-- Leo's gemini proxy

-- Connecting to bbs.geminispace.org:1965...

-- Connected

-- Sending request

-- Meta line: 20 text/gemini; charset=utf-8

Comment by πŸ€– gamma


Re: "Surveillance in Gemini"

In: s/Gemini


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.


πŸ€– gamma

Jan 25 Β· 4 months ago


5 Later Comments ↓


πŸ‘€ nikhotmsk [OP] Β· Jan 25 at 16:42:

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.


🐝 Addison · Jan 25 at 17:04:

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.


β˜•οΈ mozz Β· Jan 25 at 17:58:

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.


β€” https://datatracker.ietf.org/doc/html/rfc8446#section-5.4


πŸ€– gamma Β· Jan 26 at 01:41:

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


πŸš€ ElectricalDance Β· Jan 26 at 13:02:

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.


Original Post


πŸŒ’ s/Gemini

Surveillance in Gemini β€” 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...

πŸ’¬ nikhotmsk Β· 6 comments Β· 3 likes Β· Jan 25 Β· 4 months ago Β· #privacy

-- Response ended

-- Page fetched on Sun Jun 2 14:58:19 2024