Aw: Re: Aw: Re: Aw: Re: Problem w/ Using tor(k) for Geostreaming Live-Videos
TOO bad! Now I bypass the ip geostreming shiled but end up with memory access error /tmp$ torkify mplayer rtsp://c36000-ls.w.core.cdn.streamfarm.net/2R38HDlo3/36000zdf/live/3546zdf/encoder.geozdf.geoevent_h.wmv Playing rtsp://c36000-ls.w.core.cdn.streamfarm.net/2R38HDlo3/36000zdf/live/3546zdf/encoder.geozdf.geoevent_h.wmv. Resolving c36000-ls.w.core.cdn.streamfarm.net for AF_INET... Connecting to server c36000-ls.w.core.cdn.streamfarm.net[195.122.137.178]: 554... STREAM_LIVE555, URL: rtsp://c36000-ls.w.core.cdn.streamfarm.net/2R38HDlo3/36000zdf/live/3546zdf/encoder.geozdf.geoevent_h.wmv Stream not seekable! file format detected. Speicherzugriffsfehler = momory access error! if i use torify instead of torkify i get NO dns issue but the geostremer calls out bad ip again! Can sombody beat this system :) :) - http://wgeostreaming.zdf.de/encoder/livestream15_h.asx - Original Nachricht Von: Robert Hogan [EMAIL PROTECTED] An: [EMAIL PROTECTED] Datum: 11.06.2008 23:53 Betreff: Re: Aw: Re: Aw: Re: Problem w/ Using tor(k) for Geostreaming Live-Videos On Wednesday 11 June 2008 22:34:09 you wrote: rtsp://c36000-ls.w.core.cdn.streamfarm.net/2R38HDlo3/36000zdf/live/3546zdf/ encoder.geozdf.geoevent_h.wmv Hi Erich, I'll answer off-list since it's probably not an or-talk issue. 1. To confirm TorK is properly forcing all your Tor traffic through a german exit node, you should browse through Konqueror or Firefox. If the flag appearing in the yellow pop-up window is always german, then you are accessing the sites through a german exit node and the 'pseudonymity' is working. 2. You're right in your previous mail - only traffic that shows up in the yellow pop-up is going through Tor. The flag there indicates what country the traffic is leaving the Tor network from. 3. torify mplayer [url] is the format to use. torify can leak DNS addresses. TorK comes with a patched version called torkify, which tries not to leak DNS requests. So you could also try: torkify mplayer [url] Hopefully working through 1 and 2 above will help you confirm that TorK and Tor are working as you expect them to. If those are working, then your issue is with mplayer. Robert Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv
RE: Re: Aw: Re: Aw: Re: Problem w/ Using tor(k) for Geostreaming Live-Videos
Can sombody beat this system :) :) - http://wgeostreaming.zdf.de/encoder/livestream15_h.asx I just set my proxy to de.pickaproxy.com:8133 and it worked (slowly) from my Windows Vista machine. I reside in Canada. Wesley
Re: SPD talk: Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [EMAIL PROTECTED] wrote: I just noticed this talk at the Security and Privacy Day from May 2008. While I understand that Tor's thread model does not defend against a GPA I am still curious what effect this attack can have against the current, real Tor network? Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems http://web.crypto.cs.sunysb.edu/spday/ (same old attack snipped) We've heard about this attack several times, and have had at least a couple discussions. As more and more time goes by, I'm inclined to think it's either complete vapor, or just an impotent variation on an existing attack. FUD is easy to spread, considering what Tor is for, and who it protects; I've seen so much of it that when a new attack comes along, I say, Proof plox. =:oD - -- F. Fox AAS, CompTIA A+/Network+/Security+ Owner of Tor node kitsune http://fenrisfox.livejournal.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iQIVAwUBSFGLQOj8TXmm2ggwAQjhhg//Vhdd+HAekL9KRkeF/GevnY499nHEb1U7 wNZRH2Ecc1E8/TiDug3dBU4p+V1IeT1wM5/bsczhmoJGZpMYXclpUawllHjrzeKx Fyl0mirVivej3UCiX/Ir581+BXmn4OIFJumk/suKcYOLad/kSeO/is+t9gujbASj QU16zlqX4y68Uad8W6AIlw3w5EmbQSjL5KUfZKP67hLCzqZQRWgUcTIEBqIOvIdf VMh3cpcj098xMckXG8dhUK/a1Yaya+vHXh8xQMLoGdd8QQXc2LuQNdLyM8L2sf7w cBVVQjAXW8tlYNc+cz1sRI/mvgBgg6sd+oc9bMznPXC1UlBmjGvCSMj8gx1p8w8j fJMzYOaoOIXjdRavOMmStFMMGaWgWXeApzdBkfocBzsWHoC7K2fazcfQHrOWGjX8 4dIvlv47FxlrmTv56aoYggcC/V/ge2EDyerF5oWhWHx3ArWM8LhBIlamMxN1S3Di 76CI6p/Vy1wJv3ii25mPWPzLI6ChBZQuML0kKaoLpTQjdVUz6X4GjXZXSg45baCJ 1uPCSk3yHZLFaN4uOJupZ9GxXm1aRNluQbPsuprrKkKzZeBE5htemk4W4UNB0v7v pGXW6b3uorM78YxWMFqnbI/pUsDmH12HrQZFRQnfSFsdsi/xAiZF/Q874yhtKUFl BGJvmzItbpc= =n3pf -END PGP SIGNATURE-
Aw: RE: Re: Aw: Re: Aw: Re: Problem w/ Using tor(k) for Geostreaming Live-Videos
Hmm,, I tried it with mplayer http_proxy:/your_proxy/htpp://asx and still got bad IP Can you walk me thru or is anybody on the list that can do it under Linux?? (Debian) Please email me as well as the list as I am about to leave the mailinglist!! THX a lot, folks Erich PS: In return I can offer BBC Radio from the live matches in English :) - Original Nachricht Von: Wesley Kenzie [EMAIL PROTECTED] An: or-talk@freehaven.net Datum: 12.06.2008 19:54 Betreff: RE: Re: Aw: Re: Aw: Re: Problem w/ Using tor(k) for Geostreaming Live-Videos Can sombody beat this system :) :) - http://wgeostreaming.zdf.de/encoder/livestream15_h.asx I just set my proxy to de.pickaproxy.com:8133 and it worked (slowly) from my Windows Vista machine. I reside in Canada. Wesley Jetzt komfortabel bei Arcor-Digital TV einsteigen: Mehr Happy Ends, mehr Herzschmerz, mehr Fernsehen! Erleben Sie 50 digitale TV Programme und optional 60 Pay TV Sender, einen elektronischen Programmführer mit Movie Star Bewertungen von TV Movie. Außerdem, aktuelle Filmhits und spannende Dokus in der Arcor-Videothek. Infos unter www.arcor.de/tv
Re: SPD talk: Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems?
Hi, On Thu, 12 Jun 2008 13:46:56 -0700, F. Fox [EMAIL PROTECTED] said: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [EMAIL PROTECTED] wrote: I just noticed this talk at the Security and Privacy Day from May 2008. While I understand that Tor's thread model does not defend against a GPA I am still curious what effect this attack can have against the current, real Tor network? Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems http://web.crypto.cs.sunysb.edu/spday/ (same old attack snipped) We've heard about this attack several times, and have had at least a couple discussions. As more and more time goes by, I'm inclined to think it's either complete vapor, or just an impotent variation on an existing attack. FUD is easy to spread, considering what Tor is for, and who it protects; I've seen so much of it that when a new attack comes along, I say, Proof plox. =:oD - -- F. Fox I was unaware this talk/attack was discussed on this list before, forgive me for not searching the archives. How does one search the archives, via. some google trick? So this attack is nothing to worry about? It is just FUD? Was it done on a private Tor network (as is my assumption)? -gojosan -- [EMAIL PROTECTED] -- http://www.fastmail.fm - Same, same, but different
Re: SPD talk: Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 [EMAIL PROTECTED] @ 2008/06/12 21:22: Hi, How does one search the archives, via. some google trick? yes. you can use site:archives.seul.org/or/talk search terms -BEGIN PGP SIGNATURE- iD8DBQFIUZaJXhfCJNu98qARCAL3AJ97TBBSAflCJzAXYoa4oiIx636SNgCg6kIi k39oYErQjUNTrUR+lm/s/H0= =Ae+f -END PGP SIGNATURE-
Time synchronization on tor servers and tor clients
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi everyone, I had an experience a few months ago in which I was running a tor client in a virtual machine. Because of the way I'd configured vmware, the clock of the virtual machine drifted significantly. After a while it was off by days --- the machine had been up about a month. Anyhow, I noticed that tor wasn't working correctly in that it wasn't making connections to entry guards. When I would restart the daemon, I could tell that it was starting up connections, but after a while these all died. So, my question is, does tor depend explicitly or implicitly on time synchronization? Perhaps via the published line in the cached-routers list? Anthony G. Basile -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIUZyGl5yvQNBFVTURAswaAJ9pYOq6GEftW++4KOxnBc+BQCpeWwCePHYp 8UgI1Lu+HHApn1hHwNeav/k= =J1Jm -END PGP SIGNATURE-
Re: SPD talk: Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems?
So this attack is nothing to worry about? It is just FUD? Was it done on a private Tor network (as is my assumption)? If you read the slides, you will see it appears the nodes in the attack were real. Maybe they just named them that way for humor, however how funny is it that one of the nodes is the same name as a tor directory authority (lefkada) ? Steve
Re: Time synchronization on tor servers and tor clients
On Thu, 12 Jun 2008 18:00:38 -0400 basile [EMAIL PROTECTED] wrote: I had an experience a few months ago in which I was running a tor client in a virtual machine. Because of the way I'd configured vmware, the clock of the virtual machine drifted significantly. After a while it was off by days --- the machine had been up about a month. Anyhow, I noticed that tor wasn't working correctly in that it wasn't making connections to entry guards. When I would restart the daemon, I could tell that it was starting up connections, but after a while these all died. So, my question is, does tor depend explicitly or implicitly on time synchronization? Perhaps via the published line in the cached-routers list? Did you check the log file(s)? There were most likely at least several complaints issued by tor. Scott Bennett, Comm. ASMELG, CFIAG ** * Internet: bennett at cs.niu.edu * ** * A well regulated and disciplined militia, is at all times a good * * objection to the introduction of that bane of all free governments * * -- a standing army. * *-- Gov. John Hancock, New York Journal, 28 January 1790 * **
Re: SPD talk: Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems?
Thus spake [EMAIL PROTECTED] ([EMAIL PROTECTED]): I just noticed this talk at the Security and Privacy Day from May 2008. While I understand that Tor's thread model does not defend against a GPA I am still curious what effect this attack can have against the current, real Tor network? Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems http://web.crypto.cs.sunysb.edu/spday/ A handful of comments about the paper (many of these they themselves brought up, but some they did not): 0. They are really an active adversary here. They need to be controlling a website in order to unmask users, or have control of some exit nodes or their upstream routers, and must modulate the bandwidth of TCP connections considerably (+/- 30-40KB/sec or more, for a period of 10 minutes). 1. Their results for path recognition (25% false negatives, 10% false positives) are based on their limited sample set of only 13 trial circuits via a small set of nodes that must be geographically close to and well-peered with their pinging 'vantage point(s)'. I suspect reality is a lot less forgiving than this limited sample size indicates when more nodes and trials are involved using the real Tor path selection algorithm. 2. The bandwidth estimation technique they utilized (based on TCP Westwood/CapProbe/PacketPair) is very sensitive to any queuing and congestion that occurs between the target and the 'vantage point(s)'. As soon as congestion happens along the path, these types of estimates report a large amount of excess capacity (rather than no capacity) due to the acks/responses getting compressed together in queues. The way this has been 'fixed' in TCP Westwood+ is to filter out the high estimates and perform weighted averaging to smooth fluctuations (precisely what they are trying to measure). It would have been nice if they provided some more realistic testing of their bandwidth estimation consistency using real world nodes as opposed to the lab results on half-duplex ethernet. 3. Based on my measurements last year, only the top ~5-10% nodes are capable of transmitting this much data in an individual stream, and only if all of the nodes in your path are from this set. Furthermore, as load balancing improves (and we still have more work to do here beyond my initial improvements last year), these averages should in theory come down for these nodes (but increase for slower nodes). So how they will fair once we figure out the bottlenecks of the network is unknown. They could do better in this case, but it is probably more likely the average stream capacity for most nodes will drop below their detection threshold. 4. Right now these few fast nodes carry about 60% of the network traffic. A rough back of the envelope calculation based on our selection algorithm means that only ~22% (.6*.6*.6) of the paths of the network have this property for normal traffic, and only ~4.5% of hidden service paths (which are 6 hops). 5. Their error rates do get pretty high once they've begun trying to trace the stream back to its ISP (on top of the rates for just path recognition). Any other fluctuations in traffic are going to add error to this ability, and I imagine traffic fluctuates like crazy along these paths. They also assume full a-priori knowledge of these routes which in practice means a full map of all of the peering agreements of the Internet, and 'vantage point(s)' that have no queuing delay to all of them.. A couple countermeasures that are possible: 1. Nodes that block ICMP and filter closed TCP ports are less susceptible to this attack, since they would force the adversary to measure the capacity changes at upstream routers instead (which will have other noise introduced due to peers utilizing the link as well). I am wondering if this means we should scan the network to see how many of these top nodes allow ICMP and send TCP resets, and if it is feasible to notify their operators that they may want to consider improving their firewalls, since we're only talking about 100-150 IPs here. There are a lot more critical things to scan for though, so this is probably lower priority. 2. Roger pointed out that clients can potentially protect themselves by setting 'BandwidthRate 25KB' and setting 'BandwidthBurst' to some high value, so that short lived streams will still get high capacity if it is available, but once streams approach the 10-20minute lifetime needed for this attack to work, they should be below the detectable threshold. I think this is a somewhat ugly hack, and should probably be governed by a High Security Mode setting that would be specifically tuned to this purpose (and be a catching point for other hacks that protect against various attacks but at the expense of performance/usability). All this aside, this is a very clever attack, and further evidence that we should more closely study capacity properties, reliability properties, queuing properties, and general balancing properties of
Re: SPD talk: Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems?
Hi, On Thu, 12 Jun 2008 16:26:48 -0700, Mike Perry [EMAIL PROTECTED] said: Thus spake [EMAIL PROTECTED] ([EMAIL PROTECTED]): I just noticed this talk at the Security and Privacy Day from May 2008. While I understand that Tor's thread model does not defend against a GPA I am still curious what effect this attack can have against the current, real Tor network? Simulating a Global Passive Adversary for Attacking Tor-like Anonymity Systems http://web.crypto.cs.sunysb.edu/spday/ A handful of comments about the paper (many of these they themselves brought up, but some they did not): [snip] That is great info and very well explained, thank you. Your response was exactly what I was hoping for. A couple countermeasures that are possible: 1. Nodes that block ICMP and filter closed TCP ports are less susceptible to this attack, since they would force the adversary to measure the capacity changes at upstream routers instead (which will have other noise introduced due to peers utilizing the link as well). I am wondering if this means we should scan the network to see how many of these top nodes allow ICMP and send TCP resets, and if it is feasible to notify their operators that they may want to consider improving their firewalls, since we're only talking about 100-150 IPs here. There are a lot more critical things to scan for though, so this is probably lower priority. I am considering running an exit relay. I have a software firewall to stealth ports (ICMP, TCP, etc) and I assume filter is synonymous with stealth? When I enable my relay (cable Internet connection) I will most likely use BandwithRate of 1048576kb and a BandwidthBurst of 2097152kb. Does this mean my node is more susceptible to this attack? Also, I have the bandwidth to set BandwithRate of 2097152kb and a BandwithBurst of 4194304kb; would this larger rate be preferable? 2. Roger pointed out that clients can potentially protect themselves by setting 'BandwidthRate 25KB' and setting 'BandwidthBurst' to some high value, so that short lived streams will still get high capacity if it is available, but once streams approach the 10-20minute lifetime needed for this attack to work, they should be below the detectable threshold. What is considered a high BandwidtBurst setting? I think this is a somewhat ugly hack, and should probably be governed by a High Security Mode setting that would be specifically tuned to this purpose (and be a catching point for other hacks that protect against various attacks but at the expense of performance/usability). Could you please elaborate on these other hacks? What other settings should be used for those who prefer security/anonymity over performance/usability? In your opinion what settings and actions constitute a High Security Mode? All this aside, this is a very clever attack, and further evidence that we should more closely study capacity properties, reliability properties, queuing properties, and general balancing properties of the network. -- Mike Perry Mad Computer Scientist fscked.org evil labs Thank your for your time and assistance, -gojosan -- [EMAIL PROTECTED] -- http://www.fastmail.fm - One of many happy users: http://www.fastmail.fm/docs/quotes.html
