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
---
Previous in thread (3 of 16): 🗣️ Phil Leblanc (philanc (a) gmail.com)
Next in thread (5 of 16): 🗣️ Stephane Bortzmeyer (stephane (a) sources.org)