tor-relays May 2015

tor-relays@lists.torproject.org

80 participants
39 discussions

Authdir is rejecting routers in this range
by Tim Semeijn 13 May '15

13 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In my venture to find more ISPs to house Tor Exit nodes I have recently set up a node in Switzerland (Private Layer - 179.43.160.41). When running Tor 6 out of 9 Authdirs are rejecting the node: - ---- May 12 20:31:02.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '86.59.21.38:80'. Please correct. May 12 20:31:02.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '131.188.40.189:80'. Please correct. May 12 20:31:02.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '171.25.193.9:443'. Please correct. May 12 20:31:02.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '208.83.223.34:443'. Please correct. May 12 20:31:02.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '199.254.238.52:80'. Please correct. May 12 20:32:04.000 [warn] http status 400 ("Authdir is rejecting routers in this range.") response from dirserver '154.35.175.225:80'. Please correct. - ---- I looked through the mailing lists and blog posts to find out if this range was mentioned somewhere to see why it gets rejected but I could not find anything. Can anyone shed some light on why this range would be blocked and if there is any chance it will get accepted again in the near future? Best regards, - -- Tim Semeijn Babylon Network pgp 0x5B8A4DDF -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBAgAGBQJVUloCAAoJEIZioqpbik3fc/UQAKWstydq4S2OjRko7jhd1oXS kcde4a39nk1lvB/YtHCZJtHVkyypnLbdjmvPlcVSIk3Qqaj/40lu05caWThq5ZgI y90SEnumUHaWslYtKVUAFmgQAXv7lkAs6Svf3ZxZ9PT+NQMpWhyrrlmJ2hakF01Q /z46NU9YhL2dqCXG/w75gmrP87aYZ/2jOMIEZxi4ZIp6OlJXIGoaI8lCQrYWFstH zuC1JDnPwgGhqnB//JBKilrwEalk/kXZDodWpHvllUDqywvn1OOn/Do2JRETqxuV czVy7Ez/s19fk1ltWZyblDS6xsT0gYowH3c0zYovY/s0G1Y7KD50Jr1MEVpiv19/ 9NBHErEUEec8C+h6UoiSXoDKg5Q999uEtMJNJ0/AzlvyWN3+eXtNc/XmBpxzbIGR gQ+w30vyQNwXJFZkpq0wGIXSbXWpsgKYyxNRnokCNFx/AQpjGFUBauXDj5EcpzXJ m3on4LHH9IYbek3EKjhivJ2MjK5lRfjtINtoBx8nanliOY21Pf9js+bAxDFhorhZ wFdijEVGvoUlu/SWOlEuaQlNSBoVXxqBQQo/MVSgJpMUNRngshQslg9qI42Bd5Pn pxJ44X161/PUdChWc6hQ01dAXLNFR07+1OT/9vnSRBaaHFsstU3gI99hFZ1chhps BK+QwwxupISJchliUZZ1 =nWDs -----END PGP SIGNATURE-----

2 1

Port configuration on non-exit relay
by aredocilla＠gmail.com 13 May '15

13 May '15

Hi all, I'm running a non-exit on Amazon EC2. I followed the (out-of-date) docs online (which are no longer online!), which instructed me to open the following inbound ports in the security policy: 52176, 40872, 22, 443. Obviously 22 is for SSH, and 443 seems to be the standard choice for ORPort. What are the other two for? They don't seem to be used; should I disable them? The other thing is: I've enabled obfsproxy with obfs3 and obfs4 bound to different ports on 0.0.0.0: ServerTransportListenAddr obfs3 0.0.0.0:587 ServerTransportListenAddr obfs4 0.0.0.0:80 Is that optimal? Presumably also: - I should add additional lines for listening on [::] on the same ports to enable ipv6 obfsproxy connections; - I should also open these ports in the security policy? Best wishes, allicoder -- PGP key available on request

1 0

Hivelocity is not longer serving my needs.
by Geo Rift 11 May '15

