August 2014 - tor-relays - lists.torproject.org

onionoo backend seems to be down.
by jason＠icetor.is 21 Apr '15

21 Apr '15

Hello All, Anyone else notice onionoo and the tools that rely on it (globe.torproject.org atlas.torproject.org) seem to be down? -Jason

5 4

Torservers.net relays not updated yet?
by Nusenu 19 Sep '14

19 Sep '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi torservers, since you haven't updated most of your relays to address [1] released on 2014-07-28 yet, I was wondering if everything is ok? collective vacation? Since you are operating a significant chunk of the tor network's bw - timely patching is appreciated. The tor network is currently at 64% of the bandwidth being served by relays running a recommended version according to torstatus.blutmagie.de. I updated a previous metrics feature request so we might see nice graphs about patching progress in the future [2]. [1] https://lists.torproject.org/pipermail/tor-announce/2014-July/000094.html [2] https://trac.torproject.org/projects/tor/ticket/6856#comment:2 -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJT7+R/AAoJEDcK3SCCSvoeevcP/06Jg2ubrbbD+SKe32necCd2 OCp4auBI3M8LjxVwJMaMi1aBW81Y513shnghYvAVLRe8NCFuem0mnWfeZq6fjrqd kKvksRhCUo2ERK7covRaoVJ8Aqs37MDJh7B48v/FYcbQYbeRIw6+OUmysC6qMPvP gi+ReWFL77kW4hAK+05z6VeaBq6FfKA8L2FRF12ahtGokCO9BnPM1DijHnA4kLJG Fh2YxbWegd5wVna3PJrubjyJ5ANHM0L5pS0dPZZNobat7Sdrux7dhLo2VdHqZFT5 etykHjc18iJhm7z0r4qjYo58gEAx9CebTqdq2w22TBQFnXPaEt9oPktpdG1Q+Ba+ wPiOOBODyngqSUICD6LRGFq3L9Xa+1RrxORD+d+XmsrGhire+83BLkxDZ/JqUB0Z ZY4NEc13tTQqxPfqB6yQyU/XjTPl45zYWsaAxBjzX/AqoXgkwAQkBwdpFrUeu0O3 UiHe4DLhYtcoeOJjisqfl8t7xbyi5TduKfFH10Erglr3WX/OJ/Pau1N/tDtNqey8 GbrZSXVtv0ch7T31Cp6hYrZwxYnucUBcotcOX01+k158zpI5wv87WCwpc9ncDO3t Oj8ORAL/MbgtYh0JaE1wIP0zSuhhWY2Y+qzdXnTwoYMbfDNnLUjcgZzbZNOhEu+E Y3LfuCsT+DI5TpwIp6tK =FZKz -----END PGP SIGNATURE-----

3 9

oniontip.com
by Sebastian Urbach 02 Sep '14

02 Sep '14

Hi, I like to suggest adding oniontip.com to the "Donate" section on the tor website. It's a nice possibility to help the Relay-Oerators. Have a nice day. -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

4 4

Expired Key
by Sebastian Urbach 31 Aug '14

31 Aug '14

Hi, The key from deb.torproject.org archive is expired, a new one would be nice. The installation information in the docu should be updated to the new key id as well. Thanks -- Mit freundlichen Grüssen / Sincerely yours Sebastian Urbach ---------------------------------------------- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. ---------------------------------------------- Benjamin Franklin (1706 - 1790), Inventor, journalist, printer, diplomat and statesman

2 1

Authdir is rejecting routers in this range
by Davíð Steinn Geirsson 29 Aug '14

29 Aug '14

Hi all, I rented a dedicated server to run a tor relay (100Mbit/s) to contribute to the network. On this machine, tor gives messages like these on startup: http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '<...>'. Please correct. The server is hosted with https://fdcservers.net/. Did I just get unlucky in picking a provider? Is there a way to check these things before spending money on setup + monthly fees? Best regards, Davíð

4 5

Key expired problem - Ubuntu 12.04 LTS
by kingqueen 29 Aug '14

29 Aug '14

I'm experiencing difficulties running apt-get update as it complaints that the repository's key is out of date. Here's the error: W: A error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: http://deb.torproject.org precise Release: The following signatures were invalid: KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 KEYEXPIRED 1409325681 W: Failed to fetch http://deb.torproject.org/torproject.org/dists/precise/Release W: Some index files failed to download. They have been ignored, or old ones used instead. When I set the relay up, I used Option Two on this page https://www.torproject.org/docs/debian to install tor and deb.torproject.org-keyring . Updates worked for 10 weeks or so and now don't. I've tried going through the same processes again, to no avail. Any assistance very gratefully received.

