19

Should I use SSL/TLS renegotiation? In other words: does SSL/TLS renegotiation enhance or weaken the security?

Bob Ortiz
  • 6,234
  • 8
  • 43
  • 90
Jim
  • 341
  • 1
  • 2
  • 5

3 Answers3

23

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 CertificateRequest message.

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.

Machta
  • 103
  • 2
Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949
  • 2
    I am still not clear.First of all, as I read there are 2 issues with renegotiation: 1) Denial Of Service 2)MITM attack. So far in your answer you are addressing only (2), right?Isn't (1) an issue? – Jim Nov 29 '12 at 07:43
  • 2
    Denial Of Service is an issue with SSL, regardless of renegotiation. In SSL, the client can make the server engage considerable CPU resources, without having to do so himself. Renegotiation is not a factor in that; in particular, renegotiation occurs only in a fully established connection, where the client _did_ play the game by the rules. – Thomas Pornin Nov 29 '12 at 12:19
  • 1
    From http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2011-5094: `which might make it easier for remote attackers to cause a denial of service (CPU consumption) by performing many renegotiations within a single connection`. Perhaps I am misunderstanding your comment? – Jim Nov 29 '12 at 12:30
  • 1
    Note that the CVE is marked as "disputed". A DoS occurs when the attacker can make the server spend more CPU than himself. It is more cost-effective _for the attacker_ to open a lot of connections than to do a lot of renegotiations in a given connection, because in the latter case the attacker has to do some cryptography, whereas in the former he does not need to. What the CVE means is that limiting the number of simultaneous connections is not sufficient for DoS protection; the server must also limit the rate of renegotiations (refusing a renegotiation is very cheap on the server). – Thomas Pornin Nov 29 '12 at 13:39
8

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.

user5994461
  • 1,216
  • 3
  • 12
  • 11
  • 4
    This is _way_ overoptimistic. It's true everybody turned renego off when the (first) attack was published, but within months almost all stacks implemented 5746 and most systems turned it back on, and left it on even when the modified triple-handshake variant (on _resumption_) came out. https://www.ssllabs.com/ssl-pulse/ shows 99% of top 150k servers affirming renego today, and only about 25% supporting TLS1.3 which _if used_ (only if client also supports) does exclude renego. I've never heard of _any_ downgrade attack on renego; can you give an example or two? – dave_thompson_085 Apr 23 '20 at 03:17
  • 2
    It's a fact that renegotiation was disabled and never enabled again. Open the Apache doc that's linked and see for yourself, the github history confirms it's been disabled for more than 10 years. Apache has around 30% market share so it's simply not possible that 99% of web servers do renegotiation as reported by ssl labs. I am certainly willing to admit that the inconsistency is troubling and there might be something we are both missing out. SSL is a nightmare of complexity. – user5994461 Apr 23 '20 at 14:10
  • 3
    Few pointers after heavy researching 1) The ssl labs report mentions secure renegotiation vs insecure renegotiation. 2) SSL has both client-initiated and server-initiated renegotiation, hard to find info about either 3) OpenSSL keeps "removed" functions/flags/capabilities but they do nothing, because if functions were removed it would break ABI compatibility and linking to ssl libraries. 4) Found serious issues about client authentication so am I going to mention that instead – user5994461 Apr 23 '20 at 14:23
2

During renegotiation an attacker can inject information into the connection. It is described in detail here.

Uwe Plonus
  • 2,267
  • 12
  • 14
  • 1
    Is it renegotiation *prior* to establishing a secure connection? – Jim Nov 27 '12 at 07:42
  • 2
    It is _re_negotiation, not negotiation. _Re_negotiation is during an established connection. – Uwe Plonus Nov 27 '12 at 07:43
  • 1
    I don't understand.So the idea is that a renegotiation is never done? – Jim Nov 27 '12 at 07:49
  • 1
    No, it only says that you have to be careful with renegotiation. [RFC 5746](http://tools.ietf.org/html/rfc5746) was created to circumvent problems with renegotiation. – Uwe Plonus Nov 27 '12 at 07:52