- tor-relays - lists.torproject.org

Tor relay
by Cryptic Admin 27 Jun '17

27 Jun '17

Tor relay

1 0

申请
by 龚明福 26 Jun '17

26 Jun '17

1 0

Re: [tor-relays] I've suddenly started seeing a lot of these in our exit's logs
by tor＠t-3.net 25 Jun '17

25 Jun '17

>> On 23 Jun 2017, at 04:57, tor(a)t-3.net wrote: >> >> >> I've suddenly started seeing a lot of these in our exit's logs: >> >> Rejecting INTRODUCE1 on non-OR or non-edge circuit ...…. > >Did you upgrade the Tor version on your relay recently? >What are the old and new versions? > >(I'm guessing that this was part of the 0.2.9.11 or 0.3.0.8 bugfix, >but it's hard to tell without further info.) > >T > >-- >Tim Wilson-Brown (teor) > >teor2345 at gmail dot com >PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B >ricochet:ekmygaiu4rzgsk6n >xmpp: teor at torproject dot org No changes server-side. These just starting popping up out of nowhere. Not saying they are a malfunction and the code isn't doing exactly what it's supposed to - just that it's happening. Our tor version is a bit old compared to the ones you listed. Do you know what the correct repo is that we should be using for Tor for CentOS/RedHat ?

2 1

torservers.net relays still putting tor users at risk
by nusenu 25 Jun '17

25 Jun '17

Moritz wrote (2017-06-10): > Our MyFamily statements are badly out of > sync. Will fix this next week. you are still putting tor users at risk https://nusenu.github.io/OrNetStats/ -- https://mastodon.social/@nusenu https://twitter.com/nusenu_

2 2

Performance
by Sebastian Urbach 25 Jun '17

25 Jun '17

Dear list, I noticed a higher CPU load on my Exit since i recently upgraded from 0.2.9.x to 0.3.0.x and thought maybe it is just a matter of tweaking the config for 0.3.0. I could not find anything wrong and checked: https://metrics.torproject.org/torperf.html Is it just me or does that looks like a major Performance Downgrade for the whole Network since 0.3.0.x was introduced ? Looks to me like roughly 50% or more loss of Performance depending on the File size. Was that to be expected for 0.3.0.x ? -- Sincerely yours / M.f.G. / Sincères salutations Sebastian Urbach --------------------------------------------------------------------------- Those who surrender freedom for security will not have, nor do they deserve, either one. --------------------------------------------------------------------------- Benjamin Franklin (1706-1790)

3 3

I've suddenly started seeing a lot of these in our exit's logs
by tor＠t-3.net 23 Jun '17

23 Jun '17

I've suddenly started seeing a lot of these in our exit's logs: Rejecting INTRODUCE1 on non-OR or non-edge circuit .......

2 1

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