- tor-relays - lists.torproject.org

the effect of bw auth location on relay selection
by nusenu 09 Jul '15

09 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 (split from 'Qualities of a good relay' thread) > I run a relay in Japan on a gigabit connection, but nobody cares > too much, since (I assume) bwauths aren't anywhere near Japan and > do not get good speeds to it, they give it a low weight, and as a > result it doesn't see a lot of use. Lets say the BW auth is located on your LAN and gives you "1GBit/s" measurements, that would increase the likelihood that clients choose you but if your 1GBit/s uplink is limited to your city/country and the international uplink is eg. 100MBit/s than the measurement value alone wouldn't help much for non-JP partners, no? At least clients in JP would have an measurement value that matches reality better. Actually it would indeed be fancy to have location-aware measurement clients. Clients in Asia would consider asian* bw auth measurements to be more important than measurements from non-asian bw auths, but this presumably performance improvement would likely reduce anonymity properties as clients in JP would more likely choose guards in JP. Attackers targeting JP clients would than be in a better position because they could start guards in JP only and have a higher likelihood of being chosen as guards by a JP client (their targets). performance vs. privacy trade-off as usual. ..and the bw auth system is currently (hopefully) undergoing other changes to prevent recent problems from happening again. I just saw that JP has a guard probability of 0%. (at the same time JP is in the top 10 countries of directly connecting tor users.) Out of 132 relays in JP, there are only 3 guard relays and these 3 are exits as well so they are used as exits only. Your relatively fresh jp relay had the guard flag once for a short period of time, but lost it again - probably due to the last restart. So maybe its usage will rise once it is done with the bootstrapping phase and had the guard flag over a few months. btw: Thanks for running the biggest declared family (by consensus weight) on the tor network! *) there is no bw auth in Asia in reality, current locations: +----------+-----------+---------------+---------+ | nickname | city_name | region_name | country | +----------+-----------+---------------+---------+ | moria1 | Cambridge | Massachusetts | us | | gabelmoo | Erlangen | Bavaria | de | | longclaw | NULL | NULL | us | | maatuska | NULL | NULL | se | +----------+-----------+---------------+---------+ -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVi948AAoJEFv7XvVCELh09EcP/jAL0Gnh9yFpo444pGIipCej TH+hGT+4bNp0irXFVlWk88kBrJ90LR/by7fSwJizEoKaqD9KV5bXuOtl9BdRN+7J nQIcR7rZ6tkMXa71VZX9fG3dvg+GjqbcciMA4tutc3fnXhPScmfLnd1lAZSKoG+M Mt7HzEluW+FZO30ixmPDojVEt2xHC87ntOlYA6rbVBarsXGC2GGP6FDhETOrTftN 0nodbUjIom0W0OyYKPhq/cnS3rckdZDctAKmJDSr7uvmWNWQRiF1eLxUoB96DopQ YthkoErJcv5cuPlwuu1iWvK0fxYen7XNF+hl1bezaRW8aRDBL6dVJDX0JhwAhSzS oKkfkOeuiFiihXbM7dRXwTN9z+wZSIuk3fuJfom+ALrS7Dbu0CER6t5Ynxdbcu8h f7qoroSIK9X0aQhc2RQBXlabkNywLKnsMV+DMJOa5NEHCt5WU9JOwFZax0mGumpj WEzoWEoGR95Z4uFQ5fx9TBmronAlKAHU9C+q0sO0FQSUyHL8WKkBBuWjr3wMSMU7 73+z+LIydb80DpXJ4EurxsF/23MsOiuUk6tUl5NnGMQ8DcQeUDPAtOrIPds6/JZm T6mgBWvB1VQugkoM5pNM24ybEEgp85PtnXpRY/Su4FhpTHMB/2RarGp3GTZw954a /KRXEZb3p9ntEnDnXXoc =S/g8 -----END PGP SIGNATURE-----

2 2

Re: [tor-relays] More consensus weight problems
by Speak Freely 08 Jul '15

08 Jul '15

