[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] How to obfuscate the Tor Browser activity from the Time/Size correlation attack?
>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.
Thank you, VPN is often used by anonymous just to hide the fact of Tor protocols usage from GISP by connecting to the VPN and then forwarding to the Entry from VPN IP but with the current TBB if the GISP would statistically scan it would be able to correlate the GISP to VPN connection and Exit to Gmail server connection by the similar size and timings so your proposition would make it more processors hungry process but Google has the power to feed and that is how they could find anonymous.
Previously looking at "Also run an obfsproxy bridge" as suggested by Mike Perry was misleading at first because I have looked at running the bridge and running my traffic through it with a currently deployed transports like obfs2 or obfs3 that look like for circumventing a censorship not related to my problem. Mixmin remailer nyms answer is helpful but not in my threat model. Then after all this time I have found the answer to start with "Try to run through Undeployed plugins from https://www.torproject.org/docs/pluggable-transports.html.en list"
At the moment the latest tickets are for the Stegotorus but I still don't know the schedule and it seems from the paper that SkypeMorph is a little stronger for the Time obfuscation. It was renamed to the Code Talker Tunnel and comes from crysp.uwaterloo.ca/software/
I have seen Tor 1.0 thread so I am asking the similar question to the Tor Project "Is it a priority now and do you have a schedule for it or it just may happen as a random Pluggable Transport Bundles with deployed transports or they should be the separate releases from other than Tor Project Inc. and Inc. are making a platform for them so it is the question of stable platform for us and the transports release date should be asked from transports projects directly?"
If someone could answer my questions about the parallel tab with web application in the current TBB it would still be helpful for me, thanks.
On 03/23/2013 at 8: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