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

[Gregory Disney <gregory.disney@xxxxxxxxx>]

Well Google is not the service to use if privacy is a concern, either way
if your really concerned about obfuscating. Entrance node should be through
a VPN, then route and relay.


On Sat, Mar 23, 2013 at 4:51 PM, <avarageanonymous@xxxxxxxxxxxx> wrote:

> 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@xxxxxxxxxxxx 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.
>
> _______________________________________________
> tor-talk mailing list
> tor-talk@xxxxxxxxxxxxxxxxxxxx
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
>
_______________________________________________
tor-talk mailing list
tor-talk@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk