June 2015 - tor-relays - lists.torproject.org

Please enable IPv6 on your relay!
by Moritz Bartl 28 Jan '17

28 Jan '17

Hi! We still have a depressingly low number of relays that support IPv6 (currently only ~120 of ~1900 relays). If your host supports IPv6, please enable it, especially if you run an exit! This has to be done explicitly. https://trac.torproject.org/projects/tor/wiki/doc/IPv6RelayHowto In short, you add: ORPort [IPv6::address]:port IPv6Exit 1 ExitPolicy reject6 *:* (or a more open exit policy respectively) Thanks! -- Moritz Bartl https://www.torservers.net/

30 42

Reminder: exit nodes probably shouldn't be using Google's DNS servers
by Nick Mathewson 25 Feb '16

25 Feb '16

Hi, all! While looking into a bug report, I noticed that an exit node was using one of Google's well-known public DNS servers for its own DNS server. No disrespect to the operators of Google's fine public DNS service, but my sense is that using it for a Tor exit node might not be the greatest idea for users' privacy, having one DNS provider that gets to see so many requests. It's probably a better idea to have your own local cacheing DNS server. Would anybody like to share a guide about how to set one of those up safely and migrate correctly? best wishes, -- Nick

23 38

OpenBSD: tor rc script: don't kill unrelated tor instances (patch)
by nusenu 22 Jul '15

22 Jul '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Pascal, what do you think of changing OpenBSD's tor rc script to require perfect process matches when sending signals to them instead of the current "kill everything that starts with..." approach? I've put tor-relays on CC so people can speak up if this change is not desired or breaks anyone's environment - I believe it fixes them. Problem: /etc/rc.d/tor stop might kill all (including unrelated) tor instances instead of the intended daemon only. /etc/rc.d/tor start might never start the intended daemon if another tor instance is already running (rc_check believes tor is already running). /etc/rc.d/tor restart might kill all tor instances and starts only one. references: http://article.gmane.org/gmane.os.openbsd.misc/222896 One line "patch" for /etc/rc.d/tor to address this issue: (tested with and without custom daemon_flags) 8a9,10 > pexp="${daemon}${daemon_flags:+ ${daemon_flags}}$" > (this line is a complete copy from rc.subr with the addition of one char: $ ) thanks, nusenu https://github.com/nusenu/ansible-relayor/issues/40 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJViSx3AAoJEFv7XvVCELh0y8UQAJgb6JVbKde/xf79YJJr8LW1 t+Rji8A5zZ9VsjcW4Pguf/OZsQEN3MEIkjzTM3kw0q9S8CPnDbF3IYOaZj4ewYkX 8OoNmHfFbcQCC0YCJBlbUJMBtNJqi8pg7qRY4o+qY9KKa9ekUhPer7kzUt4N1A+T an4z44lh3ytAcehyFxo6hpDGZHHGGsACEIql9Rav6v+DPCBSJnCZsmlT0OeTeV5k 5WEy9nTVzdkX4mKs1xXv8YJFggCrb1uur3q91/5ZGhpKADfRj6T+1i/9622Bcki9 17ADc4ZI73dP3ZelKvpZ+FXhaiZLn6tugdj2dcqnXU8Zras6jKToupFi2nB8xfTV f70qSdkMP6WOJReCP+KTAGHiCkapyoc9V+8569iZIjUXuD7GbbSpP6I1rOoqSLYH rao6WpqHVfSMQ5jCaECHBbZY62qBhHH83B/um3nG+WXvvWDPpzjkbEx56RxH3UUo yZ4naGenbxQzCXsGXhEOAmUkJjSmW+Hw75EyObBLAp00+Q8zAXkHnFOqRGbRuxdl IKqAYsfGNLr7kPBvz9pxfnOJMfyIBDQ2P2WNyKXvYLME3wKbYMazVxd7cXzmAV5g QthMuFJ/JhWYI9Lb1U+IQq7LOX+pEWU6u/L2xqjTDj7VMn4UF1WZ6UHhnaLMAotZ lfiTKPnopA62t+X05ztR =ysgm -----END PGP SIGNATURE-----

3 5

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

Tor handshaking
by Adrian Soh 30 Jun '15

30 Jun '15

My ISP slows handshaking (circuit initialization) severely. Are there Torrc settings or changes to Orbot (Android) that I could use?

2 1

Re: [tor-relays] A bridge too far
by jchase 29 Jun '15

29 Jun '15

