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

[avarageanonymous at hushmail.com]

If my latest two questions were not meaningful I am asking as meaningful to the current TBB as I can: 

In a default TBB would the GISP(Google-owned Internet Service Provider) see the traffic coming to Entry Node as a mix of separate connections that are approximately the same size and time comparing to the direct GISP to Gmail connections? Maybe my example is bad as Google use https and the size would be somehow different but I hope you will get my point at large. To address my problem for the obfuscated mix of connections I should use the obfsproxy connection that is by design hiding all the real connections to the one(1) obfuscated so the GISP looking at the TBB to GISP connection would just see one constant connection (with all the real connections obfuscated and mixed into this one) of variable upload and download speeds (because the web application would help to make it variable by speed but constantly open connection)?

Bless the Entry Guard.


On 03/19/2013 at 10:45 PM, avarageanonymous at hushmail.com wrote:
>
>Thank you for all the help, there is some big research on this 
>problem you have showed me.
>
>Let me clarify the attack I need to be defended:
>The user in California sends the E-Mail message from the web 
>client provider, possibly 1Gmail to the 2Gmail address; all 3 Tor 
>nodes in between were not compromised; Google's Internet Service 
>Provider and Gmail were not tagging the traffic; only now as I 
>stopped the writing and file sharing activity they are trying to 
>retrospect and correlate my GISP account with the Gmail.
>NOW thanks to your replies I know that they could   
>link it very easily because I have used my Gmail only in new Tor 
>Browser instance and I have used it alone from other sites as I 
>wanted to be safe from IP/Time/Size correlation. How stupid I was?
>
>
>My actual questions are:
>
>
>1. You have introduced me to the 
>https://blog.torproject.org/blog/one-cell-enough and On June 15th, 
>2012 some other Anonymous said:
>
>"The Tor design doesn't try to protect against an attacker who can 
>see or measure both traffic going into the Tor network and also 
>traffic coming out of the Tor network. That's because if you can 
>see both flows, some simple statistics let you decide whether they 
>match up."
>
>Let the client download / upload random data from / to the relay 
>with a speed at 10-50% (random speed that change frequently) at 
>the download / upload speed. That is, if the download from the 
>relay is with a current speed at 50 KB/sec, the client should 
>download random nonsense data from the relay with a speed between 
>5 and 25 KB/sec. This result in a average speed at the random data 
>at 30%, and that will not put a hard pressure on the network."
>
>Could this example exist as a "partial" solution in the form of 
>the web application that I could run in the tab next to the Gmail 
>and that would D/U random data making requests from and to the 
>relay for some small or big files? Would in my threat model these 
>still be partially correlated as requested Size (within the 
>overall constant speed) would need to always be obfuscated by 
>bigger Size responses than the real response Size? Other possible 
>variant I see is that loading the full available bandwidth pipe of 
>the Tor Nodes with (two) files would actually reduce the speed for 
>the Gmail server watching and for the GISP it would be still 
>bigger but would just be restricted to the Tor Nodes broadband 
>ability and when the Gmail file is shared, the speed of D/U could 
>jump up quick enough to not be correlate-able because GISP would 
>constantly see the maximum bandwidth. Another variant is the 
>continuous slowdown/speedup of all traffic by some mechanism in 
>TBB or Nodes not by the D/U so it would save the network bandwidth 
>but this is the most insane to propose. What variant is real to 
>deal with or all are garbage?
>
>
>2. If the web application from the second question could start to 
>partially help the Size obfuscation problem except the GISP to 
>Entry Node requests that are needed to be somehow shown to the 
>GISP by the TBB to Entry Node connection (is it true?), could the 
>requests of TBB potentially be served encrypted and delayed enough 
>so that even so the Gmail server would see the “real” requests 
>timing, the timing would be obfuscated for the GISP to Entry Node 
>connection with a very little delay that would be synchronized 
>with other very little delays that are continuously being sent to 
>and from the Entry Node?
>These sub-second delays that would just not be the big problem to 
>the Gmail user but all the GISP to Entry Node activity would be 
>synchronized and optimized according to usage and behavior 
>templates like "Reading", "Writing", "File sharing".. for the GISP 
>it would only be these or more common traffic like “Default”? That 
>is if  the bandwidth traffic is obfuscated and what is left to 
>obfuscate is the time of request, the time of ordered changes in 
>this bandwidth traffic. 
>What could I know there are many new types of Web connections and 
>I don't know a simple http. There are so many papers from people 
>far better educated than me that I don't have a time to 
>understand. I think that serving constantly obfuscated speed when 
>needed and requests when they are correlated and indistinguishable 
>of artificial going on pair should defend the described attack and 
>I don't know why it is not possible for implementation. Don't 
>laugh and don't spend your time too much on my propositions, 
>please. It is all for the more arbitrary choices, not for a 
>generalization of the TBB standard.
>
>Peace, and God damn the age of stylometry.