philanc at gmail.com
Tue Mar 9 02:23:06 GMT 2021
> 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  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.
Regarding support, It is supported by OpenSSL: see option 'record_padding' 
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
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?
More information about the Gemini