[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #9493 [EFF-HTTPS Everywhere]: Implement an option to pad HTTPS requests against traffic analysis
#9493: Implement an option to pad HTTPS requests against traffic analysis
----------------------------------+-----------------------------------------
Reporter: pde | Owner: pde
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: EFF-HTTPS Everywhere | Version:
Keywords: | Parent:
Points: | Actualpoints:
----------------------------------+-----------------------------------------
One of the tools that dragnet surveillance actors have against both HTTPS
and Tor is message length analysis. In general message lengths can be
used to determine which paths on a give HTTPS domain a browser might be
requesting (summed, but probably extractably so, with the lengths of
messages the client might be POSTing to the server), and to perform end-
to-end traffic analysis of Tor circuits.
HTTPS Everywhere is in a position to pad requests to servers to some round
number of bytes (N byte blocks, powers of two, floors of powers of some
number lower than two). We could do this by sticking in a new X-Padding:
HTTP header. We could also write an RFC specifying that servers should
pad their responses in a similar way if they see the X-Padding header.
Perhaps we could persuade some servers to respect this.
Would this be valuable? What padding scheme would we want? Powers of two
seems too costly for long messages, maybe we could have a hybrid that used
512 byte blocks for short messages and powers of 1.3 (15% overhead) or
something for long messages. Perhaps we could even collaborate with some
academics to figure out a good padding scheme based on message length
spectra for gmail, wikipedia, or other major sites.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9493>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs