💾 Archived View for rawtext.club › ~sloum › geminilist › 006014.gmi captured on 2024-03-21 at 16:35:11. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Gemini privacy

nothien at uber.space nothien at uber.space

Mon Mar 8 22:35:19 GMT 2021

- - - - - - - - - - - - - - - - - - -

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, fittingwithin 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 ofbeing able to implement all major features in an afternoon) and 3) isjust 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. Thisworks better for smaller files as it is then harder to distinguishbetween files of similar sizes. I don't know how OpenSSL and othercommon TLS libraries handle padding (I've read the TLS 1.3 RFC, and itseems 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 recommendationsfor it in the Best Practices document (as seems to be what's happeningwith close_notify(), IIRC).

Note also that for larger files which can be more easily profiled byoutsiders, there is no good solution. Even with HTTP and otherprotocols, attackers can clearly distinguish between a significant datatransfer (and can roughly measure its size), even across multiplepackets.

In conclusion, it's not Gemini's responsibility to handle these kinds ofattacks. Some have suggested Gemini over TOR as a solution to preventthe more invasive attacks, but I haven't seen much development on thatfront.

~aravk | ~nothien