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

BWauth no-consensus state in effect
by starlight.2015q3＠binnacle.cx 04 Aug '15

04 Aug '15

At Tue Aug 4 20:16:17 UTC 2015 by Jannis Wiese mail at janniswiese.com >Strange thing: My relay [0] is speeding up since then >significantly (finally!!) That's because with no BWauth quorum the consensus algorithm reverts to using self-measured bandwidth with a ceiling of 10000. This causes the weight super-fast relays to drop substantially and provides a corresponding boost to middle and slower relays. Also puts most of the 450 Unmeasured=1 relays back in the game. In addition, this … [View More]

1 0

Blutmagie does not see 0.2.7.2 bandwidth
by starlight.2015q2＠binnacle.cx 04 Aug '15

04 Aug '15

FYI list https: // torstatus DOT blutmagie DOT de is registering relays running 0.2.7.2 as having zero bandwidth. I believe this is because the write-history read-history lines in extra-info have moved from the top down to the middle of the document. Many super-fast relays running 0.2.7.2 are showing zero bandwidth and have dropped to the bottom of the ranking as a result. Might be a bug in 'metrics-db' or it might be a bug in a Blutmagie customization. Seems that the code at … [View More]

3 5

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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 … [View More]

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/… [View More]

1 0