Phil Leblanc 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 bitfallacious (no offense intended!). The client or server is "notcomplex" because 99% of the complexity (TLS) is assumed to be alreadyimplemented in a library available everywhere (eg. OpenSSL). We couldsay in the same way that a modern HTTP client is not complex - and isan 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 andserver 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 willdefinitely look into it.Has anyone already used it in this sort of context?
Cheers
Phil