Should I use SSL/TLS renegotiation? In other words: does SSL/TLS renegotiation enhance or weaken the security?
The problem is not in doing a renegotiation; it is in believing in security characteristics that the renegotiation does not provide.
Renegotiation is making a new handshake while in the middle of a SSL/TLS connection. This is described in the standard, albeit not in very clear terms, especially when it comes to defining what guarantees renegotiation offer.
Renegotiation is very common when used with client certificates, especially with IIS. Things go like this:
- Server receives a connection request on port 443; it begins a handshake. The server does not ask for a client certificate.
- Once the handshake is completed, the client sends the actual target URL as a HTTP request in the SSL tunnel. Up to that point, the server did not know which page was targeted; he only knew, at best, the intended server name (through the Server Name Indication). Now that the server knows which page is targeted, he knows which "site" (i.e. part of the server, in IIS terminology) is to be used.
- If the specific site requires or at least demands certificate-based client authentication, the server triggers a new handshake, this time with a
The security issue here is a question of layers. Handshake messages appear "under the cover" as administrative out-of-band administrative interactions, around the main "application data" traffic, which is just HTTP. Once the new handshake has been performed, any subsequently sent application data is covered by the authentication umbrella of SSL. However, what of the application data which was sent before the second handshake, in particular the initial HTTP request which decided the server to perform a second handshake, or, crucially, other HTTP requests pipelined after it (but before the new handshake) ?
It so happens that Web servers tended to just assume that whatever authentication was just performed in the second handshake could be "transported" to previous data, retroactively. It so happens that it is not true. That's never clearly said in the SSL/TLS standard, but such authentication only acts in a forward way: no time travel. The important word in the previous paragraph is "subsequently". This allowed an actual attack (see this page for pointers to extensive explanations).
A crucial point for the practical attack is that the second handshake messages are indistinguishable from the handshake messages for a new connection (i.e. a "first handshake"). RFC 5746 describes the patch, which has been implemented in major browsers and servers (which we assume to be up-to-date with security fixes; otherwise, you are in big trouble anyway). This is also what OpenSSL reports as "Secure Renegotiation". Note that the RFC candidly says that:
While this extension mitigates the man-in-the-middle attack described in the overview, it does not resolve all possible problems an application may face if it is unaware of renegotiation.
In other terms, this is a patch to fix a demonstrated issue, but it does not claim to cover all grounds. What renegotiation really offers is still not clearly defined anywhere. If your clients and server support "Secure Renegotiation" then things are fine for now (it prevents all currently known attacks). The whole concept of renegotiation and interleaved handshakes is still sorely in need of a more formal analysis.
As of 2020, TLS renegotiation is no more because it was insecure.
- Renegotiation is removed from TLS 1.3 onward, year 2018.
- All major software disabled renegotiation by default since as far as 2009 (nginx, haproxy, etc...). See Apache SSLInsecureRenegotiation notes for example.
- Renegotiation has a variety of vulnerabilities by design, forcing clients to downgrade connections to less secure settings than they would normally do.
- Verifying the client certificate for mutual authentication is handled separately than a renegotiation. See SSL_verify_client_post_handshake() in OpenSSL
- CVE-2009-3555 all implementations, CVE-2011-5094 in Mozilla, CVE-2011-1473 in OpenSSL, CVE-2014-1771 in Windows SSL.
That being said, there seem to be noteworthy issues with client-authentication support lacking over HTTP/2 or TLS1/3 or both.
- If you rely on client authentication, better test extensively and check the bug reports below.
- Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=911653
- Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1511989
- Python httplib: https://bugs.python.org/issue37440
- TLS 1.2 clients used to abuse renegotiation to perform authentication, but renegotiation is entirely gone in TLS 1.3. Clients must be upgraded to do post-handshake authentication.
- HTTP/2 breaks both renegotiation and post-handshake authentication because of pipelining. Pending draft RFC 8740 to standardize on a workaround.
During renegotiation an attacker can inject information into the connection. It is described in detail here.