11 May '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 I've had my exit relay running on a spare Hivelocity server that I had for 17 days now. Even after a reduced exit policy I continued to receive abuse reports. They have now asked that I stop running a tor relay on the server. I'm looking for a decent provider that can suit my needs of running a fast exit node. Does anyone have any recommendations? Thanks, Tim -----BEGIN PGP SIGNATURE----- Version: Mailvelope v0.13.1 Comment: https://www.mailvelope.com wsFcBAEBCAAQBQJVUM1qCRC8Tq5FO2jmKgAA9aAP/3rWozZ63GiGG28/UsWT Ap4ygekHqXvKPzpbUJz7mwxgk0AzCydgaLKaYHvl4jgEgXuwAXSCfSyZS27E jOd72A6Qk36dtsVSgzBbFFyiT3f30mAZIBc+KCyhZ6fEQ5Rb5v0mJWz1nlyA BfvYjTF6eZgLaLcyPt8RPJoITyV6df+RUbaUAstoqql+cZn7Wnoj9P6rbM3h aSPFD2llWQorGxgRX7vJzuytJqZEIvhLoI/eakClyTKrNi2AosCn2rzKwB4C oTv4wmlbbZnhSXvT8jdqBXzQl1va2XPaSErXTfkREzQ6Pg+LEG1lr+AGTFAE JRMx5MN79YQtX86XnxZsCHxqLD8mqz1Kw2/lr6rNWWcxZH+tmXfKqpmCr6/b 9Jjttd2qUQctOQZEYYoMSsIx1s269km1X6WB4tvYrx8NuBaqsFUuoEndeEpD AvF2mlL5mhUjGxE4q9UERGm7KTVLf1MfqPNdpWjpepxy2eATjaOyo+tnswIZ vM1h7x/Ky2KQG9240k1U6vfiqaRV82FNRvIhbrKgCtiZ3+CrqLNx4UXwcMVt tqGqC86xX5ip4W+iyuVOOApV86V6U047ovPmiRV9XRv+44v8UFgGZA58Zobg sCsFluaLICo857y4WPsiHjXwA5IHy9hI1kVAyJB2Qo9yIApGGlL9RhVhFDBI B4Nm =L3ny -----END PGP SIGNATURE-----

4 3

Re: [tor-relays] RelayBandwidthRate vs AccountingMax
by teor 11 May '15

11 May '15

> Date: Sun, 10 May 2015 23:13:18 +0100 > From: Christopher Baines <mail(a)cbaines.net> > > I run this relay [1], and currently use the following config: > 1: > https://atlas.torproject.org/#details/91F4DFA04743755C8551A12F8C4065F79786B… > > RelayBandwidthRate 1.7 MB > RelayBandwidthBurst 20 MB > > This keeps it from using more than ~3TB of bandwidth in a month. > However, I wonder if this is beneficial for the network, over using the > AccountingMax instead? If you use "AccountingMax 3TB" and "AccountingStart month 1 00:00" (or whenever your rollover date is), the relay will go at full speed, use all the quota you specify, then hibernate for the rest of the month. The next month, it will calculate the maximum start date that it could start at to use all the bandwidth at a similar rate to last month, then wake at a random interval between the start of the month and the calculated date. Note that the AccountingMax quota will make the relay hibernate when either the download or the upload individually hit the quota. If you want the sum of both, use "AccountingRule sum". If you use RelayBandwidthRate, the relay will go at partial speed, and may not use all the quota if there are any quiet periods. Personally, I'd rather have faster relays for part of the month, but others favour stable relays for the entire month. It may also depend on whether your relay is one or more of: * a guard, where stability would be a priority, * a middle (that is, not guard or exit), where there is plenty of bandwidth, and therefore speed would be a priority, and/or * an exit, where speed would again be a priority… as far as I can work it out, anyway. Both stable relays and fast relays are a valuable contribution, please contribute what you think the Tor network needs most. teor teor2345 at gmail dot com pgp 0xABFED1AC https://gist.github.com/teor2345/d033b8ce0a99adbc89c5 teor at blah dot im OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

1 0

RelayBandwidthRate vs AccountingMax
by Christopher Baines 10 May '15

10 May '15

I run this relay [1], and currently use the following config: RelayBandwidthRate 1.7 MB RelayBandwidthBurst 20 MB This keeps it from using more than ~3TB of bandwidth in a month. However, I wonder if this is beneficial for the network, over using the AccountingMax instead? Thanks, Chris 1: https://atlas.torproject.org/#details/91F4DFA04743755C8551A12F8C4065F79786B…

1 0

descriptions still valid?
by tor-server-creator＠use.startmail.com 10 May '15

10 May '15

dear relayoperators, i wonder if descriptions on http://www.torservers.net/wiki/setup/server are still valid for debian jessie dist? particular chmod 700 ~/.ssh and wget https://www.torservers.net/misc/config/sshd_config thanks for helping out. cheers

2 1

send me somerelays and bridges for vidalia
by Sh.F.M 09 May '15

09 May '15

1 0

Re: [tor-relays] T-shirts and Confirming Relay Control
by Tim 06 May '15

06 May '15

