philanc at gmail.com
Mon Mar 8 23:32:11 GMT 2021
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