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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Hello,
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
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
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
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,