Being fairly new to the tor project I can see where he is getting at with the difficulty of helping out. I can deffinantly see having a single person to contact to try and find things to do would be important. While I agree that volunteers should not be babysat there should be someone that has a bunch of tasks to pass off to those who is interested. I would be more than willing to dedicate time to do something like this, I think it could be seriously useful to newer people in the community. In my mind a volunteer coordinator would not babysit but provide things that may be suited for a particular skill set. Then a little later down the line touch base with person to see if they encountered any issues. Side note: getting a little off track here. Would there be a better place for a discussion like this? Tim <div>-------- Original message --------</div><div>From: Matthew Finkel <matthew.finkel(a)gmail.com> </div><div>Date:06/05/2015 02:14 (GMT+08:00) </div><div>To: tor-relays(a)lists.torproject.org </div><div>Subject: Re: [tor-relays] T-shirts and Confirming Relay Control </div><div> </div>On Tue, May 05, 2015 at 01:57:04PM +0000, Speak Freely wrote: > Matthew Finkel, > > It's kind of disingenuous to suggest "If you want to work on something, > then please come work on it, we really are overloaded." > I'm really sorry you interpretted it in that way. It actually was a genuine request for more help. > You have to let us work on it, for us to work on it. Do you understand > the problem? Sure, that is a problem, but what is the problem? It seems this dilemma is reoccurring and not getting solved. Someone says they are willing to help work on something, possibly someone else says "great! we need your help!" then nothing happens. Was it an empty offer or did the offer die because no one followed up with the person? Having a volunteer coordinator might help - I hope it would help - but what's the best way to organize that? Is it the responsibly of some people associated with The Tor Project to follow up on every offer they receive or is it the responsibility of the person who made the offer to follow up and get involved? Maybe both? > > To The Inner Circle (The Tor Project People), > > I am at the very least the third person to mention in this thread that > we have offered to help. No one responded to my offers. I'm pretty sure > at least some of their offers were ignored as well, though I can't be > bothered to double check. :( I don't know. Obviously, not receiving a response sucks. I completely understand that. Tor's work and day-to-day coordination is heavily based around IRC, so the mailing lists are not great places for offering help. This whole situation seems to be less about an inner circle existing, and more about a disconnection between the announcements and discussions on the mailing lists and what happens on IRC. I don't know of a good way to bridge this gap, though. > > I get that you're busy. However, Matthew's attitude to Seth is, in my > most humble of opinions, unwarranted. > We're all busy, it's difficult balancing everything. I'm sorry if my response was unwarranted, and maybe I shouldn't have responded because it was off-topic, in any case. It's frustrating trying to do something and improve a situation, and instead of receiving helpful feedback the thread receives complaints about how Tor is crappy with how it handles volunteers. Maybe this is partially due to miscommunication but I'm at a loss for what to do. > You've got several people who out of their own free will, decided to > offer our additional help, above and beyond what we already do. > > I wonder, how would you feel, if after offering free assistance to a > community that then goes completely, totally, and utterly UNANSWERED, > only to have those very people that we offered to assist, bitch that > they are busy and want our help. How would you feel? > Angry? A little schadenfreude? Or numb? > > I'm a husband, a father, and a business owner. I'm a busy guy, yet I > still offered to help. I can't express how pissed off I am about this, > without going into a obscenity-laced tirade about how your house isn't > in order. > > When I offer assistance to someone, or in Tor's case several people, I > damn well expect a response. "Yes" or "no", "thanks" or "fuck off", > "please" or "tomorrow", "join us!" or "maybe next time". > > Deafening silence is in no way a mechanism that encourages support from > the broader community, but from my perspective that's all you've given. > Thanks. Obviously you're correct, silence is not an answer and not what you deserve as a result of offering your assistance. I don't know why this happened or the context of the offer but, to be blunt, Tor doesn't babysit volunteers. If you want to work on something, then, you must actually follow through and work on it. I learned this personally. A volunteer coordinator would be a great person for helping volunteers become more integrated into the community and work on projects but it is ultimately the person volunteering who decides how, when, and if they help. Tor wants your help, but becoming an active volunteer is your decision. > > Here's a suggestion to The Inner Circle > - Have a volunteer coordinator that actually responds to people. > > This way, when the next person offers to help, they might actually get a > good g*d d@mn f@cking response! > Yes, this sounds like a good idea. Who wants to volunteer to be the volunteer coordinator? Again, that is a genuine question. No one has stepped up to do it. If we had one, at least they would respond to most offers. > > Seeing as how I'm a nobody and my offers aren't worth acknowledging, > please continue to do whatever you'd like, with *all* the success it > brings. Don't forget to smile. > Being a nobody or being a somebody is irrelevant. I'm a nobody too, but I'm trying to do something. I sincerely hope you and the rest of the community will help me and Tor, as a whole, create a better community/network/world. Let's continue this discussion in a new thread. Thanks, Matt _______________________________________________ tor-relays mailing list tor-relays(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 0

HW-Accelerated OpenSSL & Tor not playing nicely.
by 12xBTM 05 May '15

05 May '15

