Project Introduction: ARM
Hi, throughout the summer I've been on a project called 'arm' (anonymizing relay monitor). It's a terminal monitor for Tor relays providing bandwidth/cpu/memory usage, relay configuration, event log, connection details, etc. The project is intended for command-line aficionados, ssh connections, and anyone stuck with a tty terminal for checking their relay's status. More information (including screenshots) is available at ' www.atagar.com/arm'. If this strikes your fancy you can snag a copy of the project with: svn co https://tor-svn.freehaven.net/svn/arm/trunk/ I hope others find it a handy utility. It should be stable so if you manage to make it crash (or have a feature request) then please let me know! Email is best but I'm also usually on the Tor irc channels (my nick is 'atagar'). However, I'm about to head off to the PETS conference so I might be a little slow to respond the next few days. Cheers! -Damian
Re: Measure TOR server traffic
Also, the arm monitor tallies up the BW events (bandwidth usage reported by tor) to provide the totals for the duration that it runs. Cheers! -Damian On Tue, Sep 15, 2009 at 5:33 PM, Andrew Lewman and...@torproject.orgwrote: On 09/15/2009 01:21 PM, Michael Gomboc wrote: I have a tor server running and i like to measure the traffic that goes over it. (inout) Great. Thanks for running a relay! I know there's a way do to that with iptables but I prefer to get this information from TOR. Does TOR store this information somewhere so i could read it with a script? Yes. In your $DataDir there is a state file. It lists your reads and writes over time. You may want to look at dir-spec.txt to get more details, http://git.torproject.org/checkout/tor/master/doc/spec/dir-spec.txt. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject
Re: AN idea of non-public exit-nodes
Interesting idea, but seems like it could be pretty dangerous. If an attacker was able to figure out the subset of Tor users taking advantage of these special exits and ran one themselves then correlation probably wouldn't be too difficult. In addition, abuse issues makes finding exit operators a lot harder than bridges so you probably wouldn't get the vast number of volunteers needed for the current bridge distribution tactics. -Damian On Tue, Nov 24, 2009 at 5:05 PM, Ted Smith ted...@gmail.com wrote: On Tue, 2009-11-24 at 19:49 -0500, Roger Dingledine wrote: See especially point #1: even if we didn't tell clients about the list of relays directly, somebody could still make a lot of connections through Tor to a test site and build a list of the addresses they see. I guess we could perhaps add support for configuring your own secret exit node that your buddy runs for you. But at that point the anonymity that Tor can provide in that situation gets pretty fuzzy. It's like a bridge, but for exits. They would probably have to be a lot less friend-to-friend than bridges, but it might still be doable. I think this is what the original poster meant, anyways.
Re: Path Selection
Hopefully I've got these right... Are the choices of the ORs in the path all based on the advertised bandwidth (Is that the average bandwidth value or the observed)? At the moment weighting is based on advertised bandwidth (with the exception of the entry and exit selection which has special constraints, of course). Mike's currently looking into using observed bandwidth instead. Do the directory servers select which nodes can be Guards (Is there a criteria for this)? Yes. The stable relays are favored to be guards (there might be some other criteria too...). Does the individual client select a few Guards from the valid list of Guards and then only use them as the entry nodes? Yes. An OR being marked as Stable is really just a matter of it staying up and connected to the tor network for long enough? Mostly. There's other considerations, for instance if accounting limit is enabled then you won't be eligible for the stable flag. Cheers! -Damian On Tue, Jan 19, 2010 at 4:20 AM, Jason Cooper j.l.coo...@lboro.ac.ukwrote: Hi, I am trying to get my head round the basics of the path selection for circuits. I am putting together a simple simulator for tor networks to help me understand it and see what effects changing OR values has on the circuits built. I have read http://gitweb.torproject.org/tor/tor.git/blob/HEAD:/doc/spec/path-spec.txtbut I have a few questions. Are the choices of the ORs in the path all based on the advertised bandwidth (Is that the average bandwidth value or the observed)? Do the directory servers select which nodes can be Guards (Is there a criteria for this)? Does the individual client select a few Guards from the valid list of Guards and then only use them as the entry nodes? An OR being marked as Stable is really just a matter of it staying up and connected to the tor network for long enough? Regards, Jason.
Re: Best with limited bandwidth - relay or bridge?
Exit relays are definitely the most useful (thanks for running one!). However, it's preferable to have a fast relay for part of the month rather than a slow relay always available so I'd suggest using AccountingMax rather than RelayBandwidthRate/Burst to stay below your provider's cap. Cheers! -Damian On Sat, Jan 30, 2010 at 2:02 PM, David McKeegan mckee...@mac.com wrote: I've been running an exit relay for about 6 months on my Linode VPS. The bandwidth on my hosting deal is capped at 200Gb per month, so my relay is limited to 50k, bursting to 90k - that keeps it safely around 80% of my monthly bandwidth allocation. I was wondering if switching my service to a bridge would be more useful? I have heard that bridges are in short supply, and I'd like to help out as best as I can. Do I have sufficient bandwidth to do this? Or should I just stick to running my slow exit relay? Any advice appreciated. Dave *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: getinfo circuit-status
Not sure about the first question (my guess would be either multiple circuits are built for added bandwidth or for complimentary exit policies - docs or someone else could answer this). As for the second question, I'm assuming that entries using nickname (verses a fingerprint like $4F0826FA4C325C3CAA0054A6E023E566302C20C7) have the named flag and hence won't have a problem with ambiguity. Unfortunately the control-spec is a little tight lipped on this point so don't blame you for wondering about it. Cheers! -Damian On Sat, Feb 13, 2010 at 12:21 PM, Nico Weinreich i...@web-unity.de wrote: Hi, when interacting with tor control I can get the circuit with command getinfo circuit-status. What's a bit confusing for me, there are more than one circuits: getinfo circuit-status 250+circuit-status= 51 BUILT rueckgrat,myrnaloy,$2DDAC53D4E7A556483ACE6859A57A63849F2C4F6 PURPOSE=GENERAL 50 BUILT Freedom,nixnix,$4744AD962D32A11CD7CF4513617FAC33B339806B PURPOSE=GENERAL 15 BUILT HW2,$4F0826FA4C325C3CAA0054A6E023E566302C20C7,RainCloud PURPOSE=GENERAL 14 BUILT Freedom,SuperDave,bp1 PURPOSE=GENERAL So I have two questions: -which circuit does tor use (is it alway the circuit with the highest number?) -is there a way to get this nodes always as fingerprint (for example, there are many nodes with name idideditheconfig and how do I know which one is it when the node is listed in plain text?) *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Path-spec - fast circuits
+1. I was kinda floored at the logic behind 'since this attack hasn't been used in the wild it should be ignored' but... for each their own. ;) -Damian On Sun, Feb 14, 2010 at 9:16 PM, Flamsmark flamsm...@gmail.com wrote: On 14 February 2010 03:15, Scott Bennett benn...@cs.niu.edu wrote: But one big problem is that you have no guarantee whatsoever that I'm telling you the truth about my measurements. See for example Kevin Bauer et al's Low Resource Routing Attacks Against Tor. Yes, I've understood that from the outset, but I haven't seen any evidence that such abuse is actually happening. Tor isn't just designed to be resilient to attacks that are actually being employed. It is designed to be resistant to theoretical attacks too - as well it should be. Indeed: complaining that we're protecting against attacks, but nobody is using them is like saying `I bought this expensive umbrella, but then I didn't even get wet.': *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Full bandwidth is not used.
I guess arm is using this or something similar to display the bandwidth usage of Tor. Nope, arm just gives a running total of the BW events (ie, if you restart arm the totals will revert to zero). At the moment I'm unaware of a method of getting the total bandwidth besides tallying it (though it's included in a proposal that's currently being batted around on or-dev). Cheers! -Damian On Fri, Mar 5, 2010 at 2:54 PM, Paul Menzel paulepan...@users.sourceforge.net wrote: Am Freitag, den 05.03.2010, 10:17 -0500 schrieb and...@torproject.org: On Fri, Mar 05, 2010 at 09:32:59AM +0100, paulepan...@users.sourceforge.net wrote 1.4K bytes in 39 lines about: : What did you configure for your bandwidth limits or accountingmax? : : I did not configure them and so the defaults are used. arm is displaying : »(cap: 5 MB, burst: 10 MB)«. Ok, then Tor will figure out how much bandwidth it can reliably provide. On what conditions does that depend? If you look at your (datadirectory)/state file, it will show you how much bandwidth tor has been providing over time. I guess arm is using this or something similar to display the bandwidth usage of Tor. Looking at `DataDirectory/state` directly I cannot figure out how to interpret the values. Maybe I need tot enable bandwidth accounting. $ man torrc […] DataDirectory/state A set of persistent key-value mappings. These are documented in the file. These include: - The current entry guards and their status. - The current bandwidth accounting values (unused so far; see below). - When the file was last written - What version of Tor generated the state file - A short history of bandwidth usage, as produced in the router descriptors. DataDirectory/bw_accounting Used to track bandwidth accounting values (when the current period starts and ends; how much has been read and written so far this period). This file is obsolete, and the data is now stored in the ’state’ file as well. Only used when bandwidth accounting is enabled. […] Searching the WWW for »tor state bandwidth« did not help either. Thanks, Paul
Re: Full bandwidth is not used.
Unfortunately the state doesn't provide a complete bandwidth history - if you check on line 1168 of src/or/rephist.c you'll see: /** How many bandwidth usage intervals do we remember? (derived) */ #define NUM_TOTALS (NUM_SECS_BW_SUM_IS_VALID/NUM_SECS_BW_SUM_INTERVAL) This is used later when writing to the state (line 1441 of the same file) - honestly I'm green enough with C that I got lost pretty quick once it started juggling smart lists and buffers around but I'll take the comments at their word ;) This is why I don't use it to populate past bandwidth data in arm. Cheers! -Damian On Sun, Mar 7, 2010 at 3:16 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Am Freitag, den 05.03.2010, 23:54 +0100 schrieb Paul Menzel: Am Freitag, den 05.03.2010, 10:17 -0500 schrieb and...@torproject.org: On Fri, Mar 05, 2010 at 09:32:59AM +0100, paulepan...@users.sourceforge.net wrote 1.4K bytes in 39 lines about: : What did you configure for your bandwidth limits or accountingmax? : : I did not configure them and so the defaults are used. arm is displaying : »(cap: 5 MB, burst: 10 MB)«. Ok, then Tor will figure out how much bandwidth it can reliably provide. On what conditions does that depend? If you look at your (datadirectory)/state file, it will show you how much bandwidth tor has been providing over time. I guess arm is using this or something similar to display the bandwidth usage of Tor. On average arm’s values are the same as the ones in `(datadirectory)/state`. […] Thanks, Paul
Re: [RFC] Campaign »Buy/Sponsor a relay.«
While I understand your concern I disagree since we're already in this boat. I'm currently running a relay with Comcast as my ISP, and if I was going to run an exit I'd go back to the past list correspondence about low-hassle (tor friendly) hosting solutions. In both cases my ISP or hosting provider are seeing the traffic of hundreds of tor relays. They're the points of potential mass data aggregation we should be concerned about for this sort of large scale eavesdropping, not necessarily the relay's operators. Hence, as long as any hosting entity properly set the 'Family' parameter, I think we should welcome this sort of hired-relay-operation. The proper countermeasure for this problem (imho) would be to grant relays an implied family based on geoip data and known ISP/hoster ip ranges (ie, don't make my circuit through multiple relays hosted by Comcast or, say, in the US). Just my two cents... cheers! -Damian On Wed, Mar 10, 2010 at 8:41 AM, Andrew Lewman and...@torproject.orgwrote: On Wed, 10 Mar 2010 11:26:00 +0100, Paul Menzel paulepan...@users.sourceforge.net wrote: :on the Tor start page [1] there is a message »Help us reach 5,000 : relays in 2010!« :»I guess for people caring about privacy but not wanting/able to set up :a server themselves can now be told, you can pay 90 pounds a month [for :10 Mbps] and you will improve the connectivity of the Tor network.« [me :on IRC] We turn down funding when organizations ask us to run relays on their behalf. They have the money, but not the technical skills to run relays. The risk to The Tor Project, the non-profit entity, is that we become a target as we could potentially see a large percentage of Tor network traffic. This traffic becomes interesting to law enforcement, criminal organizations, marketers, and others wanting to enumerate Tor users. This same concern is true for the funding organization. A human rights organization wanted to run either hundreds of relays or to see their relay names as the top 10 relays in the Vidalia network map for a year. They almost looked at the network map/relay list as a branding opportunity. However, controlling relays with that much traffic, even if the relays are dispersed around the world, would turn them into a data collection target. I encourage a peer to peer model of getting more relays. Having individuals run a relay and contribute the bandwidth that makes sense seems to be a less risky model. As the risk is spread out amongst hundreds or thousands of individuals. This is a more difficult path than turning lots of money into relays. Ultimately, I believe this path is more sustainable in the long-term. As committed relay operators run them for their own reasons, not for a paycheck. Active areas of research are around everyone as a bridge and everyone as a relay if the tor client finds itself reachable by the outside world. Getting these options correct without screwing users is difficult. However, we are making progress. In the meanwhile, we need more relays, in particular exit relays, to help speed up Tor for everyone. -- Andrew Lewman The Tor Project pgp 0x31B0974B Website: https://www.torproject.org/ Blog: https://blog.torproject.org/ Identi.ca: torproject *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: [RFC] Campaign »Buy/Sponsor a relay.«
StrangeCharm and I just had an interesting conversation about this. In short, while this suggestion would diversify trust it would also reduce the entropy of node selection. Not sure which is more important (I'd suspect the former, but could be argued). Cheers! -Damian (09:30:17 PM) StrangeCharm: hey (09:31:44 PM) Me: hey there (09:31:57 PM) StrangeCharm: i just read your or-talk posting (09:32:06 PM) Me: ah - thoughts? (09:32:46 PM) StrangeCharm: if we have a small number of really large families, don't the potential anonymity sets get much smaller? (09:33:29 PM) Me: we already have that situation (say, 500 with comcast, 300 with centurytell, 100 with dreamhost, etc) (09:34:09 PM) Me: if we're worried about relay operators as the point of failure then yes, big networks like this are bad (09:34:52 PM) StrangeCharm: you're suggesting that we already have these large 'families', over which end-to-end observation is possible, they're just not well marked? (09:34:57 PM) StrangeCharm: (and therefore evaded) (09:35:04 PM) Me: yup (09:35:55 PM) StrangeCharm: i see. (09:36:56 PM) StrangeCharm: i take it that you'd argue that we should protect against possible surveillance by known groups, whether or not we think it's occurring, even if it has some mild privacy deficits elsewhere? (09:38:10 PM) Me: don't follow what you mean by mild privacy defects - but yes, tor's designed to distribute trust (ie, that no one in the network can hurt you) and distributing the trust some more is a good thing (09:38:55 PM) StrangeCharm: well, if we recommend that nobody connects through multiple comcast nodes, the anonymits sets are smaller (09:41:04 PM) Me: Hmmm, I see what you mean - yea, you might have a point (though I think we're we're more interested in diversified trust than greater entropy of node selection). We'll see what the tor devs think. (09:41:30 PM) StrangeCharm: they tend to have good intuitions about these sorts of things (09:41:36 PM) Me: Mind if I post this conversation on the thread? It brings up a good point. (09:41:47 PM) StrangeCharm: go right ahead (09:41:49 PM) Me: thx On Wed, Mar 10, 2010 at 9:24 PM, Damian Johnson atag...@gmail.com wrote: While I understand your concern I disagree since we're already in this boat. I'm currently running a relay with Comcast as my ISP, and if I was going to run an exit I'd go back to the past list correspondence about low-hassle (tor friendly) hosting solutions. In both cases my ISP or hosting provider are seeing the traffic of hundreds of tor relays. They're the points of potential mass data aggregation we should be concerned about for this sort of large scale eavesdropping, not necessarily the relay's operators. Hence, as long as any hosting entity properly set the 'Family' parameter, I think we should welcome this sort of hired-relay-operation. The proper countermeasure for this problem (imho) would be to grant relays an implied family based on geoip data and known ISP/hoster ip ranges (ie, don't make my circuit through multiple relays hosted by Comcast or, say, in the US). Just my two cents... cheers! -Damian On Wed, Mar 10, 2010 at 8:41 AM, Andrew Lewman and...@torproject.orgwrote: On Wed, 10 Mar 2010 11:26:00 +0100, Paul Menzel paulepan...@users.sourceforge.net wrote: :on the Tor start page [1] there is a message »Help us reach 5,000 : relays in 2010!« :»I guess for people caring about privacy but not wanting/able to set up :a server themselves can now be told, you can pay 90 pounds a month [for :10 Mbps] and you will improve the connectivity of the Tor network.« [me :on IRC] We turn down funding when organizations ask us to run relays on their behalf. They have the money, but not the technical skills to run relays. The risk to The Tor Project, the non-profit entity, is that we become a target as we could potentially see a large percentage of Tor network traffic. This traffic becomes interesting to law enforcement, criminal organizations, marketers, and others wanting to enumerate Tor users. This same concern is true for the funding organization. A human rights organization wanted to run either hundreds of relays or to see their relay names as the top 10 relays in the Vidalia network map for a year. They almost looked at the network map/relay list as a branding opportunity. However, controlling relays with that much traffic, even if the relays are dispersed around the world, would turn them into a data collection target. I encourage a peer to peer model of getting more relays. Having individuals run a relay and contribute the bandwidth that makes sense seems to be a less risky model. As the risk is spread out amongst hundreds or thousands of individuals. This is a more difficult path than turning lots of money into relays. Ultimately, I believe this path is more sustainable in the long-term. As committed relay operators run them for their own reasons, not for a paycheck. Active areas of research
Re: New GETINFO option, bytes
Thanks Anders! You're right - this is a highly requested piece of information (dozens of times at least this year). If this makes it into the control spec it might be nice to include an option for the total bytes downloaded/uploaded verses since the last reset (sighup). Regardless, keeping my fingers cross that something like this makes it in. Cheers! -Damian PS. This option was included in a proposal that's currently in limbo, which might give a possible option name: http://archives.seul.org/or/dev/Mar-2010/msg9.html On Tue, Mar 23, 2010 at 4:20 PM, Anders Andersson pipat...@gmail.comwrote: Hi. I added a new option for GETINFO, that will return the total number of bytes that's gone through Tor since process startup. Just exporting the internal stats_n_bytes_read/written. This is very useful for retrieving statistics like bandwidth over time, for use with tools like arm, vidalia, munin, and other monitoring applications. The current method that use events is difficult to use, since you have to listen all the time. With the new method you can for example poll every minute to see how many bytes was transferred in total since last you checked. I wrote a plugin for munin that use this new feature, and it works great. The patch is trivial, and you probably want to change the name of the command if you want to use it. There might also be reasons that you don't want to export and print uint64_t variables. I didn't take time to check any tor internals guidelines. // pipe
Re: [GSoC] Improving Snakes on a Tor
Hi there John - glad to have you working with Tor! We're really anxious to see where you go with this project since, as exemplified by the recent incident with PrivacyNow [0], we're currently pretty miserable about noticing and flagging bad exits. Unfortunately our definition of a bad exit is pretty vague [1]: BadExit if the router is believed to be useless as an exit node (because its ISP censors it, because it is behind a restrictive proxy, or for some similar reason). An easy place to start would be to solicit input on or-talk for a better definition and enumerable attributes we can look for. Some obvious starting ones would be ssl stripping, certificate tampering (checking for differences like the Perspectives addon [2]), and bad DNS responses. I'd imagine Scott Bennett would be glad to jump in with some more ideas. :) Also, have you thought about setting up a site or blog where people can check how things are coming along? Here's what I did when doing GSoC with the SIP Communicator project: http://www.atagar.com/misc/gsocBlog/ Again, glad to have you and looking forward to working with you this summer! -Damian [0] http://archives.seul.org/or/talk/Apr-2010/msg00120.html [1] http://gitweb.torproject.org/tor.git?a=blob_plain;hb=HEAD;f=doc/spec/dir-spec.txt [2] http://www.cs.cmu.edu/~perspectives/index.html On Fri, Apr 30, 2010 at 9:15 PM, John M. Schanck jm...@hampshire.eduwrote: Hi or-talk, My name is John Schanck, I'm a third year CS student at Hampshire College, and I'll be working with Tor this summer through Google Summer of Code. First, let me say how excited I am to have this opportunity - I've been following the Tor project for several years now and can think of no better place to devote my efforts. Many thanks to those of you who read my proposal, especially Mike Perry who has graciously agreed to mentor the project, and Damian and Erinn who have also offered up some of their time. I'm going to be working on improving the Snakes on a Tor (SoaT) exit scanner. For those of you not familiar with it, SoaT aims to detect malicious, misconfigured, or heavily censored exit nodes by comparing the results of queries fetched across those exits to results obtained without Tor. It's an ambitious project, originally developed by Mike Perry and crafted into its current form by Aleksei Gorney during GSoC 2008, so my goals are modest. I'm going to begin by stabilizing the existing codebase, and then work on minimizing the number of false positives generated by the current filters. If time permits I'll also begin designing new filters to handle adversaries not yet accounted for. If you'd like to talk about the project (or just say hello), you can find me on OFTC under the nickname 'susurrusus'. Cheers, John PS. Congratulations to the other accepted students, I look forward to meeting you and hearing about your projects :). -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEAREDAAYFAkvbquAACgkQke2DTaHTnQlItQCgkFWuzOYTTA1ctpRTaa54q5Zf kmAAnR5Z8jzMOaFErAkSXyGEdtRbXbBJ =9a6k -END PGP SIGNATURE-
Re: GSoC Introduction - Extending Tor Network Metrics
Hi GD. I'd imagine the acronym in this case is very well known to most people here, since it's the location of the tor irc channels. It's also plenty unique and search able - if it was an alternative definition of, say, 'SOAP', then I'd fully agree with you. -Damian On Sat, May 1, 2010 at 8:49 PM, downie - downgeo...@hotmail.com wrote: Date: Sat, 1 May 2010 17:12:45 -0400 Subject: GSoC Introduction - Extending Tor Network Metrics From: xckj...@gmail.com To: or-talk@freehaven.net Hey everyone, I'm Kevin Berry, one of the GSoC students working for Tor this summer. Originally from New Jersey, I'm currently a junior at Villanova University in Philadelphia. I will be guided by Karsten on Extending Tor Network Metrics. My plans revolve around porting Ernie (the metrics portal software) to a dynamic web application. I will add a search feature to the *large* amount of relay descriptor data (for specific items like server names, characteristics), and automate the collection and publishing of a few high-level network statistics. If you haven't yet read my initial proposal, I'm including it here: http://kjb.homeunix.com/files/gsoc2010_tor_application.html . The timeline was made a bit more specific since I submitted it. Lots to do! I plan on hosting my GSoC blog and project at http://kjb.homeunix.com . Since a bit of my project involves web development, I plan to have snapshots of my project hosted there. It's a dynamic dns domain pointing to a box at home, so I apologize if it is slow/unreliable at times. I'm usually idling in oftc and freenode as kjbbb. I've already met a few of you, but definitely feel free to drop me a line. I will be around a lot more often after finals end next week, so I will have time to set up, ask questions, and get ready to begin working this summer. I'm excited to be able to dedicate my full time to open source and Tor, so thank you Google and everyone else involved for giving me this great opportunity! Kevin It's good to read that people are working to improve Tor. Welcome. However, that's the second unexplained reference to OFTC - do you mean http://www.oftc.net/oftc/ ? It's best not to assume that acronyms are understood by everyone...we don't all move in the same circles. GD -- Hotmail is redefining busy with tools for the New Busy. Get more from your inbox. See how.http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_2
Re: [GSoC] Improving Snakes on a Tor
One thing I would really like help with is compiling a list of reasons for which nodes have been given the BadExit flag. Hi John. Here's a couple more past discussions concerning bad exits: JustaNode (ssl mitm?) - http://www.mail-archive.com/or-talk@freehaven.net/msg11540.html spacecowboy (content injection?) - http://www.mail-archive.com/or-talk@freehaven.net/msg10998.html There's currently four relays marked as a bad exit according to http://torstatus.blutmagie.de *capoteATWO* Misconfiguration - http://archives.seul.org/or/relays/Apr-2010/msg00108.html http://torstatus.blutmagie.de/router_detail.php?FP=dd0f0a72a773ed5f2ea298be0dd1177560f97a9a *networkcc958ca* / *netwroke421d2a* Not really sure why... kinda weird since it's not configured to be an exit anyway (Reject */*) http://torstatus.blutmagie.de/router_detail.php?FP=7621f6493a49a4f9da13ff89ca75a08316993a31 http://torstatus.blutmagie.de/router_detail.php?FP=db0e1ce11e3ac37eb4190ffde7653eae9cbdbf20 *PrivacyNow* Misconfiguration (DNS) http://torstatus.blutmagie.de/router_detail.php?FP=cf8e39514ddd90512ebe6498ded006419b0d8f85 Cheers! -Damian On Sun, May 16, 2010 at 9:26 PM, John M. Schanck jm...@hampshire.eduwrote: -BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 On Sat, May 15, 2010 at 11:58:44PM -0400, Roger Dingledine wrote: On Sat, May 15, 2010 at 06:37:54PM -0700, Damian Johnson wrote: Hmmm... so we aren't interested in having a clearer definition of what makes up a bad exit? From the following I thought this is something we were interested in John looking into: On the bright side though, it's looking good that we'll be able to get a google summer of code student to revive Mike Perry's Snakes on a Tor project, and hopefully that means we will a) have some automated scans looking for really obviously broken relays, and *b) build a clearer policy about what counts as badexit and what doesn't, so we can react faster next time.* [0] Good point. I didn't mean to discourage him from working on more than one direction at once. I suspect that working on good clean tests that don't produce false positives, and setting up the infrastructure to automatically launch them and gather results, is something that can actually be clearly accomplished and finished; whereas trying to sort out the right balance between subtly not working right and still worth letting ordinary users exit from is a rat-hole that may well lead to madness plus no useful results. In short, it sounds like both are worth pursuing in parallel. :) I definitely think both can be pursued in parallel. I've set up a blog for documenting my progress, http://anomos.info/~john/gsochttp://anomos.info/%7Ejohn/gsoc, the most recent post (5/17/2010) is about the goals of SoaT, and the definition of BadExit. One thing I would really like help with is compiling a list of reasons for which nodes have been given the BadExit flag. I've collected information on seven cases where a BadExit flag was given, or suggested, but I'm sure there are others. This strikes me as something very easy he could do to both: 1. start integrating with the community more (all the gsoc students have been very quiet so far, hence I'm trying to encourage him to spark a discussion on or-talk) Had to finish up finals ;-) 2. it'll provide ideas of things that SoaT can look for later for both misconfigured and malicious exits I agree that we should try and either fix or find safe ways of using bad exits, and that using SoaT to try and protect the network from all the evils exit relays can dish at us is an arms race we'd lose. However, for many of the nastier active attacks like sslstrip I don't see why we should be waving the white flag right away. Cheers! -Damian Yep. Is there a list somewhere of what active attacks SoaT would like to defend against, and how to do each of the corresponding tests? I remember Mike originally designed SoaT to have a secret config file, so bad guys couldn't learn what the tests are. https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/README.ExitScanning https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/soat_config.py While I can see some reasons for doing it that way, that shouldn't stop us from documenting whatever we can publically. https://svn.torproject.org/svn/torflow/trunk/NetworkScanners/ExitAuthority/data/soat/ should give us a few hints about what Mike was thinking. I'm starting to build a list of the attacks SoaT should defend against; I'm confident that we can be completely public about what those attacks are, as well as what our defenses are - although I'd like Mike's input on that. The secret config file you mention is less about obscuring which tests are being run, and more about not publishing the fingerprintable characteristics of the scanner (rates at which certain operations occur
Re: Reducing relays = reducing anonymity ? Tortunnel.
Does anybody use tortunnel ? Never heard of it before, so doubt it. Is tortunnel evil since it maybe hacks Tor-cirucits to reduce the number of relays ? We discourage people from reducing the circuit length since it cripples the anonymity tor provides, makes exit nodes more tasty targets since they can correlate users to exit traffic, etc. There's been several discussion of this in the archives. Where is the security/anonymity reduction since tortunnel also uses Tor ? It's equivalent to using a single hop proxy. Can Tor itself reduce the number of relays (like tortunnel) ? No, nor do we want it to. Cheers! -Damian On Wed, May 19, 2010 at 9:06 AM, Attac Heidenheim heidenh...@attac.dewrote: Hi everybody, I just tried a little tool called Tortunnel which allows a user to tunnel Tor via Privoxy/Polipo to any selected exitnode. Just one hop instead of three relays. Of course, if the exitnode ist evil, you're lost, but it really speeds up the whole thing on the other hand. Website: http://www.thoughtcrime.org/software/tortunnel/ My questions: Does anybody use tortunnel ? Is tortunnel evil since it maybe hacks Tor-cirucits to reduce the number of relays ? Where is the security/anonymity reduction since tortunnel also uses Tor ? Can Tor itself reduce the number of relays (like tortunnel) ? Greetings, Niklas
Re: Answer by perfect-privacy.com Re: perfect-privacy.com, Family specifications, etc.
The trick is that both parties need to list each other as family for this to work. As per the man page.. When two servers both declare that they are in the same 'family'... The attacker would need to be listed in every other relay's torrc for the attack you described to work. I'm pretty sure listing relays you don't control has no effect. -Damian On Wed, May 19, 2010 at 11:29 PM, Scott Bennett benn...@cs.niu.edu wrote: On Thu, 20 May 2010 08:23:34 +0200 (CEST) Sebastian Hahn m...@sebastianhahn.net wrote: All that would do would be to say to all clients, Don't include this node in the same circuit as any of the blutmagie nodes. How would that be an attack? I can list all the nodes I don't control... What is the limit on line length for such a MyFamily statement? What is the limit on descriptor length? Listing ~1500 nodes sounds like the sort of thing that wouldn't work very well. Also, my other question remains: what would stop me from listing nodes that I don't control in a MyFamily statement now? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Answer by perfect-privacy.com Re: perfect-privacy.com, Family specifications, etc.
Oops, apologies - didn't realize this had already been answered. (a pox upon thread forking...) On Thu, May 20, 2010 at 7:03 AM, Damian Johnson atag...@gmail.com wrote: The trick is that both parties need to list each other as family for this to work. As per the man page.. When two servers both declare that they are in the same 'family'... The attacker would need to be listed in every other relay's torrc for the attack you described to work. I'm pretty sure listing relays you don't control has no effect. -Damian On Wed, May 19, 2010 at 11:29 PM, Scott Bennett benn...@cs.niu.eduwrote: On Thu, 20 May 2010 08:23:34 +0200 (CEST) Sebastian Hahn m...@sebastianhahn.net wrote: All that would do would be to say to all clients, Don't include this node in the same circuit as any of the blutmagie nodes. How would that be an attack? I can list all the nodes I don't control... What is the limit on line length for such a MyFamily statement? What is the limit on descriptor length? Listing ~1500 nodes sounds like the sort of thing that wouldn't work very well. Also, my other question remains: what would stop me from listing nodes that I don't control in a MyFamily statement now? 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 * ** *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Some sites recognize TOR
This is not something to be 'fixed', see: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ and search for You should hide the list of Tor relays, so people can't block the exits. (sorry about the lack of an anchor, guess it was lost in the move to trac). Cheers! -Damian On Fri, May 21, 2010 at 8:37 AM, Jerzy Łogiewa jerz...@interia.eu wrote: Wow! And how can this be fixed? Ultimately this makes blocking Tor a lot easier! -- Jerzy Łogiewa -- jerz...@interia.eu On May 21, 2010, at 9:08 AM, Karsten N. wrote: or fetching the exit node list from a tor status site like: https://torstatus.kgprog.com/ip_list_exit.php/Tor_ip_list_EXIT.csv or fetching it from check.torproject.org https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=xx.xx.xx.xx -- Sprawdź jak zadbać o życie. http://clk.tradedoubler.com/click?p=191431a=1694818g=18733532 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Some sites recognize TOR
Doh! My stupidity, sorry. Here's the anchored link: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ#YoushouldhidethelistofTorrelayssopeoplecantblocktheexits . -Damian On Fri, May 21, 2010 at 9:20 AM, Damian Johnson atag...@gmail.com wrote: This is not something to be 'fixed', see: https://trac.torproject.org/projects/tor/wiki/TheOnionRouter/TorFAQ and search for You should hide the list of Tor relays, so people can't block the exits. (sorry about the lack of an anchor, guess it was lost in the move to trac). Cheers! -Damian On Fri, May 21, 2010 at 8:37 AM, Jerzy Łogiewa jerz...@interia.eu wrote: Wow! And how can this be fixed? Ultimately this makes blocking Tor a lot easier! -- Jerzy Łogiewa -- jerz...@interia.eu On May 21, 2010, at 9:08 AM, Karsten N. wrote: or fetching the exit node list from a tor status site like: https://torstatus.kgprog.com/ip_list_exit.php/Tor_ip_list_EXIT.csv or fetching it from check.torproject.org https://check.torproject.org/cgi-bin/TorBulkExitList.py?ip=xx.xx.xx.xx -- Sprawdź jak zadbać o życie. http://clk.tradedoubler.com/click?p=191431a=1694818g=18733532 *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: shadowserver.org
Probably because your exit node is being used to do something that warrants an abuse report. Maybe, but if this shadowserver site is being incommunicado then I wouldn't put much confidence in their findings. Stop the activity on your exit node that is causing them to lodge reports? Very bad advice. Snooping on exit traffic (or tampering it in any way) are * highly* discouraged. -Damian On Mon, Jun 14, 2010 at 10:46 AM, Al MailingList alpal.mailingl...@gmail.com wrote: I am running the exit-node tor-readme.spamt.net. My provider, server4you, keeps getting abuse reports from shadowserver.org. According to the abuse service they are running honeynets which record activity comming from my exit-node's IP. I have tried to communicate directly with shadowserver.org but got no answer. Does anybody have experience with those guys? I mean, they should know what tor is and that their abuse reports create nothing but work and anger for everybody. So why do they do it then? Probably because your exit node is being used to do something that warrants an abuse report. For the moment I have to close abuse tickets on a weekly basis. I could live with that, but I would prefer solving the issue. Any recommendations on what I could do? Stop the activity on your exit node that is causing them to lodge reports? regards Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkwWNngACgkQevm6Dd/q44myVACfT861jycouvMLo1gcMiJUeBva vJkAn0lwpncn8Vs5W4HIHa+tzf1bPAEj =zuoD -END PGP SIGNATURE- *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Using Authority Servers (directory authorities) as Entry Nodes?
No. The directory authorities determine the consensus. They are not capable of figuring out what relays you've picked from it for your circuits. I'm kinda confused why you want to use them for your entry nodes. Setting StrictEntryNodes this way harms your anonymity since you're only making use of a tiny subset of the tor network for the first hop (most clients pick among a few guards for their hop, not directory authorities, and anything that differentiates you from other tor users is bad). -Damian On Fri, Jul 2, 2010 at 6:58 AM, judaiko judaiko siriu81...@gmail.comwrote: Nodes: dizum, Tonga, dannenberg, maatuska are identified as being Authority Servers on https://torstatus.blutmagie.de I set the following in my torrc file: EntryNodes dizum, Tonga, dannenberg, maatuska StrictEntryNodes 1 Is my anonymity broken as the above nodes are Authority Servers, therefore they can log and identify the flow of traffic, mapping destination and sources? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor-proxy.net is official proxy site of TOR?
No, it's not related to tor and be aware that the design (shown in their FAQ) looks like you're sending your traffic via this Tor-Proxy.net thing, which means you're trusting them in the same fashion as a single hop proxy. -Damian On Wed, Jul 21, 2010 at 8:14 AM, emigrant fromwindowstoli...@gmail.comwrote: or is it safe enough? thanks a lot. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: gratuitous change blocks upgrade to 0.2.2.15-alpha :-(
Just a heads up that there *has* been torrc validation in arm for quite some time now. Warnings about this issue (unused entries due to duplicates) have been given since release 1.2.2 (11/8/09, so bit less than a year now). I just tested and it has been giving warnings about ExcludeNodes all this time (root cause is that only entries with LINELIST and LINELIST_S in src/or/config.c can be duplicates). If others have ideas for additional validation I can do on user's torrc files then I'd love to know. Cheers! -Damian On Fri, Sep 10, 2010 at 1:05 AM, Sebastian Hahn m...@sebastianhahn.netwrote: On Sep 10, 2010, at 9:57 AM, Scott Bennett wrote: On Fri, 10 Sep 2010 03:39:44 -0400 Roger Dingledine a...@mit.edu wrote: As I understand it, we changed no behavior except printing out a warn for people who had multiple lines, to tell them that they're expecting behavior that they're not getting. [extremely shocked pause...] . . . Roger, please tell me that you're joking. I have *never* had the understanding from reading the documentation in all of the years I've been using tor that only a single line of each type would be used. How, then, are we to exclude all of the nodes that we find unacceptable for use in our own circuits? If what you say is actually the case, then it would seem that a problem described on this list on many occasions during the last few years may, in fact, have been due to this horrible limitation. Several of us have complained on numerous occasions that adding a node to one list or the other and sending SIGHUP to tor (or restarting it) failed to prevent that node from being used in the manner that we had expressly excluded. If what you say is indeed the case, then it is a truly awful design bug. Yup, that's the actual behaviour. Good thing we added the warn, otherwise it might have gone unnoticed longer. Sebastian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: tor-ramdisk 20101011 released for i686 only
One option for providing feedback on the health of the relay would be arm ( www.atagar.com/arm) with the following config changes to keep with the aims of tor-ramdisk: # would prevent any connection related information from being queried startup.blindModeEnabled true # crops log messages after a day features.log.entryDuration 1 This would provide the user with: - ps information (cpu/mem usage, uptime) - basic relay information (fingerprint, flags held, version, etc) - config (currently loaded torrc) - the last day's worth of logs - graph of the bandwidth usage The last two give a very good indication for if the relay's working right or not. If this is too much information then I'd be happy to augment arm to meet your needs. Cheers! -Damian On Mon, Oct 11, 2010 at 8:25 PM, Anders Andersson pipat...@gmail.comwrote: On Mon, Oct 11, 2010 at 11:16 PM, Jacob Appelbaum ja...@appelbaum.net wrote: On 10/11/2010 10:52 AM, Anthony G. Basile wrote: Hi everyone I want to announce to the list that a new release of tor-ramdisk is out. Tor-ramdisk is an i686, x86_64 or MIPS uClibc-based micro Linux distribution whose only purpose is to host a Tor server in an environment that maximizes security and privacy. Security is enhenced by hardening the kernel and binaries, and privacy is enhanced by forcing logging to be off at all levels so that even the Tor operator only has access to minimal information. Finally, since everything runs in ephemeral memory, no information survives a reboot, except for the Tor configuration file and the private RSA key, which may be exported/imported by FTP. Via FTP? It's probably not a good idea to export a private key without using encryption... All the best, Jake My first thought as well. Pretty much every protocol invented is better than FTP, in this case and most other cases. Another question regarding the logging: I hope you include enough to know if the node is working correctly or not. The logs that are generated could also be deleted after a couple of minutes or an hour as well, which might make it possible to log some more information if necessary to verify functionality. Great project though, a lot of people request this. *** 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 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
Arm Release 1.4.0
Hi. After over a year it's about time that I announced an arm release so here it is! What's new since August of 2009 [1], you ask? Lots. The project has been under very active development, continuing to add usability improvements to make relay operation nicer and less error prone. If you're really curious what I've been up to this last year then it's all available in the change log [2]. For those unfamiliar, arm is a terminal monitor for Tor relays and, to a growing extent, end users. It provides: * resource usage (bandwidth, cpu, and memory usage) * general relaying information (nickname, fingerprint, flags, or/dir/controlports) * event log with optional regex filtering and deduplication * connections correlated against tor's consensus data (ip, connection types, relay details, etc) * an editor to quickly alter Tor's configuration * torrc configuration file with syntax highlighting and validation and quite a bit more via a curses interface. For screenshots and downloads visit: http://www.atagar.com/arm/ Peter and I are currently working on getting its debs in shape so hopefully this'll soon be available via repositories for Debian and Ubuntu too. RPM builds are available, though I don't have a test system so beware: there be dragons (possibly). If there's any python hackers out there interested in dabbling in a bit of Tor UI development, then I'd love to have some company. Suggestions, bug reports and feedback are also be very welcome. Cheers! -Damian [1] http://archives.seul.org/or/talk/Aug-2009/msg00040.html [2] http://www.atagar.com/arm/log.php *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
Arm should work just fine under BSD with the exception of the connection listing. The problem there is that FreeBSD's netstat lacks the flag to list the pids associated with connections (so I can't narrow the list to tor connections), ss is a completely different program (a spreadsheet application instead of connection resolver), and lsof either had similar issues, though I don't recall exactly what. If you know a method of getting the connections for a given process under FreeBSD then I'm all ears. :) That said, everything else (bandwidth graph, logging, configuration editing, etc) should work just fine. -Damian On Tue, Nov 30, 2010 at 10:56 PM, John Case c...@sdf.lonestar.org wrote: Hi Damian, On Tue, 30 Nov 2010, Damian Johnson wrote: Hi. After over a year it's about time that I announced an arm release so here it is! What's new since August of 2009 [1], you ask? Lots. The project has been under very active development, continuing to add usability improvements to make relay operation nicer and less error prone. If you're really curious what I've been up to this last year then it's all available in the change log [2]. Any news on getting all of Arms functions to work under FreeBSD ? Thanks. *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
The lsof command issued by arm [1] is: lsof -nPi | grep process\s*pid.*(ESTABLISHED) I'd be happy to work with you to provide a fix, if you'd like. Once upon a time I tried to use VMs to troubleshoot FreeBSD and Gentoo issues (thus far they're the only platforms to give arm any trouble). However, either VirtualBox, those OSes, or the combination of the two made this a colossal pain in the ass. Trying to wrangle even the most basic functionality out of those systems chewed up dozens of hours so that's definitely *not* a road I'm going down again. What I'll need from you is the following: - A command that, when executed as the tor user, produces connection results filtered to tor's connections. - Example output. - Be available to test a potential fix. If you're up for that then I'm glad to have the help! Lets take further discussion of this off the list. I don't think this is generally of interest to the rest of the tor community. -Damian [1] https://svn.torproject.org/svn/arm/trunk/src/util/connections.py On Wed, Dec 1, 2010 at 10:34 PM, John Case c...@sdf.lonestar.org wrote: On Wed, 1 Dec 2010, Damian Johnson wrote: Arm should work just fine under BSD with the exception of the connection listing. The problem there is that FreeBSD's netstat lacks the flag to list the pids associated with connections (so I can't narrow the list to tor connections), ss is a completely different program (a spreadsheet application instead of connection resolver), and lsof either had similar issues, though I don't recall exactly what. If you know a method of getting the connections for a given process under FreeBSD then I'm all ears. :) Right - I've been familiar with the limitation, and the reason for the limitation, for the lifetime of your project. I run Arm very well on FreeBSD, but I'd really love to have the connection listing ... Can you use this: http://lists.freebsd.org/pipermail/freebsd-questions/2007-November/162970.html to cross reference, and get what you need ? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
Perfect! I'll try to provide a fix for you to test later today or tomorrow. I intent to try Arm in the future. Are you aware of anyone working on a port? Nope. Jesse just finished an ebuild for Gentoo: https://bugs.gentoo.org/show_bug.cgi?id=341731 and I'm working with Peter on a deb. But thus far no one has volunteered to do a bsd port. On Fri, Dec 3, 2010 at 11:34 AM, Fabian Keil freebsd-lis...@fabiankeil.de wrote: Damian Johnson atag...@gmail.com wrote: The lsof command issued by arm [1] is: lsof -nPi | grep process\s*pid.*(ESTABLISHED) I'd be happy to work with you to provide a fix, if you'd like. Once upon a time I tried to use VMs to troubleshoot FreeBSD and Gentoo issues (thus far they're the only platforms to give arm any trouble). However, either VirtualBox, those OSes, or the combination of the two made this a colossal pain in the ass. Trying to wrangle even the most basic functionality out of those systems chewed up dozens of hours so that's definitely *not* a road I'm going down again. What I'll need from you is the following: - A command that, when executed as the tor user, produces connection results filtered to tor's connections. - Example output. tor-jail# uname -or FreeBSD 9.0-CURRENT tor-jail# su -m _tor -c /bin/csh tor-jail# id uid=256(_tor) gid=256(_tor) groups=256(_tor) tor-jail# procstat -f `pgrep tor` | egrep 'TCP|UDP|PID' PID COMM FD T V FLAGS REF OFFSET PRO NAME 3561 tor 4 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:22370 3561 tor 5 s - rw---n-- 2 0 TCP 10.0.0.2:9050 0.0.0.0:0 3561 tor 6 s - rw---n-- 2 0 TCP 10.0.0.2:9040 0.0.0.0:0 3561 tor 7 s - rw---n-- 2 0 UDP 10.0.0.2:53 0.0.0.0:0 3561 tor 8 s - rw---n-- 2 0 TCP 10.0.0.2:9051 0.0.0.0:0 3561 tor 14 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:44381 3561 tor 15 s - rw---n-- 2 0 TCP 10.0.0.2:33734 [scrubbed]:443 3561 tor 16 s - rw---n-- 2 0 TCP 10.0.0.2:47704 [scrubbed]:9001 3561 tor 17 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:46343 3561 tor 18 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:64196 3561 tor 19 s - rw---n-- 2 0 TCP 10.0.0.2:18856 [scrubbed]:443 3561 tor 20 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:20385 3561 tor 22 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:27541 3561 tor 23 s - rw---n-- 2 0 TCP 10.0.0.2:9050 10.0.0.1:21877 (Public IP addresses scrubbed) - Be available to test a potential fix. If you're up for that then I'm glad to have the help! Lets take further discussion of this off the list. I don't think this is generally of interest to the rest of the tor community. -Damian It's at least interesting to a part of the rest of the tor community. I intent to try Arm in the future. Are you aware of anyone working on a port? Fabian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
Hi all. I've checked in the resolver fixes (thank Fabian and Hans!) and a test tarball is available at: http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2 http://www.atagar.com/transfer/tmp/arm_bsdTest.tar.bz2.asc I've added both of the commands you mentioned as fallback resolvers. On Ubuntu procstat doesn't exist but sockstat does, so I've also added handling for its Linux version too: ata...@fenrir:~$ sockstat | egrep tor\s*3475.*ESTABLISHED atagar tor29672tcp4 192.168.0.3:36511scrubbed:9001 ESTABLISHED atagar tor29672tcp4 192.168.0.3:45906scrubbed:9001 ESTABLISHED atagar tor29672tcp4 192.168.0.3:60202scrubbed:4430 ESTABLISHED atagar tor29672tcp4 192.168.0.3:34600scrubbed:9001 ESTABLISHED ... For BSD I'm using the following commands: sockstat -4 | egrep 'process\s*pid' | grep -v '*:*' procstat -f 'pgrep process' | grep 'pid' | grep -v '0.0.0.0:0' The purpose of these greps is to only get established connections and to filter by the pid (in case there's multiple tor instances). To test please do the following: 1. Run arm at its debug runlevel (arm -e 1) 2. Arm defaults to the bsd resolvers if os.uname() matches FreeBSD. Please look for an entry like the following in your logs (it'll be near the start): 18:50:00 [ARM_INFO] Operating System: FreeBSD, Connection Resolvers: sockstat (bsd), procstat (bsd) if it doesn't match that then let me know what it says. 3. Go to arm's second page and press u to bring up the resolver options. Regardless of the OS detected it will have: * auto * netstat * ss * lsof * sockstat * sockstat (bsd) * procstat (bsd) 4. Select one of the bsd options. If it doesn't work then the results will be unchanged (ie, if options were already listed then they'll still be listed so don't trust that, please still check the following step for both). 5. Go back to the log. You'll see an entry like: 18:16:31 [ARM_DEBUG] system call: sockstat -4 | egrep 'tor\s*29672' | grep -v '*:*' (runtime: 0.03) Problems come in two flavors. Either the command resulted in an error, like: 18:15:40 [ARM_INFO] system call (failed): procstat -f 'pgrep tor' | grep '29672' | grep -v '0.0.0.0:0' (error: 'procstat' is unavailable) in which case please let me know what the error is, or it doesn't provide any results: 18:15:55 [ARM_INFO] No results found using: sockstat -4 | egrep 'tor\s*29672' | grep -v '*:*' in which case please try the command on its own and let me know how I screwed up the greps. after polling for lsof and a foreach loop, doesn't work ? ... would work ... especially if the system in question is doing little (or nothing) other than Tor ... Sorry, I'm not following. Why is a for-each loop necessary? Process and connection resolutions are the most costly lookups arm currently does. A netstat resolution, for instance, takes around 30-40 ms on my system and is performed every five seconds. Arm tries to be a lightweight application so running multiple system commands to do each lookup isn't really an option. That said, from the link you provided it looks like this isn't necessary. What arm currently attempts is: lsof -nPi | grep process\s*pid.*(ESTABLISHED) If FreeBSD has an equivalents for the flags (n = prevent dns lookups, P = show port numbers (not names), i = ip only) then please show me what its output looks like and I'd be happy to add it as another fallback resolver. What order should sockstat, procstat, and lsof be attempted in? Are any of them preferable due to jails over the others? However if lsof is the only way to do it right Nope, not necessary at all. But the more connection resolvers available for FreeBSD the more likely arm will be able to fall back to something that works. Cheers! -Damian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
This IP serves as the internal adress to the jail when called from a local subnet, and may show multiple connections to the SocksPort, usually IP:9050. Sorry, I'm not sure if I'm following. You're saying that the check should essentially be: if (localPort == ORPort or localPort == DirPort): # treat as an inbound connection with the external ip # this is part of arm's current behavior elif (localPort == SocksPort and OS == FreeBSD): # treat as an inbound connection with the internal ip (ie, what's reported by sockstat) # this is new to fix the issue you mention else: # treat as an outbound connection # again, part of arm's current behavior ... right? If not, could you please clarify? 'GETINFO config-file' will show the path to torrc from within the jail. So arm tries to read: /path/to/torrc The location from the host though would be /path/to/jail/path/to/torrc Reading the file in that way, I believe, is not a good idea. All this only applies for systems running Tor in a jail and arm from the host. Arm works nicely with Tor if both are running on the same host or inside a jail on FreeBSD. If you set features.pathPrefix /path/to/jail in your armrc then it'll read: /path/to/jail/path/to/torrc like you wanted. Again, if you have an approach for arm to detect that (a) Tor exists in a BSD jail and (b) what its path is then I'd be happy to make it work by default instead. Cheers! -Damian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
Fantastic - thanks Fabian! The patch looks perfect. I'll apply it either after work today or tomorrow morning. but I think the same should be done with connections on the SocksPort Yup, sounds like a bug. Until recently arm had just been for relay usage so I probably missed this when writing the connection panel. I'll change it when applying the patch. The connection doesn't leave the system because its a socks connection with both the source and the destination address located on the same system. Makes sense. So if both the source and destination are private IPs (10.*, 172.16.* - 172.31.*, 192.168.*) then skip the private - external translation for the display, right? I'm still trying to get my head around the rest of this bit. From an UI perspective doing location1 - location2 - location3 entries will be pretty difficult. Also, I've never run into this use case so I'm not quite sure what you're describing. Oh well, maybe things will be clearer after a bit more coffee. Maybe it should be mentioning in the log message when the torrc can't be found? Good point. I'll change that too. I missed procstat, though. Actually, neither of the BSD resolvers were added (that was the Linux sockstat entry). I'll add them both. The psutil library [1] uses lsof as its default connection resolver for FreeBSD so I'd like to get a working fallback for it. However, from Hans' feedback earlier it sounds like there's issues with jails so I'll use it as a last resort. The command I'm now using for Linux is: lsof -nPi -p pid | grep process.*(ESTABLISHED) However, like sockstat it probably omits the ESTABLISHED tags from results. If so, this will need a workaround. On Linux the following looks right: lsof -nPi -sTCP:ESTABLISHED -p pid | grep process | grep TCP Does this to the trick? For some reason there was a UDP connection included despite the -sTCP part, hence the extra grep. The lsof man warns that State names vary with UNIX dialects so it might expect a different keyword. If there aren't any concerns between the resolvers then we should default to whatever performs the best. When you run at the debug level (arm -e 1) it provides the runtime for system calls (sockstat, procstat, lsof, etc) so they should be easy to compare. Cheers! -Damian [1] https://code.google.com/p/psutil/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
... Damian, how many connections are on the node that you successfully see the conn list ? I don't recall. It was on amunet and I'll retest this once the relay's back up to speed (we recently switched ISPs so it'll take a few weeks for the BW authorities to send more traffic our way again). I'm sorry, btw, for not applying the patch yet. There was an issue in that it would introduce a couple unnecessary system calls every time the path prefix was fetched, but the trivial fix (caching the results) would mean potentially having the wrong jail path if the connection singleton changes. While addressing this I found a couple other issues I'm also trying to address (unrelated to the patch) so it'll probably be a few more days before I have another tarball to be tested. Cheers! -Damian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Arm Release 1.4.0
Hi, I've uploaded a new tarball to: http://www.atagar.com/transfer/tmp/arm_bsdTest3.tar.bz2 http://www.atagar.com/transfer/tmp/arm_bsdTest3.tar.bz2.asc Besides a modified version of Febian's patch to autodetect FreeBSD jails it most notably includes... - A replacement for the connection test function (which was a pita in my humble opinion). The new script [1] provides the resolver runtimes, a check if all the resolvers match, and a better method of dumping the connection results. If you modify the bsd resolvers then this should provide a nice sanity check that it's working as expected. - I forgot to account for the dns resolution exits do on behalf of the clients. The resolvers need to include UDP connections so, on *nix, they're now: - netstat -np | grep ESTABLISHED pid/process - sockstat | egrep process\s*pid.*ESTABLISHED - lsof -nPi | egrep ^process\s*pid.*((UDP.*)|(\(ESTABLISHED\))) - ss -nptu | grep ESTAB.*\process\,pid I'm guessing, for the FreeBSD resolvers, that sockstats already works and procstat just needs the 'grep TCP' to be removed (or maybe replaced with 'egrep (TCP|UDP)'). Is that right? The connection doesn't leave the system because its a socks connection with both the source and the destination address located on the same system. Hm. Sounds like basic client connections (ie, things like firefox connecting to tor via the SocksPort). However, I tried running TBB and arm didn't list any of those connections. This is what I'd expect since the connection resolution is only fetching tor connections. Am I missing something here? Regardless, I made a couple changes to address issues that have been brought up (socks connections and listing external addresses for private ip range connections - see lines 332-334 and 363-364 in src/interface/connPanel.py [2]). But without a working repro case I can't promises that this'll do the trick. With ^ added to the pattern it seems to work Great, it's happy with that on Linux as well so I'm now using: lsof -nPi | egrep ^process\s*pid.*((UDP.*)|(\(ESTABLISHED\))) and including it among FreeBSD resolvers as the last fallback. lsof also seems to be rather slow (on FreeBSD): Yikes, that's quite the difference. It's pretty bad on Linux too (ss is worse, but netstat and sockstat tend to run around 20% faster). I intend to look into creating a FreeBSD port around Christmas. Awesome, thank you! Cheers! -Damian [1] https://svn.torproject.org/svn/arm/trunk/src/test.py [2] https://svn.torproject.org/svn/arm/trunk/src/interface/connPanel.py *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Arm Release 1.4.1
Hi everyone. The next version of arm (1.4.1) is available including the proc querying enhancements, Fabian's BSD compatibility patches, and numerous other improvements: https://blog.torproject.org/blog/arm-release-141 Updates to the packages and repositories will be staggered a week (just in case issues are discovered over the next new days). Feedback and bug reports are always welcome! -Damian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Shewstring v1.0.0 release!
That's because it's a hidden service. Here's the tor2web page: https://xqz3u5drneuzhaeo.tor2web.org/users/shew/shewstring/20110127-shewstringv1.0.0.html -Damian On Fri, Jan 28, 2011 at 2:59 PM, Zaher F. the_one_man...@hotmail.com wrote: the link is not working Date: Fri, 28 Jan 2011 16:34:22 + From: shew09...@rambler.ru To: or-t...@seul.org Subject: Shewstring v1.0.0 release! More info on my blog: http://xqz3u5drneuzhaeo.onion/users/shew/shewstring/20110127-shewstringv1.0.0.html -- Shew *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: arm: NameError: global name 'bin' is not defined
Damn, looks like the bin function is new in Python 2.6: http://docs.python.org/library/functions.html#bin Thanks for the catch. In the future please file a trac ticket rather emailing everyone on or-talk. Cheers! -Damian On Sun, Jan 30, 2011 at 12:25 AM, Paul Menzel paulepan...@users.sourceforge.net wrote: Dear Damian, with revision 24158 I am getting the following error when I want to run arm. # ./arm Traceback (most recent call last): File ./src/starter.py, line 378, in module controller.init(conn) File /arm/src/util/torTools.py, line 292, in init self._exitPolicyChecker = self.getExitPolicy() File /arm/src/util/torTools.py, line 766, in getExitPolicy result = ExitPolicy(reject private, result) File /arm/src/util/torTools.py, line 1541, in __init__ lastHop = ExitPolicy(prefix + addr + suffix, lastHop) File /arm/src/util/torTools.py, line 1558, in __init__ self.ipAddressBin += (%8s % bin(int(octet))[2:]).replace( , 0) NameError: global name 'bin' is not defined Thanks, Paul *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian [1] https://trac.torproject.org/projects/tor/wiki/badRelays On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiher j...@buksy.de wrote: At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Sounds good. But what to do for now? Just creating a list of nodes which only allow unencrypted traffic and put them into the ExcludeExitNodes list? Shouldnt these nodes be excluded by default? I'm unsure. I want to stress again that I'm not saying any operator is doing anything evil, but I think we should find some way to avoid nodes which have such weird exitpolicies. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
There's no point in putting relays flagged as BadExit into your torrc since your client will already avoid them. However, if you want a listing of the bad exits then it's available at: https://trac.torproject.org/projects/tor/wiki/badRelays As for the previous discussion of if plaintext-only exits warrant the flag, here's my bit to add to the discussion: We already filter exit nodes based on suspicion by defaulting ExcludeSingleHopRelays to true (the reason for that being that single hop exits are more likely to be passively monitoring data). We also invalidated the trotsky relays without proof of malicious intent (a suspected sybil attack when over seven hundred identical relays appeared out of the blue). I'm a little in favor of flagging plaintext-only exits, though I agree that it sucks when flagging doesn't have a smoking gun. Cheers! -Damian On Sun, Jan 30, 2011 at 10:58 AM, Orionjur Tor-admin tor-ad...@orionjurinform.com wrote: Damian Johnson wrote: The five relays Mike mentioned have been flagged as BadExits [1]. Adding them to your ExcludeExitNodes isn't necessary. -Damian [1] https://trac.torproject.org/projects/tor/wiki/badRelays On Sun, Jan 30, 2011 at 1:33 AM, Jan Weiher j...@buksy.de wrote: At some point, we intend to shrink exit policies further as Tor scales to more decentralized schemes. Those exit policies will likely be represented as bits representing subsets of ports. When that time comes, we will very likely combine encrypted and unencrypted versions of ports together, removing this option entirely. Sounds good. But what to do for now? Just creating a list of nodes which only allow unencrypted traffic and put them into the ExcludeExitNodes list? Shouldnt these nodes be excluded by default? I'm unsure. I want to stress again that I'm not saying any operator is doing anything evil, but I think we should find some way to avoid nodes which have such weird exitpolicies. best regards, Jan *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ Is it possible to publish a list of bad-exits for copypasting it to /etc/torrc in addition to the above-mentioned list? *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
Can you please say a little more about this for all of us who are not au fait with all command options? Relays have an option to allow single hop connections through them, which is off by default. If relays *do* set this and allow single hop circuits through themselves then Tor clients by default avoid them for *any* usage in their circuits. Here's the description from the man page [1]: ExcludeSingleHopRelays 0|1 This option controls whether circuits built by Tor will include relays with the AllowSingleHopExits flag set to true. If ExcludeSingleHopRelays is set to 0, these relays will be included. Note that these relays might be at higher risk of being seized or observed, so they are not normally included. Also note that relatively few clients turn off this option, so using these relays might make your client stand out. (Default: 1) In short, there's no proof that these relays are bad but we avoid them because they're riskier (hopefully the parallels with the current discussion are obvious). Could you please say a little more about this case and sybil attack[s]? A sybil attack is where a huge number of relays operated by a single entity appear with the goal of doing bad things (for instance operating the first and last circuit hops to correlate traffic). Again, during that incident we didn't have proof that the seven hundred Trotsky relays appearing out of the blue were bad - we invalidated them because they were highly suspicious, lacked contact information, and had no family entry set. In both of those cases we took harder measures based on suspicion of malicious intent than we are with these plaintext-only relays. Despite its name, the BadExit flag really isn't a big whoop - the relays are still perfectly usable for guard and middle hop positions. They just aren't seeing exit traffic any longer. -Damian [1] https://www.torproject.org/docs/tor-manual.html *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
https://gitweb.torproject.org/tor.git/blob/HEAD:/doc/spec/dir-spec.txt#l1285 On Tue, Feb 1, 2011 at 4:10 PM, Joseph Lorenzo Hall joeh...@gmail.com wrote: On Tue, Feb 1, 2011 at 6:31 PM, Damian Johnson atag...@gmail.com wrote: In both of those cases we took harder measures based on suspicion of malicious intent than we are with these plaintext-only relays. Despite its name, the BadExit flag really isn't a big whoop - the relays are still perfectly usable for guard and middle hop positions. They just aren't seeing exit traffic any longer. -Damian Slightly OT: Is there a place that explains what the various flags mean? I've wondered what they mean while looking at torstatus and metrics.torproject.org... and the manuals don't go into that. best, Joe -- Joseph Lorenzo Hall ACCURATE Postdoctoral Research Associate UC Berkeley School of Information Princeton Center for Information Technology Policy http://josephhall.org/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talk in the body. http://archives.seul.org/or/talk/ *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
Re: Is gatereloaded a Bad Exit?
the whole discussion didn't change my mind. I still support the idea of flagging them as bad exit. Same. Mike gave some good reasons for flagging them weeks ago and I've yet to see much else besides ranting that seems to ignore most of this thread. -Damian *** To unsubscribe, send an e-mail to majord...@torproject.org with unsubscribe or-talkin the body. http://archives.seul.org/or/talk/