Thanks, isis, for your answer. I restarted my bridge without the flags and it's been running 7 days and still no stable flag back. Any experiments you can suggest? -J Chase > jchase transcribed 0.8K bytes: >> Hello, >> Can anybody help me figure out why my bridge has stopped showing the >> flags fast, running and stable? Especially stable, I would love to get >> that flag back. I run two bridges, on two different Rasp Pi's, the one >> with a globe fingerprint of B08284109C72C81ACF5866A17A4CC64CE3E16499 . >> The other with a globe fingerprint of >> 1BCD3EBEFE17EEB86EEDE21D5E2DB8468E2864CF . The first bridge runs with >> obfs 3 & 4 on a Pi 2. It seems I lost the stable flag around the time I >> got obfs 4 up and running. The second bridge runs only with obfs 3 on an >> older Pi. >> I've read that the stable flag is quite handy. Any ideas about how I can >> get it back? >> Greetings, >> J Chase > > Hi J, > > Your bridge B08284109C72C81ACF5866A17A4CC64CE3E16499 appears to have a current > uptime of about 50 hours, and to have the Stable flag, according to > dir-spec.txt, [0] it must have: > > "Stable" -- A router is 'Stable' if it is active, and either its Weighted > MTBF is at least the median for known active routers or its Weighted MTBF > corresponds to at least 7 days. > > Meaning that you probably just need to let the bridge run for a few more days, > and it'll get its Stable flag back. > > Also, for what it's worth, BridgeDB will still distribute your bridge, even if > it doesn't have the Stable flag. The only required flag for your bridge to > get distributed is the Running flag. However, you are correct that having the > Stable flag is useful, because BridgeDB, when distributing some bridges to a > user, will try pretty hard to make sure that at least one of the bridges has > the Stable flag. So, with the Stable flag, you've got a better chance of > being distributed to clients more often, but it's not strictly necessary to > have it, especially for a bridge like yours with small bandwidth and CPU. > > [0]: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt?id=26929b8c5554… >

1 0

Re: [tor-relays] More consensus weight problems
by Aaron Gibson 29 Jun '15

29 Jun '15

On 2015-06-29 17:51, Speak Freely wrote: > 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 Well, relays are ranked by capacity, and split over several scanner processes - they do get measured against their relative peers. But it seems that, when they fall out of the measurement process ('Unmeasured') they must start again at the beginning. This is expected because all relays start Unmeasured, and gradually increase their position in the consensus (per relative capacity), in order to dampen sudden changes and limit sybil attacks by requiring relays to stick around for a while, increasing the cost to an adversary. It likely should not be the case that historically long running relays should start at the bottom if they are unmeasured for a short period of time. We are in the process of testing increasing the number of scanner and accompanying tor instances from 4 to 9 (double, plus one for currently unmeasured relays) in order to decrease the amount of time each fraction of the network takes to measure and ensure that new relays or unmeasured relays are measured often. There are additional patches that introduce extra exits into the slice of relays, if there are no suitable exits to measure with. This likely won't address the above behavior, but we hope it will reduce the number of relays that go missing. Currently we seem to have mixed results, with one Bandwidth Authority operator claiming minimal (50) unmeasured relays, and another claiming ~600 mixed relays. These numbers are not directly comparable because they were not sampled at the same time, and may not be representative of typical behavior - it's a little too soon to tell. It's a bit tricky to both test these changes, on the live tor network, demonstrate that they produce sane results, and convince the directory authority operators and partner bandwidth authority operators to upgrade - nor do we want to do that all at once - gradual change is better. So, the goal is to produce results that will convince operators they should update, improve the situation for relay operators, and then start looking at longer term solutions for the measurement problem that are more maintainable and scalable in the long run. > 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. > I hope to have a testable hypothesis as to why your faster relays suffer(ed) more than the slower relays - it could be that the fraction of network by capacity allocated to a particular scanner is not well balanced, and that fraction is taking significantly longer to measure. In order to evaluate that statement I need to understand the common characteristics of relays that become unmeasured/lose rank and see if they are from a similar segment of the network, and whether or not that segment of the network takes longer to measure than other segments. Another hypothesis is that your relays are on the boundary between two segments, and that a transition between scanner instances causes enough missed measurements to drop your relays. It would be helpful to know what rank the last good measurement your or other relays had before becoming unmeasured. It will require some cooperation with the existing deployed Bandwidth Authorities, in order to learn what their current scan times are - I will be writing some simple scripts to scrape these results so that we can collect and publish some useful heuristics about the scanner processes to better try and debug this problem. > > 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. That is very interesting, because MyFamily should have nothing to do with the scanner process at all - I'll need to think about this some more. > > 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. If anything that I said above sparks a thought, 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

1 0

default value (after reboot ) of controller.get_server_descriptor.uptime changed ?
by Toralf Förster 28 Jun '15

28 Jun '15

I do wonder, why a python script [1], lines 22 and 113, nowadays returns "00:00:00" for the uptime of my exit relay, when the system was rebooted, whereas in former times '00:01:01' (= 61 sec) was returned. FWIW the only local change before reboot here was to switch from Gentoo hardened kernel 4.0.6 to 4.0.6-r1. [1] http://www.zwiebeltoralf.de/pub/info.py -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E

2 1

be in time or not to be in time ?
by Toralf Förster 28 Jun '15

28 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hhm, found this in the log: Jun 28 03:58:37.000 [warn] Our clock is 1 minutes, 23 seconds behind the time published in the consensus network status document (2015-06-28 02:00:00 UTC). Tor needs an accurate clock to work correctly. Please check your time and date settings! NTP runs fine at this exit relay since months, and I found nothing in the log which would tell me that sth was wrong with the time. Any hints / explanations ? - -- Toralf pgp key: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 0076 E94E -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iF4EAREIAAYFAlWPuw0ACgkQxOrN3gB26U71+wD+PIH6JSVqR8SJ/43wwDZKNibH UdvUWwDG4eQQ5kn/3N4A/AydwluUvBMXXSy7fh+Zphg1dCUF+zq7jKmxzRYcAZ2A =bnzu -----END PGP SIGNATURE-----

2 2