Gemini privacy

Phil Leblanc philanc at gmail.com
Tue Mar 9 02:23:06 GMT 2021


Hi Nothien,

> Length-analysis prevention is not Gemini's job, it's the job of TLS.
> And TLS does provide a mechanism to defend against it - padding.

You are perfectly right. The new  "record padding" mechanism added to
TLS 1.3 [1] is almost perfect for the job. Of course it doesn't
protect servers which serve few large files, but for the typical small
gmi files, it is perfect.

[1] https://tools.ietf.org/html/rfc8446#section-5.4

Regarding support, It is supported by OpenSSL: see option 'record_padding'  [2]

[2] https://www.openssl.org/docs/man1.1.1/man3/SSL_CONF_cmd.html

As TLS 1.3 is not yet mandatory for Gemini, and as several server
owners may not be interested by this privacy issue, I guess that
record padding may not be part of Gemini specification. But I think it
should at least belong to a "best practices" document.

A recommended value could be 4,096  (all served files padded during
transport to the next multiple of 4KB).  Servers serving high volume
of very small files (typically 0 to 2KB) could use 1,024 instead.

Thanks again for the suggestion

Phil

On Mon, Mar 8, 2021 at 11:32 PM Phil Leblanc <philanc at gmail.com> wrote:
>
> On Mon, Mar 8, 2021 at 10:35 PM <nothien at uber.space> wrote:
> >
> > Firstly, most Gemini documents are (intentionally) pretty tiny, fitting
> > within maybe 1 or 2 KB.  This is not so big an issue.
>
> hmmm,  with some form of padding yes. But without padding, I am not so sure.
>
> > > What countermeasures could we propose?
>
> > 1) and 2) are too complicated (particularly with Gemini's spirit of
> > being able to implement all major features in an afternoon) and
>
> I have seen many time this argument about complexity. I find it a bit
> fallacious (no offense intended!). The client or server is "not
> complex" because 99% of the complexity (TLS) is assumed to be already
> implemented in a library available everywhere (eg. OpenSSL). We could
> say in the same way that a modern HTTP client is not complex - and is
> an afternoon project - because LibCurl is available everywhere :-)
>
> > 3) is just not backward compatible.
>
> My point is not about the protocol. Just what the capsule owner and
> server software could do.
>
> > > Has any server author designed some sort of countermeasure against
> > > length-based attacks?  Has it been already discussed?
> >
> > Length-analysis prevention is not Gemini's job, it's the job of TLS.
> > And TLS does provide a mechanism to defend against it - padding.  This
> > works better for smaller files as it is then harder to distinguish
> > between files of similar sizes.  I don't know how OpenSSL and other
> > common TLS libraries handle padding (I've read the TLS 1.3 RFC, and it
> > seems that currently clients and servers have to opt into using padding,
> > and the amount of padding and how it varies is implementation-defined),
> > but we can definitely look into it, and perhaps provide recommendations
> > for it in the Best Practices document (as seems to be what's happening
> > with close_notify(), IIRC).
>
> I didn't know about TLS padding. Thanks for pointing it out. I will
> definitely look into it.
> Has anyone already used it in this sort of context?
>
> Cheers
>
> Phil


More information about the Gemini mailing list