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@xxxxxxxxxxxx (avarageanonymous@xxxxxxxxxxxx): > 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@xxxxxxxxxxxxxxxxxxxx > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- Mike Perry
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-talk mailing list tor-talk@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk