nothien at uber.space
nothien at uber.space
Mon Mar 8 22:35:19 GMT 2021
Phil Leblanc <philanc at gmail.com> wrote:
> Now Nathan looks at Alice's encrypted traffic with Bob's server. Just
> looking at the response sizes, Nathan knows what file(s) Alice has
> accessed and their content (collected during the indexing phase). No
> crypto, no MITM involved.
> Of course, with lots of files in Bob's capsule, the matching is less
> perfect, but it still leaks lots of information regarding what Alice
Firstly, most Gemini documents are (intentionally) pretty tiny, fitting
within maybe 1 or 2 KB. This is not so big an issue.
> What countermeasures could we propose? I can think of a few more or
> less practical approaches::
> 1. make sure the same file is never served with the same size - add
> random white space at the end of gmi / txt / html files, add random
> comments to pics, zip files, etc.
> 2. or add lots of "decoy" files (with all sorts of sizes) to your
> capsule. It will make life more difficult for the attackers, ... but
> also for the legit indexers.
> 3. Adopt a "twitter-like" approach: serve only fixed-size content.
> Serve only 8 KB gmi pages and 32KB pics (didn't Solderpunk have an
> experiment with fixed size pics?)
1) and 2) are too complicated (particularly with Gemini's spirit of
being able to implement all major features in an afternoon) and 3) is
just not backward compatible.
> 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).
Note also that for larger files which can be more easily profiled by
outsiders, there is no good solution. Even with HTTP and other
protocols, attackers can clearly distinguish between a significant data
transfer (and can roughly measure its size), even across multiple
In conclusion, it's not Gemini's responsibility to handle these kinds of
attacks. Some have suggested Gemini over TOR as a solution to prevent
the more invasive attacks, but I haven't seen much development on that
~aravk | ~nothien
More information about the Gemini