2 1

Centos 7
by obx 28 Aug '14

28 Aug '14

There are no packages for centos 7 yet. Is there an ETA? Is there anything we can do/contribute?

3 2

Re: [tor-relays] Advantage in more exits in the same /8?
by Jesse Victors 27 Aug '14

27 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 On 08/27/2014 04:03 PM, tor-relays-request(a)lists.torproject.org wrote: > Not to drift too far off course, but I think you have your masking > back wards or confused at least. > > a /8 is 16M addresses 18.0.0.0/8 for example, so not a small block, > and a /16 has 64K. > > two consecutive /16's say 128.30.0.0/16 and 128.31.0.0/16 make a /15 > (120.30.0.0/15) > > the real concern is administrative control not addressing. for exmaple > both the /8 and /15 mentioned above and some other smaller patches of > addressing are all on MIT campus and part of the same administrative > domain in the sense that all traffic passes through a small set of > routers at some point. Being a university it doesn't imediately imply > root access to all servers. this isn't true of all (or even most) > /8's, nor does even a /24 with 256 addresses need to be in a single > geographic or andministrative zone. > > -Jon Thanks Jon, You're right, I had my ranges weird, even in my title, thanks for the correction. To clarify, because the nodes are physically close to one another, they are in the same /24, namely x.x.x.x - x.x.x.y. Yes, the real issues is the traffic concentration to a specific set of routers, which is why I'm asking. I'm trying to get a sense of where to draw the line, but from the responses so far it looks like I've got room to spare. - -- Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCQBmBQJT/lfPXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAYCwH/i6Ci/SS6dpXr703mlajr31C fXX2WOKVWoGGTkPDXkQJM18+uI0DGRaieahmQ99VAGwA8+PAFhq9QsISLZ/Bby9g rZCOkY9E9xel2uu80hiMlP99h4WkjJtbgeX1cGXXOoJq1d+MLHIzQqgzZvmVry2+ piIUsXRO693r+TiU6BzZjnpBm+Omo6BzvOuJmUq34/XztdrGWSfoCvpwlesbMJZc sNGN1N5wQ3U1FcQTkwJc2wVyTpQNyu+tgvZyqwusIwAlH7J9cN/zg+eNZ+3ZpPUv 7DjiKhwQCQUqv/LHC5sK7FmQNELLwXPGvTaflvjfhF9uSBWCAX9JVEBNsHrB1M0= =77pe -----END PGP SIGNATURE-----

1 0

Re: [tor-relays] Advantage in more exits in the same /8?
by Jesse Victors 27 Aug '14

