Bonjour,

Je sais que la version 2 du handshake Tor utilisait la renégociation : https://gitweb.torproject.org/torspec.git/plain/tor-spec.txt

In "certificates up-front" (a.k.a "the v1 handshake"), the connection initiator always sends a two-certificate chain, consisting of an X.509 certificate using a short-term connection public key and a second, self-signed X.509 certificate containing its identity key. The other party sends a similar certificate chain. The initiator's ClientHello MUST NOT include any ciphersuites other than:

• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA

In "renegotiation" (a.k.a. "the v2 handshake"), the connection initiator sends no certificates, and the responder sends a single connection certificate. Once the TLS handshake is complete, the initiator renegotiates the handshake, with each party sending a two-certificate chain as in "certificates up-front". The initiator's ClientHello MUST include at least one ciphersuite not in the list above – that's how the initiator indicates that it can handle this handshake. For other considerations on the initiator's ClientHello, see section 2.1 below.

Le handshake v2 a été introduit en mars 2008 : https://gitweb.torproject.org/torspec.git/commit/tor-spec.txt?id=7ba878d5184024d15fef52090bddc3fb296a9692
Le handshake v3 a été introduit en octobre 2011: https://gitweb.torproject.org/torspec.git/commit/tor-spec.txt?id=6630c95e4c9736b3c4ecb6e8f576d817840ec1d3

Le handshake v3, qui s'effectue intégralement à l'intérieur du lien SSL, remplace le handshake v2. Les raisons qui ont amené à l'abandon de la renégociation sont présentées ici : https://gitweb.torproject.org/torspec.git/plain/proposals/169-eliminating-renegotiation.txt

Late in 2009, researchers found a flaw in most applications' use of TLS renegotiation: Although TLS renegotiation does not reauthenticate any information exchanged before the renegotiation takes place, many applications were treating it as though it did, and assuming that data sent before the renegotiation was authenticated with the credentials negotiated during the renegotiation. This problem was exacerbated by the fact that most TLS libraries don't actually give you an obvious good way to tell where the renegotiation occurred relative to the datastream. Tor wasn't directly affected by this vulnerability, but its aftermath hurts us in a few ways:

• OpenSSL has disabled renegotiation by default, and created a "yes we know what we're doing" option we need to set to turn it back on. (Two options, actually: one for openssl 0.9.8l and one for 0.9.8m and later.)
• Some vendors have removed all renegotiation support from their versions of OpenSSL entirely, forcing us to tell users to either replace their versions of OpenSSL or to link Tor against a hand-built one.
• Because of 1 and 2, I'd expect TLS renegotiation to become rarer and rarer in the wild, making our own use stand out more.