💾 Archived View for rawtext.club › ~sloum › geminilist › 006027.gmi captured on 2023-09-08 at 17:07:55. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-11-30)

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

<-- back to the mailing list

Gemini privacy

Phil Leblanc philanc at gmail.com

Tue Mar 9 17:15:45 GMT 2021

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

On Tue, Mar 9, 2021 at 7:53 AM Stephane Bortzmeyer <stephane at sources.org> wrote:

This attack is well known and, for HTTP, documented in many
articles. A general view of the problem and of countermeasures is
"Peek-a-Boo, I Still See You: Why Efficient Traffic Analysis
Countermeasures Fail"
<https://cise.ufl.edu/~teshrim/tmAnotherLook.pdf>.

I wasn't implying length attacks are new :-) (just gave an examplefor people less familiar with the subject).

Thanks for the interesting "Peek-a-Boo" paper link (It also includesseveral interesting references). I think it addresses a differentproblem (traffic analysis of an encrypted stream - ie. whatinformation can we extract from an encrypted tunnel traffic).

Length attacks on Gemini traffic are _much_ simpler and more efficientsince (1) the traffic is composed of independent TLS transactions withone request and one response, and (2) responses are documents which apublicly available on the Gemini server (except for CGI and clientcert-authenticated traffic).

4. The client could obfuscate the traffic with many gratuitous
requests. See the excellent book "Obfuscation"
<https://mitpress.mit.edu/books/obfuscation>.

This approach depends on what are the attacker's objectives. If theywant to establish that you have accessed a specific sensitivedocument, the fact that you also accessed many decoys doesn't mattermuch - except if you accessed _all_ files and claim that you are infact just indexing the site.

Thanks for the Obfuscation book reference. Will try to have a look.

Cheers

Phil