tor-relays June 2017

tor-relays@lists.torproject.org

46 participants
40 discussions

Exit node restarts itself.
by Alan 22 Jun '17

22 Jun '17

I've started to see my Exit node restart itself. There is a warning in the log pointing to a problem with OpenSSL but I don't know how to proceed. Jun 21 03:07:03.000 [notice] Tor 0.2.9.10 (git-1f6c8eda0073f464) opening new log file. Jun 21 03:07:03.619 [warn] OpenSSL version from headers does not match the version we're running with. If you get weird crashes, that might be why. (Compiled with 1000105f: OpenSSL 1.0.1e 11 Feb 2013; running with 1000105f: OpenSSL 1.0.1e-fips 11 Feb 2013). Jun 21 03:07:03.647 [notice] Tor 0.2.9.10 (git-1f6c8eda0073f464) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1e- ips and Zlib 1.2.7. Jun 21 03:07:03.647 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jun 21 03:07:03.647 [notice] Read configuration file "/usr/share/tor/defaults-torrc". Jun 21 03:07:03.647 [notice] Read configuration file "/etc/tor/torrc". Jun 21 03:07:03.650 [notice] Based on detected system memory, MaxMemInQueues is set to 1464 MB. You can override this by setting MaxMemInQueues by hand. Jun 21 03:07:03.650 [warn] Tor is running as an exit relay. If you did not want this behavior, please set the ExitRelay option to 0. If you do want to run an exit Relay, please set the ExitRelay option to 1 to disable this warning, and for forward compatibility. Jun 21 03:07:03.650 [notice] Opening Socks listener on 127.0.0.1:9050 Jun 21 03:07:03.650 [notice] Opening Control listener on 127.0.0.1:9051 Jun 21 03:07:03.650 [notice] Opening OR listener on 0.0.0.0:8081 Jun 21 03:07:03.651 [notice] Opening Directory listener on 0.0.0.0:8080 Jun 21 03:07:03.000 [notice] Not disabling debugger attaching for unprivileged users. Jun 21 03:07:03.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip. Jun 21 03:07:03.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6. Jun 21 03:07:03.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now. Jun 21 03:07:03.000 [warn] Fixing permissions on directory /var/lib/tor Jun 21 03:07:03.000 [notice] We were built to run on a 64-bit CPU, with OpenSSL 1.0.1 or later, but with a version of OpenSSL that apparently lacks accelerated support for the NIST P-224 and P-256 groups. Building openssl with such support (using the enable-ec_nistp_64_gcc_128 option when configuring it) would make ECD H much faster.

4 8

keypair does not match its older value
by Alexander Nasonov 21 Jun '17

21 Jun '17

Hi, I tried moving a tor relay with offline master key to a new host but something went wrong and it printed several warnings: http status 400 ("Looks like your keypair does not match its older value.") response from dirserver What did I screw up and how to fix this problem if it happends again? I suspect it will happen again because I generate a new signing key more frequently than necessary. I create '15 days' key every week and upload it (over onion ssh connection). This scheme should be resistant to occasional upload failures but it's not clear which of the last three signing keys to use on restart. If passing the wrong key can bring down the relay I need to switch to a different scheme. I'm thinking about adding these commands to my crontab: $ crontab -l @weekly scp "${DESTDIR}/keys/ed25519_signing_cert" "${DESTDIR}/keys//ed25519_signing_secret_key" ${ONION:?}: @monthly tor --hush --keygen --SigningKeyLifetime '1 month' "${DESTDIR:?}" && {{{scp command from the previous line}}} Are there any potential problems with this approach (e.g. 28 days in Feb vs 31 days in March)? -- Alex

4 5

artikel5ev.de: tor relays and the danger of end to end correlation
by nusenu 21 Jun '17

21 Jun '17

Hi, thanks for running relays! would you mind fixing the MyFamily in your torrc files? https://nusenu.github.io/OrNetStats/ https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#see-httpsww… dc6jgk15TEST has been around since 2017-04-27 (more than a few hours or days of 'test') thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

1 0

Re: [tor-relays] Consensus Weight calculation
by Vort 21 Jun '17

21 Jun '17

>> Are there any news regarding that problem? > It's a complicated problem. > We need to work out why it is happening before we can fix it. I am not sure if I really can help with BwAuth's algorithms. But that's what I would do in such situation: First, most important thing, is a clear goal. As BwAuth's task is to make a measurements, then theirs result must be clearly defined. So, the question is - how an ideal "w" ([Consensus] Weight) looks like? Suppose we have some perfectly measured parameters for relay: perfect_measured_bandwidth (KiB/sec) and perfect_measured_latency (sec). Their exact definition can be omitted now for simplicity. Then ideal_w should be equal to: ideal_w = perfect_measured_bandwidth ideal_w = k * perfect_measured_bandwidth ideal_w = k * perfect_measured_bandwidth / perfect_measured_latency or, maybe, something else? Once this question is clear, then it is possible to see how existent implementation is far from this ideal. And here is part two: why it is different? It is some noise that can't be eliminated? Or algorithm for some reason converges to incorrect values? BwAuths have some debug information. This can help to investigate problem. There are also the possibility of doing manual checks. Which then can be compared to debug logs of BwAuth. Maybe my approach is not so good and you will choose another. But, anyway, thanks for working on this problem. -- Vort

