- tor-relays - lists.torproject.org

Re: [tor-relays] Blutmagie does not see 0.2.7.2 bandwidth
by torrry＠Safe-mail.net 03 Aug '15

03 Aug '15

> debugging the old Blutmagie Perl scripts I found all routers like > splitDNA running Tor 0.2.7.2 sending two hash values in the > extra-info-digest. I suppose this isn't expected by the script parsing > the data. > > GETINFO desc/name/splitDNA > 250+desc/name/splitDNA= > router splitDNA 62.210.82.44 21 0 143 > [...] > extra-info-digest D6F7A98078BDA327D388D918EBA92D0FC9EDC487 > nMA7WhPSpQmquUdYpwIdQtdcKvTAcvNDnXleiPBia0U It shouldn't be expected by the script: https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt ------------------------------------------------------------------ "extra-info-digest" digest NL [At most once] "Digest" is a hex-encoded digest (using upper-case characters) of the router's extra-info document, as signed in the router's extra-info (that is, not including the signature). (If this field is absent, the router is not uploading a corresponding extra-info document.) ------------------------------------------------------------------- Fetching descriptors via: http://<DIR_SERVER>/tor/server/all has 2 values for extra-info-digest as well.

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

At 08:26 8/2/2015 -0700, you wrote: >I wonder if you could just run sslyze (or another >TLS scanning tool) on the OR ports of all the >relays, and see what ciphersuites they accept. The info would be indicative, but it would not reflect client-only Tor, which represents the majority of installations. Is why I think collecting connection statistics a good idea.

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

Of course! This is implicit in my posting. What I am saying is that, like old v1/v2 handshakes, Tor should be moving in the direction of eliminating DHE. The way to approach that is to *count* the number of DHE handshakes and other TLS session attributes. This is currently begin done for TOR/NTOR handshakes but is not for TLS negotiations. 0.2.7 will not build/run with openssl 0.9.8, so once 0.2.7 is widely deployed DHE can be forcibly disabled. BUT, as with v1/v2 handshakes, one would not want to do that prematurely so counting them is a good idea. That suggesting is the principle idea of the thread. At 20:01 8/2/2015 +0300, you wrote: >I think that is to maintain a backward >compatibility. Tor tries as hard as possible to >maintain backward compatibility with older >versions, unless something critical which requires >deprecation regardless some relays will disappear >from the consensus. > >I guess this is the reason we currently prefer >ECDHE but do not reject DHE. In the future, when >we are certain everyone upgraded to new enough >OpenSSL, we can safely reject DHE all the time. >

1 0

Re: [tor-relays] relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

At 08:26 8/2/2015 -0700, you wrote: >It also may not tell you their ordering >preference (but it might! again, >you'd have to look at the code.) That "openssl s_client" test I ran was against my 0.2.6.10 with openssl 1.0.2 relay. It's certain that ECDHE is preferred over DHE, but my thought is that, especially with 0.2.7 dropping openssl 0.9.8 (no ECDHE), that relays should refuse to accept DHE connections entirely. We've seen many downgrade attacks and who knows for certain if none remain buried in the openssl? Seems prudent to kill-off DHE.

2 1

relay's count handshake versions, why not TLS handshake types?
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

In the next-above thread I had mistakenly conflated relay handshakes and 'openssl' TLS negotiations, which are it seems entirely independent. Thanks to Yawning for correcting that misconception. TLS encryption protects the relay-to-relay conversation protocol if I understand correctly, while cells are further encrypted with EC curve 25519 for the actual layered/onion encryption. Per ticket https://trac.torproject.org/projects/tor/ticket/15212 relay handshake types are counted and logged in the heartbeat message with the idea that the old v1/v2 handshake support should soon be eliminated soon. Now I wonder why the TLS handshake types are not also counted with the idea that DHE-RSA-AES256-SHA should be eliminated entirely due the near certainty that the NSA can decrypt any such sessions negotiated using the default DH 1024 bit primes, per the LogJam research https://weakdh.org/ I know that 0.2.7 is eliminating 'openssl' 0.9.8 from the picture, but this does not prevent $ openssl s_client -connect addr:port -tls1 -cipher EDH from successfully establishing a connection to relay OR ports with the aforementioned suspect DHE encryption level. Seems to me forcible prevention of this level of TLS session should be nearly as important as moving to the new ed25519 identity keys. In addition to ECDHE vs DHE, it might make sense to count how many SSL 3, TLS 1.0, 1.1 and 1.2 connections are established to be certain SSL 3 is really dead and to see how quickly TLS 1.2 is fully supported everywhere. Perhaps which ECDHE curve is selected should also be tracked.

2 1

Tor 2.6.10 fails to generate fresh DH Keys
by starlight.2015q2＠binnacle.cx 02 Aug '15

02 Aug '15

>Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. > Looks like you have DynamicDHGroups enabled in your torrc file. This is interesting because the recent LogJam research indicates the NSA has probably broken commonly used 1024 bit DH groups, which suggests turning on this parameter. However it was disabled by default some time ago for anti-fingerprinting reasons: https://trac.torproject.org/projects/tor/ticket/5598 AND, it's probably a moot issue now that Ntor handshakes (elliptic curve) have overtaken older RSA connections. So you should delete DynamicDHGroups 1 from torrc and let it be disabled by default.

3 3

Tor 2.6.10 fails to generate fresh DH Keys
by cyb3rwr3ck 01 Aug '15

01 Aug '15

Hi there, after a unsuspected reboot of wr3ck3d0ni0n01 I decided to refresh all the keys. I took the chance to upgrade to 2.6.10 (Debian) and recognized that the relay wont start afterwards. It looks like it is unable to generate the new krypto: Aug 01 11:56:01.000 [notice] Tor 0.2.6.10 (git-71459b2fe953a1c0) opening log file. Aug 01 11:56:01.000 [notice] Generating fresh dynamic DH modulus. This might take a while... Aug 01 11:56:01.000 [err] tor_assertion_failed_(): Bug: ../src/common/crypto.c:1788: crypto_generate_dynamic_dh_modulus: Assertion r == 0 failed; aborting. Aug 01 11:56:01.000 [err] Bug: Assertion r == 0 failed in crypto_generate_dynamic_dh_modulus at ../src/common/crypto.c:1788. Stack trace: Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(log_backtrace+0x41) [0x7f892b3b3601] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0x9f) [0x7f892b3c0def] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(crypto_set_tls_dh_prime+0x7db) [0x7f892b3cfb1b] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(set_options+0x1ce5) [0x7f892b35ee25] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(options_init_from_string+0x2d3) [0x7f892b35f503] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(options_init_from_torrc+0x1ca) [0x7f892b35f81a] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_init+0x2e2) [0x7f892b2d1202] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(tor_main+0x55) [0x7f892b2d23a5] Aug 01 11:56:01.000 [err] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xfd) [0x7f8929bc2ead] Aug 01 11:56:01.000 [err] Bug: /usr/bin/tor(+0x362ad) [0x7f892b2cd2ad] I wasn’t able to find any known bugs regarding this behaviour. Anyone out there who has seen this before? Best regards! Felix

