Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

When we read about TLS Renegotiation vulnerability, does it mean that a server is not supposed to ever accept renegotiation during a secure connection?
I thought that by renegotiation security is enhanced. No?

share|improve this question
    
Security can be enchanced, if you do not downgrade the cipher suite:) –  fatfredyy Nov 27 '12 at 7:34

2 Answers 2

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.

share|improve this answer
    
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 7:43
    
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
    
From 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
    
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

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

share|improve this answer
    
Is it renegotiation prior to establishing a secure connection? –  Jim Nov 27 '12 at 7:42
    
It is _re_negotiation, not negotiation. _Re_negotiation is during an established connection. –  Uwe Plonus Nov 27 '12 at 7:43
    
I don't understand.So the idea is that a renegotiation is never done? –  Jim Nov 27 '12 at 7:49
    
No, it only says that you have to be careful with renegotiation. RFC 5746 was created to circumvent problems with renegotiation. –  Uwe Plonus Nov 27 '12 at 7:52

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.