The protection offered by TLS in a TOFU scheme

Björn Wärmedal bjorn.warmedal at gmail.com
Fri Mar 5 10:30:42 GMT 2021


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


More information about the Gemini mailing list