1 0

Re: [tor-relays] what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Ended up reading rephist.c for awhile. Seems the up/down time is accumulated with downtime discounted %5 every 12 hours. So absolute worst-case age-out for 100% downtime would be something like .95 ^ 76 (35.5 days) to get down it to 2%. Since the outage is not as bad as that, the guard flag should show up sooner. Not interested enough to calculated the exact answer. Will just watch it.

1 0

what is guard flag recovery time for outage?
by starlight.2015q2＠binnacle.cx 31 Jul '15

31 Jul '15

Does anyone know how long it takes for the guard flag to come back after a multi-day relay downtime? Know that WTU (weighted time up) is 98%, and new-relay TK (time known) minimum is eight days. Reading rephist.c the the WTU is calculated from uptime history but rather then spend awhile to fully understand it seemed worth asking. Presently watching a relay that has been around six weeks, has been down four days recently and five total, has 14-day 100% uptime, Globe- calculated 1-month uptime of 85% and 3-month uptime of 90%. Had guard a couple of times but has not seen it return after the last outage.

1 0

my provider null routed my exit. advice?
by Christopher Yeager 31 Jul '15

31 Jul '15

Hello, I run a 100mb exit hosted at server.lu since sometime in late 2013. There have been a couple dozen abuse reports but normally they forward them to me to deal with and nothing much happens. However a week or so ago, while I was travelling, there was an abuse report that made them decide to file a ticket which then led to them suspending my IP as I 'ignored' it while I was gone. So now I'm trying to convince them to turn the system back on and they are pushing back, and after some back and forth they say they want me to run an exit policy consisting of ports 53, 80, and 443. I've been running the suggested reduced exit policy since day one and am very reluctant to pare it down further, and certainly not to just 3 ports. I wrote a short note explaining my point of view and I wonder if any of you would do me the courtesy of telling me if I am likely to convince them to let me leave the exit policy alone. I'm very willing to edit my response as required. I think it bears mentioning that I am several messages in and I did not get a good sense that whoever I am talking to understands Tor very well at all - I was repeatedly asked to find and block my customer, and told I must have logs if I provide a service, etc. I can show you the longer exchange if you think it might be helpful. Thanks in advance and here goes: --- Hello, We have nothing against Tor but IP is listed at 11 blacklists including Spamhaus ZEN. So we have to ask you block all ports except 80, 53 and 443 to prevent scan, spam and other infringing activity from your IP. Hope such proposal will be suitable for you. Regards, ROOT S.A. --- Hello again, I would rather not block any more ports that are already blocked. The system is already set up to use the reduced exit policy detailed at https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy which allows as many Internet services as possible while still blocking the majority of TCP ports. Currently, the policy allows approximately 65 ports. I am reluctant to further reduce the ports because there is vastly more to the internet than just the world wide web. Email, chat, remote desktop, cache, and vpn services are all valid uses of the network that would not be allowed by such a restrictive exit policy. I'm also afraid that it will not help much in getting this IP off the various blocklists that it is on, as 2/3rds of the abuse reports I've been sent were due to traffic on ports 80 or 443. Several of the lists such as SECTOOR and Dans TOREXIT and related are simply reporting to the world that this system is a Tor node. The system is only in the Spamhaus Zen list due to its listing in the CBL for being "infected with, or is NATting for a machine infected with s_vawtrak" which is a Microsoft Windows virus that connected to their sinkhole IP on port 80. Being on blocklists is something that happens when you are running a Tor exit node and supporting Tor means putting up with them and explaining why Tor is worth supporting even though abuse is guaranteed to happen. Naturally if you require this change I will be forced to make it. I hope, however, that you can be persuaded that it is not helpful to Tor and will not solve the problem of abuse and blacklists even if it were. Thanks again. -- Thanks for getting this far. I await your replies with interest. :)

3 2