Re: Active Attacks - Already in Progress?
Thus spake Theodore Bagwell (torus...@imap.cc): On Sun, 28 Nov 2010 17:54 -0800, Mike Perry mikepe...@fscked.org wrote: Rather than cripple the network by forcing more clients to use slower nodes more often, we have opted to try to document the process of running a high capacity Tor exit node: http://archives.seul.org/tor/relays/Aug-2010/msg00034.html In my research (posted earlier to this list), I did not find an issue with exit relays. The relays which were reliably chosen as part of my circuit were often the first or second relay in my circuit - not the exit relay. In this case, you are experiencing your guard nodes. This is a protective measure where the Tor client remembers a set of 3 live nodes and tries to use them for up to 2 months for its 1st hop... This is done to protect against a wide variety of traffic analysis attacks. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpyfEcctkRwv.pgp Description: PGP signature
Re: Active Attacks - Already in Progress?
On Sun, 28 Nov 2010 17:54 -0800, Mike Perry mikepe...@fscked.org wrote: Rather than cripple the network by forcing more clients to use slower nodes more often, we have opted to try to document the process of running a high capacity Tor exit node: http://archives.seul.org/tor/relays/Aug-2010/msg00034.html In my research (posted earlier to this list), I did not find an issue with exit relays. The relays which were reliably chosen as part of my circuit were often the first or second relay in my circuit - not the exit relay. Please help us to create the network we *wish* we had. I'm running a relay of my own, no worries. -- http://www.fastmail.fm - Accessible with your email software or over the web *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
I don't take issue with these particular nodes, nor the method in which they are multiplied. What concerns me is that any single entity (person/organization) is capable of convincing my Tor client to use it in the majority of circuits I build. The clusters I pointed out before have been vouched for by the community, and that's fine, let's assume they're not evil. But the fact remains that nobody - good or evil - should be capable of making themselves a party in my circuit with such reliability. -- Theodore Bagwell torus...@imap.cc On Thu, 25 Nov 2010 14:46 +0100, Olaf Selke olaf.se...@blutmagie.de wrote: On 25.11.2010 08:17, Damian Johnson wrote: The reason the operators of the largest tor relays (Blutmagie, TorServers, and Amunet) operate multiple instance is because this is the best way in practice for utilizing large connections. yep, all four blutmagie nodes are running on a single quad core cpu. The Tor application doesn't scale very well with the number of cores. Thus starting multiple instances on a single piece of hardware is the cheapest option to make use of a gigabit uplink. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/ -- http://www.fastmail.fm - Email service worth paying for. Try it for free *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
Thus spake Theodore Bagwell (torus...@imap.cc): I don't take issue with these particular nodes, nor the method in which they are multiplied. What concerns me is that any single entity (person/organization) is capable of convincing my Tor client to use it in the majority of circuits I build. The clusters I pointed out before have been vouched for by the community, and that's fine, let's assume they're not evil. But the fact remains that nobody - good or evil - should be capable of making themselves a party in my circuit with such reliability. Unfortunately, Exit bandwidth is really hard to maintain if it is not centralized, and all bandwidth is much much cheaper in bulk. It is very hard to convince an ISP to put up with the noise, attacks, and abuse complaints if you are a low budget node: https://blog.torproject.org/blog/tips-running-exit-node-minimal-harassment Rather than cripple the network by forcing more clients to use slower nodes more often, we have opted to try to document the process of running a high capacity Tor exit node: http://archives.seul.org/tor/relays/Aug-2010/msg00034.html We have to do the best with the situation we actually have. Trying to force the network to route as if it were the network we *wish* we had will only make it completely unusable. Please help us to create the network we *wish* we had. -- Mike Perry Mad Computer Scientist fscked.org evil labs pgpR0O77gJTaV.pgp Description: PGP signature
Re: Active Attacks - Already in Progress?
On 25.11.2010 08:17, Damian Johnson wrote: The reason the operators of the largest tor relays (Blutmagie, TorServers, and Amunet) operate multiple instance is because this is the best way in practice for utilizing large connections. yep, all four blutmagie nodes are running on a single quad core cpu. The Tor application doesn't scale very well with the number of cores. Thus starting multiple instances on a single piece of hardware is the cheapest option to make use of a gigabit uplink. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
Am 25.11.2010 03:38, schrieb Theodore Bagwell: ** I speak primarily of torserversNet_ numbers 1-5, and PPrivCom___ numbers 004-052. hi there, would you mind to broaden your research covering blutmagie1-4? Its last 24h sustained bandwidth is higher than the cumulated bandwidth of all torserversNet and PPrivCom relays. Currently about 25% of all traffic reported by relays flagged as exit is routed thru blutmagie (50090 KBytes/s of 191341 KBytes/s Tor network's total). This doesn't trouble you? Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
Hi, would it be noticed if an adversary modifies Tor's source code in order to report a fake observed bandwidth (a few KB), fake uptime data, and Windows as OS to the directories? Probably nobody will notice even if those relays carry a significant amount of traffic. Olaf *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
A quick look at my cache-descriptors show the following for PPrivComXXX. family PPrivCom001 PPrivCom002 PPrivCom003 PPrivCom004 PPrivCom005 PPrivCom006 PPrivCom007 PPrivCom008 PPrivCom009 PPrivCom010 PPrivCom012 PPrivCom013 PPrivCom014 PPrivCom015 PPrivCom016 PPrivCom017 PPrivCom018 PPrivCom019 PPrivCom020 PPrivCom021 PPrivCom022 PPrivCom023 PPrivCom024 PPrivCom025 PPrivCom026 PPrivCom027 PPrivCom028 PPrivCom029 PPrivCom030 PPrivCom031 PPrivCom032 PPrivCom033 PPrivCom034 PPrivCom035 PPrivCom036 PPrivCom037 PPrivCom038 PPrivCom039 PPrivCom040 PPrivCom041 PPrivCom042 PPrivCom043 PPrivCom044 PPrivCom045 PPrivCom046 PPrivCom047 PPrivCom048 PPrivCom049 PPrivCom050 PPrivCom051 PPrivCom052 PPrivCom053 PPrivCom054 PPrivCom055 PPrivCom056 PPrivCom057 PPrivCom058 PPrivCom059 PPrivCom060 PPrivCom061 PPrivCom062 PPrivCom063 PPrivCom064 PPrivCom065 PPrivCom066 PPrivCom067 PPrivCom068 PPrivCom069 PPrivCom070 PPrivCom071 PPrivCom072 PPrivCom073 PPrivCom074 PPrivCom075 PPrivCom076 PPrivCom077 PPrivCom078 PPrivCom079 PPrivCom080 PPrivCom081 PPrivCom082 PPrivCom083 PPrivCom084 PPrivCom085 PPrivCom086 PPrivCom087 PPrivCom088 PPrivCom089 PPrivCom090 PPrivCom091 PPrivCom092 PPrivCom093 PPrivCom094 PPrivCom095 PPrivCom096 PPrivCom097 PPrivCom098 PPrivCom099 PPrivCom100 As for torserversNetX, they have the following listed. family $2F265B37920BDFE474BF795739978EEFA4427510 $89B64AB62ECBE91CD58017065DE01BD477F638AD $9B41B9B3D4661566C660096B715BC647FBD72A72 $CF91FBA32FDAC4C500F3A3565591F144D5074820 $D0378B405AA7781820428EE4F40867B53CC70599 It seems they are playing by the rules by listing the other nodes owned by them in the MyFamily tag on their torrc files. On Wed, Nov 24, 2010 at 6:38 PM, Theodore Bagwell torus...@imap.cc wrote: We recently discussed an attack on onion-routing anonymity, wherein a well-funded adversary overwhelms the network with compromised relays, thereby increasing his chances of monitoring anonymity-compromising data. I don't mean to alarm anyone, but I just did some quick-and-dirty research that suggests such an attempt may already be under way. I hope to be proven wrong. I postulated that such an attacker would mass-deploy his relays in a way that did not lend a whole lot of uniqueness to the name of each relay*. The relay names would probably be random characters, numbers, or words at best. At sloppiest, they would just be one name with sequential numbers after it - AnonymityAttacker001, AnonymityAttacker002, AnonymityAttacker003, etc. So, I decided to look for such patterns in the list of Relays available in my Tor console. A quick scan revealed what appeared to be either (A) mass-deployments of Tor relays by a singular entity, or (B) astronomically-unlikely coincidental naming schemes adopted by dozens of disparate and unconnected individuals.** But it wasn't just finding these relays that concerned me. It was Tor's affinity for routing through them. See, I began closing my open circuits systematically. I kept records of any circuits which contained PPrivCom___ or torserversNet_ relays in it. I closed and recorded 43 circuits. Here are my findings: While Tor indicated it had 1665 relays to choose from, 79% of my circuits used one of the suspicious relays. 2% of my circuits used two suspicious relays. 0% of my circuits used three suspicious relays. Of the circuits I recorded, only 21% did not route through a suspicious relay. My conclusion is that someone (a security researcher? A hobbyist? A government?) is actively toying with the feasibility of attacking Tor's anonymity. According to my statistics, they may also be gaming Tor's affinity for choosing relays*** because they have, unquestionably, succeeded in relaying 79% of my circuits despite controlling a mere 2.8% of the relays in the Tor network. How dangerous is it if two of the three circuit relays are compromised? What recourse do we have? Can someone more knowledgeable shed more light on this? I yield the balance of my time. :) --- * Of course, the well-organized attacker would go to the trouble to construct names that truly blended in with the Tor namescape - such as,MrSpudRelays, QueenAnnesRevenge, SteveKenpIsMyHero, and so forth. ** I speak primarily of torserversNet_ numbers 1-5, and PPrivCom___ numbers 004-052. *** The inner workings of which I, admittedly, do not understand... 47 out of 1665 active relays, according to my Tor console. -- Theodore Bagwell torus...@imap.cc -- http://www.fastmail.fm - The professional email service *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Active Attacks - Already in Progress?
On Wed, 24 Nov 2010 18:38:23 -0800 Theodore Bagwell torus...@imap.cc wrote: We recently discussed an attack on onion-routing anonymity, wherein a well-funded adversary overwhelms the network with compromised relays, thereby increasing his chances of monitoring anonymity-compromising data. I don't mean to alarm anyone, but I just did some quick-and-dirty research that suggests such an attempt may already be under way. I hope to be proven wrong. I postulated that such an attacker would mass-deploy his relays in a way that did not lend a whole lot of uniqueness to the name of each relay*. The relay names would probably be random characters, numbers, or words at best. At sloppiest, they would just be one name with sequential numbers after it - AnonymityAttacker001, AnonymityAttacker002, AnonymityAttacker003, etc. So, I decided to look for such patterns in the list of Relays available in my Tor console. A quick scan revealed what appeared to be either (A) mass-deployments of Tor relays by a singular entity, or (B) astronomically-unlikely coincidental naming schemes adopted by dozens of disparate and unconnected individuals.** Several people and organizations run multiple Tor relays with obviously similar names. They generally do not try to hide their identities or the connections between their relays. See http://torstatus.blutmagie.de/ for an easily browsable list; click on the name of a relay to see more detailed information about it, including the ContactInfo value, if any, specified by the relay's operator. Entities which operate multiple Tor relays can, usually should, and often do use the MyFamily torrc option to indicate that their relays are run by a common operator. If two relays list each other in their MyFamily directives, your Tor client will not include them in the same circuit. Unless you have turned off the EnforceDistinctSubnets torrc option, your Tor client will also not include two relays in the same /16 network in a single circuit. But it wasn't just finding these relays that concerned me. It was Tor's affinity for routing through them. See, I began closing my open circuits systematically. I kept records of any circuits which contained PPrivCom___ or torserversNet_ relays in it. I closed and recorded 43 circuits. Here are my findings: While Tor indicated it had 1665 relays to choose from, 79% of my circuits used one of the suspicious relays. 2% of my circuits used two suspicious relays. 0% of my circuits used three suspicious relays. Of the circuits I recorded, only 21% did not route through a suspicious relay. Tor weights its node selection according to node bandwidth, as specified in the consensus. The consensus, in turn, provides bandwidth values measured by the ‘bandwidth authorities’. This weighting is necessary to balance load fairly throughout the Tor network. There should be multiple bandwidth authorities running, operated by people whom the Tor Project and the directory authority operators trust; as I understand it, there is currently only one running bandwidth authority, but the Tor Project is working on getting others back online. My conclusion is that someone (a security researcher? A hobbyist? A government?) is actively toying with the feasibility of attacking Tor's anonymity. According to my statistics, they may also be gaming Tor's affinity for choosing relays*** because they have, unquestionably, succeeded in relaying 79% of my circuits despite controlling a mere 2.8% of the relays in the Tor network. The relay families which you have complained about are most likely not controlled by a single organization, and the organizations that control them are most likely not trying or planning to attack Tor or its users. How dangerous is it if two of the three circuit relays are compromised? A passive attacker can use some combination of the following capabilities to try to link you to the Internet server you access using a Tor circuit: * The ability to monitor the TLS connection from your computer to your guard node for the circuit. * The ability to monitor the Tor circuit at your middle node (by controlling the middle node and monitoring/logging its internal state). * The ability to monitor the TCP connection from your exit node for the circuit to the server you are accessing. There are other capabilities which an attacker could have, but I think the three I have listed are sufficient for this discussion. An attacker who monitors the TLS connection from you to your guard node and the TCP connection from your exit node to the server can link the endpoints of your connection using timing alone. There is no point in considering the more precise attacks that can be performed by controlling your guard node and/or exit node themselves; if an attacker monitors both you and the server you are connecting to, you lose. An attacker who monitors the Tor circuit at your middle node and the TCP connection from your
Re: Active Attacks - Already in Progress?
Hi Theodore. The reason the operators of the largest tor relays (Blutmagie, TorServers, and Amunet) operate multiple instance is because this is the best way in practice for utilizing large connections. Robert and others are right and you should call people out if they operate multiple relays without setting the family entry. However, both of the relays you cite [1][2] not only have their families set, but contact information too so you're perfectly able to ask them if you have concerns. In particular Moritz, the operator of TorServers, both discussed his plans to get funding for running large relays on this list [3] and with several of us at PETS. I for one am thilled he's had success with it! Lastly, it sounds like you're discussing a Sybil attack. This sort of threat is the reason I wrote a script for monitoring the consensus and sending alerts when large additions to the tor network are made. You are more than welcome to keep an eye on this too by subscibing to the script's email list [4]. Also, this script has discovered this type of attack in the past, so your concerns are certainly understandable. For details see the bit about trotsky on the bad exits wiki [5]. So in short, we are well aware of this sort of attack and your vigilance would certainly be welcome. However, please try to investigate relays a bit and contact their operators before worrying too much about them. Cheers! -Damian [1] http://torstatus.blutmagie.de/router_detail.php?FP=cf91fba32fdac4c500f3a3565591f144d5074820 [2] http://torstatus.blutmagie.de/router_detail.php?FP=34a46b317dcad4ca52c449d3af3786344ee75054 [3] http://archives.seul.org/or/talk/May-2010/msg00058.html [4] https://lists.torproject.org/cgi-bin/mailman/listinfo/consensus-tracker [5] https://trac.torproject.org/projects/tor/wiki/badRelays On Wed, Nov 24, 2010 at 9:51 PM, Robert Ransom rransom.8...@gmail.com wrote: On Wed, 24 Nov 2010 18:38:23 -0800 Theodore Bagwell torus...@imap.cc wrote: We recently discussed an attack on onion-routing anonymity, wherein a well-funded adversary overwhelms the network with compromised relays, thereby increasing his chances of monitoring anonymity-compromising data. I don't mean to alarm anyone, but I just did some quick-and-dirty research that suggests such an attempt may already be under way. I hope to be proven wrong. I postulated that such an attacker would mass-deploy his relays in a way that did not lend a whole lot of uniqueness to the name of each relay*. The relay names would probably be random characters, numbers, or words at best. At sloppiest, they would just be one name with sequential numbers after it - AnonymityAttacker001, AnonymityAttacker002, AnonymityAttacker003, etc. So, I decided to look for such patterns in the list of Relays available in my Tor console. A quick scan revealed what appeared to be either (A) mass-deployments of Tor relays by a singular entity, or (B) astronomically-unlikely coincidental naming schemes adopted by dozens of disparate and unconnected individuals.** Several people and organizations run multiple Tor relays with obviously similar names. They generally do not try to hide their identities or the connections between their relays. See http://torstatus.blutmagie.de/ for an easily browsable list; click on the name of a relay to see more detailed information about it, including the ContactInfo value, if any, specified by the relay's operator. Entities which operate multiple Tor relays can, usually should, and often do use the MyFamily torrc option to indicate that their relays are run by a common operator. If two relays list each other in their MyFamily directives, your Tor client will not include them in the same circuit. Unless you have turned off the EnforceDistinctSubnets torrc option, your Tor client will also not include two relays in the same /16 network in a single circuit. But it wasn't just finding these relays that concerned me. It was Tor's affinity for routing through them. See, I began closing my open circuits systematically. I kept records of any circuits which contained PPrivCom___ or torserversNet_ relays in it. I closed and recorded 43 circuits. Here are my findings: While Tor indicated it had 1665 relays to choose from, 79% of my circuits used one of the suspicious relays. 2% of my circuits used two suspicious relays. 0% of my circuits used three suspicious relays. Of the circuits I recorded, only 21% did not route through a suspicious relay. Tor weights its node selection according to node bandwidth, as specified in the consensus. The consensus, in turn, provides bandwidth values measured by the ‘bandwidth authorities’. This weighting is necessary to balance load fairly throughout the Tor network. There should be multiple bandwidth authorities running, operated by people whom the Tor Project and the directory authority operators trust; as I understand it, there is currently only one running bandwidth