Probably (and hopefully) a very obvious fix for those that aren't newbies to Linux, but I'm trying to get Hardware-Accelerated OpenSSL to work with Tor on Jessie. I've gotten the Hardware-Accelerated OpenSSL part done, but the Tor part is giving me problems. I am able to successfully compile Tor by itself, and I'm able to successfully utilize OpenSSL by itself, but getting them to work together isn't working. So, I'll give a run-down of what I've done, and where I'm stuck: Info: Linux beaglebone 3.14.39-ti-r61 #1 SMP PREEMPT Fri Apr 24 18:32:15 UTC 2015 armv7l GNU/Linux Debian 8 Console Tor 2.6.7 Information Sources: https://superuser.com/questions/881404/beaglebone-black-openssl-crypto-acce… and http://datko.net/2013/10/28/tor_cryptodev/ Step 1: Getting OpenSSL to become Hardware-Accelerated sudo apt-get install linux-image-3.14.39-ti-r61 sudo apt-get install linux-headers-3.14.39-ti-r61 wget http://download.gna.org/cryptodev-linux/cryptodev-linux-1.7.tar.gz tar zxf cryptodev-linux-1.7.tar.gz cd cryptodev-linux-1.7/ sudo make sudo make install sudo depmod -a sudo modprobe cryptodev lsmod sudo sh -c 'echo cryptodev>>/etc/modules' cd ~ wget https://www.openssl.org/source/openssl-1.0.2a.tar.gz tar zxf openssl-1.0.2a.tar.gz cd openssl-1.0.2a/ ls ./config -DHAVE_CRYPTODEV -DUSE_CRYPTDEV_DIGESTS shared sudo make sudo make install Step 2: Test OpenSSL: /usr/local/ssl/bin/openssl speed -evp aes-128-cbc Results confirm hardware acceleration is functional Step 3: Making Tor use OpenSSL Added to /etc/apt/sources.list : deb http://deb.torproject.org/torproject.org jessie main deb-src http://deb.torproject.org/torproject.org jessie main deb http://deb.torproject.org/torproject.org tor-experimental-0.2.6.x-jessie main deb-src http://deb.torproject.org/torproject.org tor-experimental-0.2.6.x-jessie main Fixed the key nonsense sudo apt-get update sudo apt-get install build-essential fakeroot devscripts sudo apt-get build-dep tor mkdir ~/debian-packages; cd ~/debian-packages sudo apt-get source tor cd tor-* And it's here where I believe the problem lies: sudo nano debian/rules Add the two lines as shown on the "guide" such that mine reads: override_dh_auto_configure: ! [ -e debian/micro-revision.i ] || cp debian/micro-revision.i src/or/micro-revision.i dh_auto_configure -- \ $(confflags) \ --enable-static-openssl \ --with-openssl-dir=/usr/local/ssl \ --prefix=/usr \ --mandir=\$${prefix}/share/man \ --infodir=\$${prefix}/share/info \ --localstatedir=/var \ --sysconfdir=/etc \ --disable-silent-rules \ --enable-gcc-warnings-advisory sudo debuild -rfakeroot -uc -us Error message after 35m: 15/359 TESTS FAILED. (0 skipped) Makefile:6429: recipe for target 'test' failed make[1]: *** [test] Error 1 make[1]: Leaving directory '/home/debian/debian-packages/tor-0.2.6.7/build' dh_auto_test: make -j1 test returned exit code 2 debian/rules:16: recipe for target 'build' failed make: *** [build] Error 2 dpkg-buildpackage: error: debian/rules build gave error exit status 2 debuild: fatal error at line 1376: dpkg-buildpackage -rfakeroot -D -us -uc failed My thoughts: I noticed on the Tor FAQ here: https://www.torproject.org/docs/faq.html.en#RelayMemory That adding the malloc flag it done using the ./configure option, while I used nano. If that's the problem, how do I use configure for adding the other flags such as OPenSSL dir and static openssl. Also, I noticed that the path I add to the configure is not quite the same as the path used to test openssl's functionality. Also, the tor confflag mentions static openssl, but the openssl ./configure talked about being shared. Also, does the ordering other confflags matter? Is it asking for a static openssl prior to learning the directory of the correct library? I'm just trying to brainstorm why I'm getting this one error. Looking at the test log, looks like there's some kind of error in the self-test of the cryptographic engine, yet it works in OpenSSL by itself? Any help would be appreciated, thanks. Super long test log: onion_handshake: cryptodev_digest_update: illegal inputs FAIL ../src/test/test.c:84: assert(! onion_skin_TAP_create(pk, &c_dh, c_buf)) [onion_handshake FAILED] bad_onion_handshake: cryptodev_digest_update: illegal inputs cryptodev_digest_update: illegal inputs cryptodev_digest_update: illegal inputs cryptodev_digest_update: illegal inputs FAIL ../src/test/test.c:158: assert(! onion_skin_TAP_create(pk, &c_dh, c_buf)) [bad_onion_handshake FAILED] onion_queues: OK ntor_handshake: OK circuit_timeout: OK rend_fns: OK geoip: OK geoip_with_pt: [forking] OK stats: [forking] OK accounting/bwlimits: [forking] OK addr/basic: OK addr/ip6_helpers: OK addr/parse: OK addr/virtaddr: OK addr/localname: OK addr/dup_ip: OK addr/sockaddr_to_str: OK addr/is_loopback: OK addr/make_null: OK address/get_if_addrs_ifaddrs: [forking] OK address/ifaddrs_to_smartlist: OK address/get_if_addrs_ioctl: [forking] OK address/ifreq_to_smartlist: OK buffer/basic: [forking] OK buffer/copy: [forking] OK buffer/pullup: [forking] OK buffer/ext_or_cmd: [forking] OK buffer/allocation_tracking: [forking] OK buffer/time_tracking: [forking] OK buffer/zlib: [forking] OK buffer/zlib_fin_with_nil: [forking] OK buffer/zlib_fin_at_chunk_end: [forking] OK cellfmt/relay_header: OK cellfmt/begin_cells: OK cellfmt/connected_cells: OK cellfmt/create_cells: OK cellfmt/created_cells: OK cellfmt/extend_cells: OK cellfmt/extended_cells: OK cellfmt/resolved_cells: OK cellfmt/is_destroy: OK cellqueue/basic: [forking] OK cellqueue/circ_n_cells: [forking] OK channel/dumpstats: [forking] OK channel/flush: [forking] OK channel/flushmux: [forking] OK channel/incoming: [forking] OK channel/lifecycle: [forking] OK channel/lifecycle_2: [forking] OK channel/multi: [forking] OK channel/queue_impossible: [forking] OK channel/queue_size: [forking] OK channel/write: [forking] OK channeltls/create: [forking] OK channeltls/num_bytes_queued: [forking] OK channeltls/overhead_estimate: [forking] OK checkdir/perms: [forking] OK circuitlist/maps: [forking] OK circuitlist/rend_token_maps: [forking] OK circuitlist/pick_circid: [forking] OK circuitmux/destroy_cell_queue: [forking] OK config/resolve_my_address: [forking] OK config/addressmap: OK config/parse_bridge_line: OK config/parse_transport_options_line: OK config/parse_transport_plugin_line: [forking] OK config/check_or_create_data_subdir: [forking] OK config/write_to_data_subdir: [forking] OK config/fix_my_family: OK container/smartlist_basic: OK container/smartlist_strings: OK container/smartlist_overlap: OK container/smartlist_digests: OK container/smartlist_join: OK container/smartlist_ints_eq: OK container/bitarray: OK container/digestset: OK container/strmap: OK container/pqueue: OK container/order_functions: OK container/di_map: OK container/fp_pair_map: OK control/bucket_note_empty: OK control/bucket_millis_empty: OK control/sum_up_cell_stats: OK control/append_cell_stats: OK control/format_cell_stats: OK crypto/formats: OK crypto/rng: OK crypto/aes_AES: [forking] OK crypto/aes_EVP: [forking] OK crypto/sha: OK crypto/pk: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_crypto.c:427: assert(128 OP_EQ crypto_pk_public_encrypt(pk2, data1, sizeof(data1), "Hello whirled.", 15, PK_PKCS1_OAEP_PADDING)): 128 vs -1 [pk FAILED] crypto/pk_fingerprints: [forking] OK crypto/digests: OK crypto/dh: OK crypto/aes_iv_AES: [forking] OK crypto/aes_iv_EVP: [forking] OK crypto/base32_decode: OK crypto/kdf_TAP: OK crypto/hkdf_sha256: OK crypto/curve25519_impl: OK crypto/curve25519_impl_hibit: OK crypto/curve25519_wrappers: OK crypto/curve25519_encode: OK crypto/curve25519_persist: OK crypto/ed25519_simple: OK crypto/ed25519_test_vectors: OK crypto/ed25519_encode: OK crypto/ed25519_convert: OK crypto/ed25519_blinding: OK crypto/ed25519_testvectors: OK crypto/siphash: OK dir/nicknames: [forking] OK dir/formats: [forking] OK dir/routerparse_bad: OK dir/extrainfo_parsing: OK dir/parse_router_list: [forking] OK dir/load_routers: [forking] OK dir/load_extrainfo: [forking] OK dir/versions: [forking] OK dir/fp_pairs: [forking] OK dir/split_fps: OK dir/measured_bw_kb: [forking] OK dir/measured_bw_kb_cache: [forking] OK dir/param_voting: [forking] OK dir/v3_networkstatus: [forking] OK dir/random_weighted: OK dir/scale_bw: OK dir/clip_unmeasured_bw_kb: [forking] OK dir/clip_unmeasured_bw_kb_alt: [forking] OK dir/fmt_control_ns: OK dir/http_handling: OK dir/purpose_needs_anonymity: OK dir/fetch_type: OK dir/packages: OK dir/md/cache: [forking] OK dir/md/broken_cache: [forking] OK dir/md/generate: OK dir/md/parse: OK dir/md/reject_cache: [forking] OK entryconn/rewrite_basic: [forking] OK entryconn/rewrite_bad_dotexit: [forking] OK entryconn/rewrite_automap_ipv4: [forking] OK entryconn/rewrite_automap_ipv6: [forking] OK entryconn/rewrite_cached_dns_ipv4: [forking] OK entryconn/rewrite_cached_dns_ipv6: [forking] OK entryconn/rewrite_unmapped_virtual: [forking] OK entryconn/rewrite_mapaddress: [forking] OK entryconn/rewrite_reject_internal_reverse: [forking] OK entryconn/rewrite_automap_exit: [forking] OK entryconn/rewrite_mapaddress_exit: [forking] OK entryconn/rewrite_mapaddress_automap_onion: [forking] OK entryconn/rewrite_mapaddress_automap_onion2: [forking] OK entryconn/rewrite_mapaddress_automap_onion3: [forking] OK entryconn/rewrite_mapaddress_automap_onion4: [forking] OK entrynodes/entry_is_time_to_retry: [forking] OK entrynodes/choose_random_entry_no_guards: [forking] OK entrynodes/choose_random_entry_one_possibleguard: [forking] OK entrynodes/populate_live_entry_guards_1guard: [forking] OK entrynodes/populate_live_entry_guards_3guards: [forking] OK entrynodes/entry_guards_parse_state_simple: [forking] OK entrynodes/entry_guards_parse_state_pathbias: [forking] OK entrynodes/entry_guards_set_from_config: [forking] OK entrynodes/entry_is_live: [forking] OK guardfraction/parse_guardfraction_file_bad: [forking] OK guardfraction/parse_guardfraction_file_good: [forking] OK guardfraction/parse_guardfraction_consensus: [forking] OK guardfraction/get_guardfraction_bandwidth: [forking] OK guardfraction/should_apply_guardfraction: [forking] OK extorport/id_map: [forking] OK extorport/write_command: [forking] OK extorport/init_auth: [forking] OK extorport/cookie_auth: [forking] OK extorport/cookie_auth_testvec: [forking] OK extorport/handshake: [forking] OK hs/hs_desc_event: [forking] OK hs/pick_tor2web_rendezvous_node: [forking] OK hs/pick_bad_tor2web_rendezvous_node: [forking] OK introduce/early_parse_v0: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [early_parse_v0 FAILED] introduce/early_parse_v1: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [early_parse_v1 FAILED] introduce/early_parse_v2: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [early_parse_v2 FAILED] introduce/early_parse_v3: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0)cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [early_parse_v3 FAILED] introduce/decrypt_v0: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [decrypt_v0 FAILED] introduce/decrypt_v1: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [decrypt_v1 FAILED] introduce/decrypt_v2: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [decrypt_v2 FAILED] introduce/decrypt_v3: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0)cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [decrypt_v3 FAILED] introduce/late_parse_v0: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [late_parse_v0 FAILED] introduce/late_parse_v1: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [late_parse_v1 FAILED] introduce/late_parse_v2: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [late_parse_v2 FAILED] introduce/late_parse_v3: cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0)cryptodev_digest_update: illegal inputs FAIL ../src/test/test_introduce.c:381: assert(r >= 0) FAIL ../src/test/test_introduce.c:305: assert(r > 0) [late_parse_v3 FAILED] nodelist/node_get_verbose_nickname_by_id_null_node: [forking] OK nodelist/node_get_verbose_nickname_not_named: [forking] OK oom/circbuf: [forking] OK oom/streambuf: [forking] OK options/validate: [forking] OK policy/router_dump_exit_policy_to_string: OK policy/general: OK pt/parsing: OK pt/protocol: OK pt/get_transport_options: [forking] OK pt/get_extrainfo_string: [forking] OK pt/configure_proxy: [forking] OK pt/get_pt_proxy_uri: [forking] OK relay/append_cell_to_circuit_queue: [forking] OK relaycell/resolved: [forking] OK replaycache/alloc: OK replaycache/badalloc: OK replaycache/free_null: OK replaycache/miss: OK replaycache/hit: OK replaycache/age: OK replaycache/elapsed: OK replaycache/noexpire: OK replaycache/scrub: OK replaycache/future: OK replaycache/realtime: OK routerkeys/write_fingerprint: [forking] OK routerlist/initiate_descriptor_downloads: OK routerlist/launch_descriptor_downloads: OK routerset/routerset_new: [forking] OK routerset/routerset_get_countryname: [forking] OK routerset/routerset_is_list: [forking] OK routerset/routerset_needs_geoip: [forking] OK routerset/routerset_is_empty: [forking] OK routerset/routerset_contains__null_set_or_null_set_list: [forking] OK routerset/routerset_contains__set_and_nickname: [forking] OK routerset/routerset_contains__set_and_null_nickname: [forking] OK routerset/routerset_contains__set_and_no_nickname: [forking] OK routerset/routerset_contains__set_and_digest: [forking] OK routerset/routerset_contains__set_and_no_digest: [forking] OK routerset/routerset_contains__set_and_null_digest: [forking] OK routerset/routerset_contains__set_and_addr: [forking] OK routerset/routerset_contains__set_and_no_addr: [forking] OK routerset/routerset_contains__set_and_null_addr: [forking] OK routerset/routerset_contains__countries_no_geoip: [forking] OK routerset/routerset_contains__countries_geoip: [forking] OK routerset/routerset_add_unknown_ccs__only_flag_and_no_ccs: [forking] OK routerset/routerset_add_unknown_ccs__creates_set: [forking] OK routerset/routerset_add_unknown_ccs__add_unknown: [forking] OK routerset/routerset_add_unknown_ccs__add_a1: [forking] OK routerset/routerset_contains_extendinfo: [forking] OK routerset/routerset_contains_router: [forking] OK routerset/routerset_contains_routerstatus: [forking] OK routerset/routerset_contains_node__none: [forking] OK routerset/routerset_contains_node__routerinfo: [forking] OK routerset/routerset_contains_node__routerstatus: [forking] OK routerset/routerset_get_all_nodes__no_routerset: [forking] OK routerset/routerset_get_all_nodes__list_with_no_nodes: [forking] OK routerset/routerset_get_all_nodes__list_flag_not_running: [forking] OK routerset/routerset_get_all_nodes__list: [forking] OK routerset/routerset_get_all_nodes__nodelist_with_no_nodes: [forking] OK routerset/routerset_get_all_nodes__nodelist_flag_not_running: [forking] OK routerset/routerset_refresh_counties__geoip_not_loaded: [forking] OK routerset/routerset_refresh_counties__no_countries: [forking] OK routerset/routerset_refresh_counties__one_valid_country: [forking] OK routerset/routerset_refresh_counties__one_invalid_country: [forking] OK routerset/routerset_union__source_bad: [forking] OK routerset/routerset_union__one: [forking] OK routerset/routerset_parse__malformed: [forking] OK routerset/routerset_parse__valid_hexdigest: [forking] OK routerset/routerset_parse__valid_nickname: [forking] OK routerset/routerset_parse__get_countryname: [forking] OK routerset/routerset_parse__policy: [forking] OK routerset/routerset_subtract_nodes: [forking] OK routerset/routerset_subtract_nodes__null_routerset: [forking] OK routerset/routerset_to_string: [forking] OK routerset/routerset_equal__empty_empty: [forking] OK routerset/routerset_equal__empty_not_empty: [forking] OK routerset/routerset_equal__differing_lengths: [forking] OK routerset/routerset_equal__unequal: [forking] OK routerset/routerset_equal__equal: [forking] OK routerset/routerset_free__null_routerset: [forking] OK routerset/routerset_free: [forking] OK scheduler/channel_states: [forking] OK scheduler/compare_channels: [forking] OK scheduler/initfree: [forking] OK scheduler/loop: [forking] OK scheduler/queue_heuristic: [forking] OK socks/4_unsupported_commands: [forking] OK socks/4_supported_commands: [forking] OK socks/5_unsupported_commands: [forking] OK socks/5_supported_commands: [forking] OK socks/5_no_authenticate: [forking] OK socks/5_auth_before_negotiation: [forking] OK socks/5_authenticate: [forking] OK socks/5_authenticate_with_data: [forking] OK socks/5_malformed_commands: [forking] OK status/count_circuits: [forking] OK status/secs_to_uptime: [forking] OK status/bytes_to_usage: [forking] OK status/log_heartbeat__fails: [forking] OK status/log_heartbeat__simple: [forking] OK status/log_heartbeat__not_in_consensus: [forking] OK status/log_heartbeat__calls_log_accounting: [forking] OK status/log_heartbeat__packaged_cell_fullness: [forking] OK status/log_heartbeat__tls_write_overhead: [forking] OK util/time: OK util/parse_http_time: OK util/config_line: OK util/config_line_quotes: OK util/config_line_comment_character: OK util/config_line_escaped_content: OK util/expand_filename: OK util/escape_string_socks: OK util/string_is_key_value: OK util/strmisc: OK util/pow2: OK util/gzip: OK util/datadir: OK util/memarea: OK util/control_formats: OK util/mmap: OK util/sscanf: OK util/format_time_interval: OK util/path_is_relative: OK util/strtok: OK util/di_ops: OK util/round_to_next_multiple_of: OK util/laplace: OK util/strclear: OK util/find_str_at_start_of_line: OK util/string_is_C_identifier: OK util/asprintf: OK util/listdir: OK util/parent_dir: OK util/ftruncate: OK util/exit_status: OK util/fgets_eagain: OK util/format_hex_number: OK util/format_dec_number: OK util/join_win_cmdline: OK util/split_lines: OK util/n_bits_set: OK util/eat_whitespace: OK util/sl_new_from_text_lines: OK util/envnames: OK util/make_environment: OK util/set_env_var_in_sl: OK util/read_file_eof_tiny_limit: OK util/read_file_eof_one_loop_a: OK util/read_file_eof_one_loop_b: OK util/read_file_eof_two_loops: OK util/read_file_eof_two_loops_b: OK util/read_file_eof_zero_bytes: OK util/write_chunks_to_file: OK util/mathlog: OK util/weak_random: OK util/socket: [forking] OK util/socketpair: [forking] OK util/socketpair_ersatz: [forking] OK util/max_mem: OK util/hostname_validation: OK util/ipv4_validation: OK util/logging/sigsafe_err_fds: [forking] OK util/logging/sigsafe_err: [forking] OK util/thread/basic: [forking] OK util/thread/conditionvar: [forking] OK util/thread/conditionvar_timeout: [forking] OK

