[tor-talk] How to obfuscate the Tor Browser activity from the Time/Size correlation attack?

[Mike Perry]

You got me. I'll bite. This is probably my favorite FAQ to answer, in
part because I have a dissenting opinion from the established dogma. :)

Right now, I think the best answer we have is "Also run an obfsproxy
bridge", but that's not a great answer for many reasons (in addition to
being tricky to do with TBB's Tor instance).

The big problem with e2e correlation is the multiple visit problem. A
bridge might improve things if there is enough traffic, but over a long
period of time the adversary can build up confidence in their
correlations, especially if the bridge is only in infrequent use.


So we still have no great answers at the moment. But as I said, I'm an
optimist about the future.

In my opinion, the first problem we need to solve is the Website Traffic
Fingerprinting problem. If we're clever, lightweight solutions to that
problem will also serve to reduce e2e correlation accuracy. Dual-use
examples include running an HTTP to SPDY conversion proxy at every Exit
(so we can make use of more efficient request re-combination,
pipelining, and randomization than most servers currently support), and
light-weight adaptive padding to the Guard node. See these two links for
further thoughts in that direction:
https://www.torproject.org/projects/torbrowser/design/#website-traffic-fingerprinting
https://www.torproject.org/projects/torbrowser/design/#traffic-fingerprinting-defenses

With those defenses in place, I am hopeful that if we can also scale Tor
to tens of millions of concurrent users, those defenses will also
significantly increase the number of observations an adversary has to
make to succeed at e2e correlation. But we probably need lots more users
(to increase the rate of similarly-sized concurrent activity to within
our ability to blend it with padding) for it to actually work with
acceptable amounts of padding.

Thus spake avarageanonymous at hushmail.com (avarageanonymous at hushmail.com):

> How would you obfuscate the packets from the the Time/Size correlation
> in this example activity:
> 
> The user in California sends the E-Mail message from the web client
> provider, possibly 1Gmail to the 2Gmail address?
> 
> It is said that Tor Browser working with protocol that is made to send
> this message in 512 bytes packets.  The users Internet provider could
> log and see the approximate size of the message and in California for
> example the Google working with self-owned Internet Provider could
> correlate the approximate size of the send to the message sent from
> 1Gmail to the Entry Node with the size of the message received by
> 2Gmail. Does this threat exists?
> 
> Maybe the web application that could be opened in the same Tor Browser
> next to the web mail client and that application would generate some
> truly random traffic from some truly random generating server so the
> Internet Provider would see the all traffic including the random and
> would not be able to sufficiently correlate the Size? It would be
> wonderful if there could be such option in the Tor Browser. It would
> be awesome if the user could just use non-exit relaying for this
> purpose but not everyone is able to use it because of the NAT or
> Firewall. It looks that Time could not be obfuscated as easily as
> Size. Is the Size obfuscation possible within the current Tor protocol
> specification for the Tor Browser? If this kind of web application is
> possible and would obfuscate the Size from the Internet Provider? If
> Google is running the Entry Node or it is being hosted on Google, the
> Google would still be able to correlate the Size and Time?
> 
> _______________________________________________ tor-talk mailing list
> tor-talk at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk

-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-talk/attachments/20130314/0afc4751/attachment.pgp>