Rah rah rah... Emailed Aaron directly by accident. Here's the email: Hello, First of all, I love Tor. I love Tor Browser, and I love running relays. When the problems are solved, I will most likely spin up more relays. I'm leaving my fastest relay running, as a method of checking the status for myself. The rest have already started to expire, and within the next week or so most of the other ones will have expired as well. I'm going to try tor-dev-alpha 2.7.1 and change fingerprints, as per a suggestion from s7r, seeing as how I have nothing to lose. I just wish the bwauths could scan relays based off previous relative consensus weights... If this particular relay was at 27000, it should be higher on the list to check compared to another one I have that is at 487. My one relay was blazing fast with thousands of connections, my other is painfully useless with dozens, but my fastest one lost its consensus while the slowest one kept it's consensus. It just seems silly. That being said, I don't know how/if the bwauths scan in any order or just willy-nilly, (that's not entirely true, I know it's segmented to some degree as I recall reading a blog post about how it's chopped up) but... I'd be much less upset if my best relays worked and my worst relays didn't. More complaining... bleh. One thing I would like to point out though... it appears... These problems have at least a casual relationship with MyFamily. One group of MyFamily is completely done - all of them stuck at 20. Another group of MyFamily is working happily. I've been doing some tests over the past few months trying to understand why I keep having problems, and one thing has consistently popped up... MyFamily. As one of MyFamily lost consensus, another family gained consensus back on or around the same time. Yes, especially nusenu, I know I'm supposed to have it all configured to be under 1 MyFamily... But in a way I'm glad I didn't, as the casual relationship I see really could only be seen having done what I did. I say casual because I have no proof of causation. But... it is interesting. If no one else has experienced similar problems, then I'd chock it up to a completely unexpected unrelated set of mysterious circumstances that should not have happened for which there is no explanation. Aaron, if there is anything I can do to help you please let me know. So in conclusion, I'm not done, I'm just not happy. This was supposed to be a short email, oops. Matt Speak Freely

5 7

Faravahar authority key expired
by starlight.2015q2＠binnacle.cx 08 Jul '15

08 Jul '15

The authority node Faravahar's key expired and it dropped off the consensus. Looks purposeful. Does anyone know why? Are authority public keys embedded in the relay code or learned? New release required for new key? Is this usual? Just curious.

2 2

Question about responding to abuse request
by Patrick ZAJDA 05 Jul '15

05 Jul '15

Hi all, I run a Tor exit node, and I received an abuse complain from Webiron. In this mail, I can read the following: "If you run a VPN, anonymizer service (like a TOR exit or proxy node), or business intelligence not contracted with the site owner, then we request that the targeted range be blocked from your service. If it is being blocked, then it's at the right and choice of our clients to refuse access." So if I understand correctly, they ask me to block the targeted range they give me in this report. I know I can block this IP range by adding it to my exit policy, but I would like to know how others exit node operators manage these type of requests, because I ask myself if it is not against tor philosophy to block access to a specific network to Tor users. Thanks all in advance for your answers. Best regards, -- Patrick ZAJDA

5 4

Running a Relay behind a NAT (was Re: unflagged BAD EXIT nodes)
by teor 05 Jul '15

05 Jul '15

