Re: Do I need an updated .torrc file?
On Mon, 22 Nov 2010 21:51:16 + Matthew pump...@cotse.net wrote: Hello, My .torrc file says: ## Configuration file for a typical Tor user ## Last updated 12 April 2009 for Tor 0.2.1.14-rc. ## (May or may not work for much older or much newer versions of Tor.) Do I need to get a new .torrc version? I have had a look online and cannot find a template. I am using the latest version (0.2.1.26) so see no reason to install from scratch. Any suggestions? Thanks. You only need a new torrc if your current one causes Tor to stop working or emit warning messages. Robert Ransom signature.asc Description: PGP signature
Re: Do I need an updated .torrc file?
On Mon, Nov 22, 2010 at 09:51:16PM +, Matthew wrote: ## Configuration file for a typical Tor user ## Last updated 12 April 2009 for Tor 0.2.1.14-rc. ## (May or may not work for much older or much newer versions of Tor.) Do I need to get a new .torrc version? I have had a look online and cannot find a template. I am using the latest version (0.2.1.26) so see no reason to install from scratch. That's actually the newest version of the default torrc. I update the date and version at the top when I change the file, but I try not to change the file often because every time it changes some of the packages (e.g. Debian) need to interact with the user, to ask if they want to keep their old torrc version or move to the new version. --Roger *** 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
