The vulnerability applies in situations where:
- The attacker can do a MitM at the network level (usually through DNS poisoning or by operating a fake open WiFi access point).
- A Web site offers some services over HTTPS.
- Some parts of the Web site require a user authentication.
- The Web server accepts to to SSL/TLS renegotiations.
- The Web server is ready to retroactively apply authentication to previous requests.
The last point is the crucial one. To understand it, let's see how the attack proceeds:
- The client (victim) C wants to connect to the server S. However, the attacker A intercepts the connection at the TCP level and answers it himself.
- The client C sends its
ClientHello SSL/TLS message to the attacker.
- The attacker connects, as a client, to the server S. The attacker then proceeds to do a normal SSL/TLS handshake with the server.
- The attacker injects a command X to the server S (the kind of command that requires user authentication).
- Somehow, a renegotiation is triggered: this is a new handshake, complete with messages, performed within the already established A->S SSL connection.
- For that renegotiation, the attacker simply sends the
ClientHello from the client C (who is still waiting) and forwards the subsequent messages back and forth between client and server. The nifty trick here is that the handshake is the initial one from the point of view of the client, but a renegotiation from the point of view of the server.
- During or immediately after the handshake, the server authenticates the client; and then, somehow, the server just assumes that it has been talking to the same client all along, and applies that authentication to the command X that it receives before the renegotiation. The server executes the command X in the name of the client C, whereas the command was injected by the attacker.
How can this happen ? The important point is that the server receives the command X from what is, at this point, an unauthenticated client, but does not execute it right away. The server waits for the renegotiation to occur, and then some sort of authentication, and only then processes the command. In an HTTPS request, this can realistically happen only if the server triggers the renegotiation itself, and expects the second handshake to provide the authentication. This relates to the layered nature of HTTPS: it is HTTP-within-SSL, so everything that happens at the SSL level is transparent for the HTTP layer. Once the HTTP request X is received, the server delays the response until all the SSL-level tasks have been performed.
So, in practice, such things happen when using client certificates. This is typical of how Microsoft IIS operates:
- Client connects to server. During the first handshake, the server knows the server name that the client sees in the target URL (through the Server Name Indication extension) but not the URL. The server does not request a client certificate.
- When the first handshake has been completed, the client sends the actual HTTP request. At that point, and only at that point, the server learns the target URL, with the complete path and parameters. The server then realizes that the request is for a portion of the site that requires certificate-based client authentication.
- Before responding to the request, the server triggers a renegotiation; this time, the server asks for a client certificate.
- After the second handshake, the server knows that it is talking to the right client, and executes the HTTP request.
IIS requests client certificate only on specific paths, not for a complete server, mainly because user interfaces offered by browsers for user certificate selection are, let's say, aesthetically suboptimal. In fact they are downright frightening for an average user. User certificates are a rarity; very few servers work with them.
Therefore, the only plausible scenario where the TLS renegotiation vulnerability applies is a Web server that requires client certificates, and works like IIS does. If you do not use certificate-based client authentication, then the vulnerability is not a problem (well, at least, I see no way this vulnerability could be leveraged). On the other hand, if you do use client certificates, then the vulnerability is a very serious one and is not hard to exploit (all it takes is a 100$ device). Thus, the involved risk is either "none" or "high", depending on system architectural characteristics that tools like nessus cannot guess automatically; nessus then responds with "medium" which, in this case, really is a "depends" or "maybe".
Note that the vulnerabilities comes from the fact that the very same handshake messages are used for the initial handshake and for a renegotiation. The fix for that vulnerability really is a way to unambiguously mark ClientHello messages as either "initial" or "renegotiate", so that the server may detect foul play. But it works only if both client and server support it, and the server refuses to talk to client that do not support that extension. Nessus is telling you that your server accepts to talk to clients who do not support the extension, and thus are potentially vulnerable (depending on whether the server will require client certificates in the IIS way). There is a trade-off: by enforcing the extension support, the server adds protection in some cases, but also breaks compatibility with old legacy browsers (which may or may not be a desirable thing).
From a conceptual point of view, the real problem is that the SSL/TLS standards describe the renegotiation but never explain what security characteristics are really achieved through it. IIS just assumed, wrongly, that retroactive authentication was part of these characteristics.