1 0

Exit notice in Spanish
by ilv＠torproject.org 20 Jun '17

20 Jun '17

Hola, I wanted to let you know that at derechos digitales we wrote a basic tor exit notice in spanish. You can find it in [1] and a mirror in [2]. We look forward to receive feedback from the community to improve it (content, ui, etc), hoping that it could be useful to other relay operators. We have also added legal info of some countries. Feedback and contributions in this matter are welcome as well :) p.s.: someone on global-south list also told me about [3]. [1] https://0xacab.org/tortola/exit-notice [2] https://github.com/derechosdigitales/tor-exit-notice [3] https://github.com/chgans/tor-exit-notice Saludos. -i

1 0

I would lime to poste on this list
by Andree-anne Tremblay 20 Jun '17

20 Jun '17

Tank you

1 0

sharing tor relay at night or working hours ? make sense ?
by Zalezny Niezalezny 20 Jun '17

20 Jun '17

Hi, I have 100mbit Up/Down connection at home. Most of the day, my connection is not use. Mostly between 22:00-17:00. I would like to share my Internet connection for Tor. If I will setup some crontabs to start/stop my tor relay between that hours, will it work ? Does it make sense ? Will TOR network know that my relay is working only between 22:00 and 17:00 and will push some more traffic to me ? How to properly configure such a relay which is working only for a few hours per day ? Cheers Zalezny <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campai…> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

7 8

libzstd and/or liblzma
by Felix 15 Jun '17

15 Jun '17

Hi nusenu thanks again for your responses ! > the context of that line is longer in the original changelog: > https://gitweb.torproject.org/tor.git/tree/ChangeLog?id=tor-0.3.1.2-alpha#n… That's where I got it from >> Might ports archivers/zstd only do the job (OR-type): >> >> Tor 0.3.1.2-alpha (git-61625b8f26384a4a) running on >> FreeBSD with Libevent 2.1.8-stable, OpenSSL LibreSSL 2.5.3, >> Zlib 1.2.8, Liblzma N/A, and Libzstd 1.2.0 > > see the related comment by the FreeBSD port maintainer: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219571#c2 Good hint. When I follow the link I find the archivers/zstd port will be included which seems up to date (libzstd.so.1.2.0, 30 Jul 2016). That's what I did. Fine. Which is the right port for lzma ? When I try to include archivers/lzmalib (liblzma.so.1.1.0, 23 Sep 2008) I find it un-maintained, old and Tor does not configure for it: checking for LZMA... no configure: WARNING: Unable to find liblzma. checking for ZSTD... yes Is there a better lzma port ? -- Cheers, Felix

2 1

torservers.net: some exits became guards? (deanonymization risk)
by nusenu 15 Jun '17

15 Jun '17

Dear Torservers, are you aware that you have recently become a relay operator with end-to-end correlation (deanonymization) capabilities? (in fact you are the biggest known such operator) This is especially bad for tor clients because you are also one of the biggest tor exit operators. Some of your relays which used to be exits recently became guard-ony relays. https://nusenu.github.io/OrNetStats/endtoend-correlation-groups#httpswwwtor… Is there anything I can help you with to fix this and reduce the risk for tor clients? thanks, nusenu -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

5 7

IP space for Tor exits - any takers?
by Moritz Bartl 12 Jun '17

12 Jun '17

Hi, After some trouble and ongoing discussions with one of our IP providers, we're again toying with the idea of registering IP space with RIPE ourselves. We can apply for a /22, which can be split into four /24s and announced at different locations (254 addresses each). Until now, we tried to avoid that, because we don't have enough "other things" to put on the same netblocks, so basically "one exit" would waste 254 precious IPv4 addresses (the full /24 address block needs to be announced from one location). But lately, with the rising amount not of abuse but of automated notifications and scared ISPs, and with the sponsoring of up to 10GE by Community-IX, we would really like at least one /24. Gareth from Brasshorn has graciously offered a spare /24 of his. The alternative would be that we apply for our own IP space, which would in turn mean that we could supply three other organizations with a /24 for their exit(s), or bridges. For bridges it is actually not that crazy, even if the range is "known" and easy to find: Most censors won't auto-detect them easily, and even if some do, the bridges are still valuable in many other locations. Also, this would allow for a bit of experimenting with tarpitting, different decoy strategies, etc. In terms of WHOIS information, the /24 can be segregated further, so an option would be to use a location where you have other uses for larger number of IP addresses. If you like the idea, and have actual use for a /24, please contact me off-list and explain what exactly you would like to do with it. If we have three other organizations (or reliable individuals) and a couple of good use cases, we're willing to apply for the /22. -- Moritz Bartl https://www.torservers.net/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-relays June 2017