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, avarageanonym...@hushmail.com 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, avarageanonym...@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
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. On Sat, Mar 23, 2013 at 4:51 PM, avarageanonym...@hushmail.com 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, avarageanonym...@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
[tor-talk] How to obfuscate the Tor Browser activity from the Time/Size correlation attack?
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 statistically 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 s o 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How to obfuscate the Tor Browser activity from the Time/Size correlation attack?
On 03/14/2013 01:55 PM, avarageanonym...@hushmail.com wrote: 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? Instead of using webmail, you could use Mixmin remailer nyms with delivery via alt.anonymous.messages (a.a.m). After arbitrarily long paths through remailer chains, encrypted messages are delivered to a.a.m, which serves as a common inbox. Checking for mail involves getting all new a.a.m posts, determining which are for you, and decrypting them. Both mail and news servers are available as hidden services. Quicksilver Windows apps (QSL for sending, and QSA for receiving) work well in Whonix with Wine. 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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
[tor-talk] How to obfuscate the Tor Browser activity from the Time/Size correlation attack?
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How to obfuscate the Tor Browser activity from the Time/Size correlation attack?
avarageanonym...@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? It's called an end-to-end correlation attack and is one of Tor's initial design trade-offs *not* to do anything about it. 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? Called padding and sometimes cover traffic. A difficult issue: https://trac.torproject.org/projects/tor/wiki/doc/TorFAQ#Youshouldsendpaddingsoitsmoresecure. There is also a paper on about padding in anonbib: http://freehaven.net/anonbib/ See also: https://blog.torproject.org/blog/one-cell-enough Some terms you could use in a search engine to find older discussions. host:lists.torproject.org end-to-end correlation attack host:lists.torproject.org padding host:lists.torproject.org traffic confirmation (Or drop the lists.) In *theory*, high latency networks can defeat it, but they come with problems on their own: http://www.mail-archive.com/liberationtech@lists.stanford.edu/msg00022.html At the moment their is no low latency network defeating this attack. Unfortunately, there is no real alternative to Tor (legally available to ordinary citizen, defeating that attack, low latency tcp, access clearnet), no competition. I can't say, how well/if the proposed solutions work. Just gave you some keywords and links if you are interested to read more about this. ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
Re: [tor-talk] How to obfuscate the Tor Browser activity from the Time/Size correlation attack?
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 avarageanonym...@hushmail.com (avarageanonym...@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk -- Mike Perry signature.asc Description: Digital signature ___ tor-talk mailing list tor-talk@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