27 Aug '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA384 > Message: 5 > Date: Tue, 26 Aug 2014 19:50:21 +0200 > From: Anders Andersson <pipatron(a)gmail.com> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Advantage in more exits in the same /8? > Message-ID: > <CAKkunMYKgXKT1OEbV5Lft9edqLhvAJsbxv7QkHQn6dCbpuj36Q(a)mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Aug 26, 2014 at 3:47 PM, Jesse Victors > <jvictors(a)jessevictors.com> wrote: > >> I run some relays and an exit in a university setting. The nodes are in the same /8 block and are physically close to one another as well. Is there any advantage in turning one of the relays into another exit? This is something that my ISP would be agreeable to, but I'm also pondering the effects on the Tor network as a whole. > Just want to be clear here: Do you really mean /8 and not /24? There's > only one university I can find with a /8 block. Anders, no I literally mean the same /8. The university has its own /16 and recently required another /16, but since my nodes are physically close to one another they are in the same /8. My concern is that too many nodes in a small block can result in a large concentration of Tor circuits in that block. No circuit should use any two nodes from the same /16 unless forced to, so my question really revolved around how many is too many Tor circuits and how much is too much traffic through the same /8 or /16 in people's opinion. - -- Jesse V. On 08/27/2014 06:00 AM, tor-relays-request(a)lists.torproject.org wrote: > Message: 2 > Date: Tue, 26 Aug 2014 16:24:42 +0200 > From: Moritz Bartl <moritz(a)torservers.net> > To: tor-relays(a)lists.torproject.org > Subject: Re: [tor-relays] Advantage in more exits in the same /8? > Message-ID: <53FC98AA.2000607(a)torservers.net> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi Jesse, > > On 08/26/2014 03:47 PM, Jesse Victors wrote: >> > It seems to me that too many nodes under the same ISP is >> > problematic because it concentrates too much traffic in >> > the same AS, but on the other hand, Tor could use more exits. >> > More importantly, how many is too many nodes in the same /8, >> > or in the same /16? Where would you draw the line? > Very good question. Ideally, the Tor client would be AS-aware, and you > would not have to worry about it. For the interested reader, see for > example [1]. Until then, my thinking is that I compare to other > locations. https://compass.torproject.org/ is very helpful for that: For > example, if you group by AS, the largest AS right now (i3d, NL) in > regards to exit capacity has 11%, and OVH tops the overall network at > 10% consensus weight. > > As a rough rule, I'd avoid to push more than 1-2Gbit/s of traffic at one > ISP. On the plus side, as long as you don't top the list, you're > weighing down other locations. And universities are a preferred location. > > Make sure to use the MyFamily statement correctly: Unless relays are on > the same /16, Tor might pick multiple of them for a circuit. Also, if > you want to push more than ~100 Mbit/s on a single machine, you need > AES-NI or run multiple relays, for more than 400 Mbit/s you need to run > multiple relays in any case. The multi-relay initscript can be quite > helpful for that. > > [1] http://freehaven.net/anonbib/#ccs2013-usersrouted > [2] https://www.torservers.net/wiki/setup/server#multiple_tor_processes > > -- Moritz Bartl https://www.torservers.net/ Thanks Moritz, Ok, so I think 1-2 Gbit/s is a good number, that just seems like an awful lot of data to me and I'd rather see that spread out more diversely of course. I'm aware that no circuit should contain two nodes from the same /16 unless forced to, and the MyFamily value further helps with that. My concern was not with a single circuit using multiple nodes there, but rather many circuits preferring that AS. Diversity helps security. That being said, by your advice I'm nowhere near that threshold, so I could keep going. Thanks for the tips on the multiple Tor instances and the optimization tips. - -- Jesse V. /CS, Network Security / -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQF8BAEBCQBmBQJT/e7iXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQxMjgyMjhENjEyODQ1OTU1NzBCMjgwRkFB RDk3MzY0RkMyMEJFQzgwAAoJEK2XNk/CC+yAu0wIAK3rn17vEWQZTZy5KVBgOnUI TstJAkqO9Wjkfxf++E/5h8OMRdU1f3rV2mArJgGbgc344ttueM8iPntneaK4jI9W 4FrEqiMf7X6boYZXyeG81gYaGT6nf8ePSK5+1xY3pGR+2R3gXbDt/AU/LIZFsL2w r+9znukltzWBudfM76Fzd7jJcrwC+2giguHKU1/oxpKDh1xWuQC4maOYxZexGSLw JFz/O9Ca/CIDH/5Pbm6uJFe3Ec1zzm6z8cgsfBmGY8GHj3xBM8bNttP+a+fW7J5Z W01uoYss6tuw3jhVAp/+LKm4GcXsdtUjJIAX56yvEURCa6L9CbuTYha4cBI4zFw= =OHSc -----END PGP SIGNATURE-----

2 1

Ongoing scan from FDCServers block
by linenoiz＠Safe-mail.net 27 Aug '14

27 Aug '14

For the past week or so I've been seeing unsolicited echo replies coming from FDC servers block and one that looks like it is owned by China(?) Most of the entries are from 67.159.54.101 and I am seeing around one per minute. I verified by running tcpdump for a couple minutes (no longer, I'm not an illegal wiretapper!) that I'm not sending echo requests. IPTables is configured to drop and log this invalid traffic. Any idea what they are trying to accomplish? Some convoluted way of pinging me because they don't get an ICMP unreachable back? And why every minute? DENY IN=eth0 OUT= MAC=xxx SRC=67.159.54.101 DST=yyy LEN=40 TOS=0x08 PREC=0x20 TTL=55 ID=61817 PROTO=ICMP TYPE=0 CODE=0 ID=10249 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=67.159.54.101 DST=yyy LEN=40 TOS=0x08 PREC=0x20 TTL=55 ID=61817 PROTO=ICMP TYPE=0 CODE=0 ID=58375 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=67.159.54.102 DST=yyy LEN=40 TOS=0x08 PREC=0x20 TTL=55 ID=39417 PROTO=ICMP TYPE=0 CODE=0 ID=62498 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=50.117.112.42 DST=yyy LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=28340 PROTO=ICMP TYPE=0 CODE=0 ID=30728 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=50.117.112.42 DST=yyy LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=28334 PROTO=ICMP TYPE=0 CODE=0 ID=30728 SEQ=0 DENY IN=eth0 OUT= MAC=xxx SRC=50.117.112.42 DST=yyy LEN=40 TOS=0x00 PREC=0x00 TTL=56 ID=28335 PROTO=ICMP TYPE=0 CODE=0 ID=54277 SEQ=0

2 1