> Date: Sat, 4 Jul 2015 19:34:45 -0400 > From: Ben Serebin <ben(a)reefsolutions.com> > Subject: Re: [tor-relays] unflagged BAD EXIT nodes > > ?I'll hijack the response.... I'm a sysadmin, an unloved Windows one. My unwanted $0.02 are: > > - Windows installer (omg, Windows, the evil one which if you really want greater adoption is the answer! Oh smokes, someone said it! I agree that relay installers, particularly for non-Linux platforms, would help increase Tor's platform diversity. But platform diversity isn't a large part of Tor's threat model, as its impact is mainly felt through vulnerabilities shared by an entire platform. Currently, it looks like 90% of the Tor relays are Linux, by count of relays. (I believe the weighted bandwidth statistic is much higher than 90%.) https://metrics.torproject.org/platforms.html One suggestion I've heard, but that isn't ideal, is to download the Tor Browser Bundle, and modify the torrc in it to run a relay. That said, a relay operator really needs to know how to download, install, and configure a service on a secured server. So that's one reason a one-click installer is a bad idea. > - change the architecture so running behind nat works (this is probably the #1 limit factor for increasing relays). Every tom, dick, and harry could then add bandwidth via every internet circuit. It would be insane! Tor relays run quite fine behind a NAT, as long as the NAT box handles the number of connections which tor makes. There's even src/tools/tor-fw-helper, which supports NAT-PMP and UPnP. It can be configured via the torrc option: PortForwarding 1 Or, you can configure your NAT box to forward ports yourself. Tim Tim Wilson-Brown (teor) teor2345 at gmail dot com pgp ABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 1

unflagged BAD EXIT nodes
by starlight.2015q2＠binnacle.cx 05 Jul '15

05 Jul '15

Could someone comment on why 15 exit nodes discovered to be sniffing and abusing login credentials have not been marked with the BAD EXIT flag? The research appears to be legitimate, involved a good deal of effort, and seems credible: https://chloe.re/2015/06/20/a-month-with-badonions/ was blogged by Sophos, also credible https://nakedsecurity.sophos.com/2015/06/25/can-you-trust-tors-exit-nodes/ Is there an issue of trust w/r/t this security researcher? An issue of methodology and/or reproducibility? A shortage of resources to follow up? An investigation attempting to identify the operators? The researcher writes that they received a polite reply from and was summarily ignored with no further comment. AND the exits continue to steal and abuse credentials. If true this would be contrary to the inclusiveness generally exhibited by the Tor Project. IMO a likely password-stealing exit should be marked-first, questions asked later. If some kind of mix-up or mistake has occurred, a good operator should readily be able to defend themselves and not feel ruffled for it.

7 11

Re: [tor-relays] unflagged BAD EXIT nodes
by starlight.2015q2＠binnacle.cx 04 Jul '15

04 Jul '15

At 10:04 7/4/2015 +0200, nusenu wrote: >I find it more worrying that we do not "hear" >about the 'more serious attacks' that keep >them busy and don't allow them to look into >i.e. 'AviatoChortler' (even after a few >weeks). That might mean that there is a >constant stream of 'more serious attacks' >(without information I can only guess). Here is one where 70 bad exits were rewriting an .onion address on a clearnet portal and sending a Tor email service's users to an evil onion clone: https://lists.torproject.org/pipermail/tor-talk/2015-April/037549.html I can see the argument for ignoring the near-zero-ranked exits (as they will virtually never be used) and the massive BW password stealer (due to the value of the bandwidth and the fact that HTTPS is immune to passive sniffing). But am concerned Chloe apparently received mute indifference as her contribution to the project is significant.

1 0

Re: [tor-relays] Simplifying ExoneraTor
by Magnus Hedemark 04 Jul '15

04 Jul '15

tor(a)dserrano5.es thus spoke: > Results: do we really need the "Exit: yes" column? Seems pretty redundant to > me. How so? All exits are relays, but not all relays are exits. And if a relay is only configured as an exit for part of the time, that's a potentially important part of the historic record. Sent from [ProtonMail](https://protonmail.ch), encrypted email based in Switzerland

2 1

de-centralised bad exit list files - a bad and/or naive idea ?
by Toralf Förster 04 Jul '15

04 Jul '15

Reading "[tor-relays] unflagged BAD EXIT nodes" /me wonders, such a feature would makes sense. Technically this could yield to a ./torrc.d config directory, where tor users could store the (regular updated) list/s they do trusts. -- Toralf, pgp key: 872AE508 0076E94E

3 2

turned on statistics
by starlight.2015q2＠binnacle.cx 01 Jul '15

01 Jul '15

It looked interesting so I turned on EntryStatistics 1 ConnDirectionStatistics 1 HiddenServiceStatistics 1 in addition to the default DirReqStatistics 1 and the output is indeed interesting. Also have CellStatistics 1 though this information does not seem to be published in the ExtraInfo digest. Any reason why having any of these enabled might be a bad idea? Running 0.2.6.9.

1 0