The protection offered by TLS in a TOFU scheme

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 :)

The first one is a short and somewhat sloppy introduction to
certificate security in general. The second is a more thorough guide
to TOFU as a validation scheme.

In general, TLS without any validation at all offers no significant
protection. However (and this is worth noting) it does protect data in
transit from dragnet surveillance. A simple sniff of network traffic
will not reveal the paths you visit on a server, or the query strings
you send. That's always something. Any sort of validation at all
offers more security on top of that. TOFU is not perfect, but it's a
lot better than no validation.

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

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

Cheers,
ew0k

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 Fingerprint
https://tlsfingerprint.io

The use of TLS in Censorship Circumvention
https://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-prob
ably-doing-certificates-wrong.gmi

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

YMMV as always.


?0?

> ? 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 Fingerprint
> https://tlsfingerprint.io
>
> The use of TLS in Censorship Circumvention
> https://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.

Yes. Note that I don't -- for example -- claim that it protects us
from meta data or tracking. As you say, there are endless options for
abuse. Most of those apply to the CA cert validation scheme too, of
course. Any data we send or receive is a data point that can be
harvested at some point and form along the way, and the more data
points an adversary has the more it can analyse and infer.

> ? 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?

You are absolutely right. As I wrote in my second gemlog post:

"Trust On First Use basically means that if I can't verify the
identity of the server I connect to, I can at least make sure to check
that it's the same server on any subsequent connections. In and of
itself this is not a terrible scheme. As mentioned in the spec no
certificate chain needs to be sent, for example. This can almost half
the amount of data sent on in a single request, as gemtext documents
are typically quite small. We also protect ourselves from Man in the
Middle Attacks on all connections except - notably - the first.

The downsides are equally obvious. First of all we can't automatically
validate the server on our first connection. Neither can we really on
subsequent connections; we can only tell if it's still the same host."

In a CA scheme we trust the CAs. Despite the CA system having its own
set of flaws (did you know that a company Example Inc can be
incorporated in two different states in the US by entirely different
people, and thus both buy legitimate certificates for the same
domains, as the CAs will assume that it's the same corporate entity?).

Basically, whichever scheme we choose will have its own flaws and
merits. It's very much a matter of which flaws you find to be most
dangerous or abhorrent.

For my own sake I very much liked both your implementation of the
mercury protocol and Solderpunk's speculative post about it. There's
something alluringly simple about proclaiming that "F it, TLS is just
security theatre anyway!" and skipping it altogether. And it wouldn't
be entirely wrong; there are some huge and obvious problems with it,
as we've seen. I twitch nervously whenever sending login credentials
over an unencrypted connection, though, knowing that it'll be stored
in plain text in someone's log somewhere along the way.

I definitely think that TOFU solves some problems. Not all, but some.
And somewhere we have to decide which problems we want to solve and
which ones we're willing to accept. Gemini is not a great protocol if
you're in need of strong privacy.

Cheers,
ew0k

> On Mar 5, 2021, at 11:30, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 
> I definitely think that TOFU solves some problems. Not all, but some.
> And somewhere we have to decide which problems we want to solve and
> which ones we're willing to accept. Gemini is not a great protocol if
> you're in need of strong privacy.

Indeed. Arguably, no protocols are :)

It's my opinion that the easiest course of action is to ignore the TOFU 
problematic altogether ?  and blindly use TLS for transmission security only. 

TOFU doesn't seem to be a good operational fit for Gemini.

Developing  a whole new trust model to support it is beyond the scope of 
the Gemini protocol ? in my view.

The easiest win would be to stick to just plain TLS ? and call it a day.

?0?

> It's my opinion that the easiest course of action is to ignore the TOFU 
problematic altogether ?  and blindly use TLS for transmission security only.
>
> TOFU doesn't seem to be a good operational fit for Gemini.
>
> Developing  a whole new trust model to support it is beyond the scope of 
the Gemini protocol ? in my view.
>
> The easiest win would be to stick to just plain TLS ? and call it a day.

An absolutely valid opinion. Just accept any cert and go. Any client
developer out there can already do that, of course (and any automated
clients have to, in the current state of affairs).

Another option is to stick with CAs, which all(?) TLS libraries do by
default. Also a valid opinion.

I personally like TOFU, but it's proven to be very very hard to
communicate to implementers and server operators what TOFU means for
them.

Basically, in my opinion, all these three options have merits and
flaws and I'd be okay with any of them as the final choice.

Cheers,
ew0k

> On Mar 5, 2021, at 11:30, Bj?rn W?rmedal <bjorn.warmedal at gmail.com> wrote:
> 
> There's something alluringly simple about proclaiming that "F it, TLS is just
> security theatre anyway!" and skipping it altogether. 

Security theatre! 

You will find a kindred spirit in Bruce Schneier ? of Applied Cryptography fame.

https://www.schneier.com/essays/archives/2009/11/beyond_security_thea.html
https://en.wikipedia.org/wiki/Security_theater

While the above essay focuses on [ physical | political | societal ] 
security, the exact same dynamics apply to digital systems.

?0?