relay's count handshake versions, why not TLS handshake types?
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.
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. It won't be exactly symmetric - I'm not sure (one can investigate the code though) if those same ciphersuites will be the ones offered in a relay -> relay connection. It also may not tell you their ordering preference (but it might! again, you'd have to look at the code.) -tom On 2 August 2015 at 08:17, <starlight.2015q2@binnacle.cx> wrote:
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
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.
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (2)
-
starlight.2015q2ï¼ binnacle.cx -
Tom Ritter