gemini://bbs.geminispace.org/s/Gemini/14348

Adversary can tell very specifically which one gemini page a user is requesting, based on the size of server response. There is no need to decrypt the channel to learn which page is transmitted there, the only thing that matters is the size of that message.

The same thing works all the way around, if someone has submitting a picture or a text to the gemini forum, adversary can see corresponding portion of encripted traffic going from specific user. Again, there is no need to crack the TLS encription. Only thing that matters is size of the data being sent. This can ruin your anonimity on gemini. Also, when posting to the public forum, messages usually appear on public page immediately. Adversary can learn the precision time of post appearance and compare it to the user activity.

There are some methods to fix the issue. 1. on user side, use some additional encription tunnel and put gemini protocol into it along with something else (so called masking traffic). 2. On a public server side, allow people to shedule draft publication, so adversary can not learn exact posting time.

I am sure that anonimity is a feature that needs to be preserved for those who need it. You may not need anonimity today, but you need to think about future here.

On the server side, a server that hosts potentially sensitive capsules could pad the end of the response with spaces, up to the maximum size of content hosted on the server. If the response were always ~1MB for instance then you couldn't determine which page was being accessed.

To accomplish this, the server would need to enforce a cap on content length/file size. There's a tradeoff involved. A better approach may be to just host more capsules on Tor onion sites.

I actually has the same thought about spaces. There is a second option, combine entire collection of pages as a gemini book and download it as a whole thing.

AES operates on 16-byte blocks, so at best your "size signature" is only good to a resolution of modulus 16 bytes. This isn't unique to Gemini though. At best a snoop will be able to see how many requests you're making that are within 16 bytes of each other in size. Clients often have to re-attempt requests anyway, and may drop connections before receiving a full response; so now a snoop will have to gauge the mod-16 issue on top of determining which payloads are complete or not. You could easily write a client that opens several connections at once and only completes some of them, and requests other pages at the same time.

Additionally, a paranoid capsule owner could include random junk in their responses, or a meaningless/repeated meta header ("lang=en-US;" repeated n times). I don't think there's even a size limit on those.

For me personally, this is far less of an issue than the analytics ever one of my network-connected devices is likely spewing across the ether (why do smart TVs need microphones in the remote?). I don't even really care enough to do something about that though.

TLS 1.3 already has a mechanism for padding responses for this reason, you're better off using that than trying to implement something gemini-specific.

Great point about TLS 1.3. Clients and servers could both use that to mask content length.

What you are describing is basically what High latency mix network used to do in the early 90. In short, you could send them a PGP encrypted e-Mail and they would store it and then forward it after a certain time (few hours usually). You can search Mixnet, cypherpunk remailer if you want more information about this.

TLS was never built to do this. It’s was created against "trivial" interception between you and the sender and to secure online shopping.

Surveillance in Gemini

#privacy

6 Comments ↓