Hi! 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 > read. 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 packets. 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 front. ~aravk | ~nothien
---
Previous in thread (1 of 16): 🗣️ Phil Leblanc (philanc (a) gmail.com)
Next in thread (3 of 16): 🗣️ Phil Leblanc (philanc (a) gmail.com)