💾 Archived View for rawtext.club › ~sloum › geminilist › 005947.gmi captured on 2023-11-14 at 09:44:08. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

The protection offered by TLS in a TOFU scheme

Petite Abeille petite.abeille at gmail.com

Fri Mar 5 10:08:48 GMT 2021

- - - - - - - - - - - - - - - - - - -

Hello,

On Mar 5, 2021, at 10:30, Björn Wärmedal <bjorn.warmedal at gmail.com> wrote:

There's been some questions on the mailing list about what sort of

protection a TOFU scheme in certificates offers.

I've written about

this on my gemlog a couple of times, and several people have told me

that the posts are a good introduction to the subject. Therefore I

feel confident about posting links here :)

Thank you for reaching out, and taking the time to verbalize your usage assumptions.

Onwards to your specific points:

• PROTECT DATA IN TRANSIT FROM DRAGNET SURVEILLANCE

Yes, somewhat — ignoring larger issues such as deeper network traffic analyzes. But yes, the transmission is somewhat encrypted, at a bare minimum.

Courtesy of TLS though, the aptly named Transport Layer Security. Nothing to do with TOFU per se.

The expedient of ignoring certificates altogether would achieve the same effect.

Also, the mere existence of certificates and usage of TLS may compromise privacy — for a given value of "privacy".

TLS Fingerprinthttps://tlsfingerprint.io

The use of TLS in Censorship Circumventionhttps://tlsfingerprint.io/static/frolov2019.pdf

Clients could leak unwelcome informations.Servers could generate unique certificates for tracking purpose. The possibilities for abuse are endless, as always.

• TOFU IS NOT PERFECT, BUT IT'S A LOT BETTER THAN NO VALIDATION

The same assertion is made by the current specification, toward the end of 4.2 Server certificate validation:

"This model is by no means perfect, but it is not awful and is vastly superior to just accepting self-signed certificates unconditionally."

Saying so doesn't make it so.

My personal point of contention is that I do not buy that argument at all: it seems to be more wishful thinking than actual reality.

The operative word in "Trust on first use" is /trust/.

Where does the trust come from?

Quoting Wikipedia:

"The single largest strength of any TOFU-style model is that a human being must initially validate every interaction."

https://en.wikipedia.org/wiki/Trust_on_first_use#Model_strengths_and_weaknesses

How is this meant to happen in Gemini space? How does this happen in your operating model? How do you trust or not a given certificate?

Furthermore:

"The largest weakness of TOFU that requires manual verification is its inability to scale for large groups or computer networks."

How do you scale it, in your operating model?

The usage pattern for Gemini is quite different from SSH. How does SSH usage assumptions translates to Gemini? That's the crux of the question.

Until we develop a coherent operating model for TOFU in the context of Gemini, this is all hocus-pocus and cargo cult.

These are my personal opinions only. I speak for not other bees, but myself :)

gemini://warmedal.se/~bjorn/posts/certificate-security.gmi

gemini://warmedal.se/~bjorn/posts/your-gemini-browser-and-server-are-probably-doing-certificates-wrong.gmi

Thanks for sharing though, but this fails short, in my view, of a coherent operational model.

YMMV as always.

±0¢