3 8

T-shirts and Confirming Relay Control
by Matthew Finkel 05 May '15

05 May '15

Hi Ops, We recently began responding to t-shirt requests again. Sorry for the long silence. There's been a lot happening around here but not enough time or people to do everything, so the t-shirt requests simply remained untouched. But, despite the overload, t-shirts are important because they are a small token of our thanks and appreciation for making the network what it is today. We responded to around 70 t-shirt requests from relay operators in April, which comprised all requests for which we could verify (within reason) the request came from the person who controlled the qualifying relay. We still have another 20 requests where the requestor is not obviously the owner of the relay. Currently the content of a relay's Contact field is used, but this does not always provide enough (or any) information. For this case, we need an authentication mechanism which proves control of the relay but is something relay operators won't mind running. My currently plan is to ask relay operators to sign the fingerprint file which tor creates. The major disadvantage of this method is that it must be run as root (or a user with access to tor's data directory). The following process is the current plan, but does anyone have a better idea? Does it seem logical? ------------------------------------------------------------ When we receive a t-shirt request from someone who isn't obviously in control of the relay, we ask them to sign their fingerprint file with a unique salt. Assuming the path to their data dir is /var/lib/tor, we ask them to run: $ (echo -n "salt "; cat /var/lib/tor/fingerprint) | openssl sha256 \ -binary | openssl pkeyutl -inkey /var/lib/tor/keys/secret_id_key \ -sign -pkeyopt digest:sha256 -pkeyopt rsa_padding_mode:pss \ -pkeyopt rsa_pss_saltlen:32 | openssl base64 > signed_fingerprint They send us both /var/lib/tor/fingerprint and signed_fingerprint. When we receive them, we confirm the fingerprint in the fingerprint file matches the qualifying relay. Then we retrieve the relay's public key from its descriptor and convert it into pkcs#8 format using: $ openssl rsa -pubin -in pubkey_pkcs1 -RSAPublicKey_in -out pubkey and then we verify the sig using following commands: $ (echo -n "salt "; cat fingerprint) | openssl sha256 -binary | \ openssl pkeyutl -pubin -verify -inkey pubkey -sigfile \ $(OUT=/tmp/signed_fingerprint_bin; base64 -d signed_fingerprint > \ ${OUT}; echo ${OUT}) -pkeyopt digest:sha256 -pkeyopt \ rsa_padding_mode:pss -pkeyopt rsa_pss_saltlen:32; rm \ /tmp/signed_fingerprint_bin; This should yield "Signature Verified Successfully". ------------------------------------------------------------ Another disadvantage of this is PSS wasn't implemented in openssl's apps until 1.0.1. I wonder how many relays are running on servers which are still using openssl 0.9.8 (and 1.0.0?). For these servers we can fallback on pkcs#1 v1.5 signatures. ------------------------------------------------------------ The signature can be created using a command similar to the one above: $ (echo -n "salt "; cat /var/lib/tor/fingerprint) | openssl dgst \ -sha256 | openssl rsautl -inkey /var/lib/tor/keys/secret_id_key \ -sign | openssl base64 > signed_fingerprint Again, they provide /var/lib/tor/fingerprint and signed_fingerprint, and we verify using: $ test "$(openssl base64 -d -in signed_fingerprint | openssl rsautl \ -pubin -verify -inkey pubkey)" = "$((echo -n "salt "; cat \ fingerprint) | openssl dgst -sha256)"; echo $? In addition, again, we confirm the fingerprint in the fingerprint file matches the fingerprint of the qualifying relay. ------------------------------------------------------------ Originally I used a few bashisms which made these simpler, but for this I suspect portability is important. Sorry this is a bit long. Thanks, Matt

11 19

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays May 2015