What needs to be done on a Citrix Netscaler to protect from SSL Renegotiation attacks?

Question

I'm under the impression that the TLS/SSL renegotiation hack has been fixed. I'm not sure if the software has to be deployed on the server side, client side, or both.

Based on this blog, TLS renegotiation is a good thing, but only if done securely... and disabling TLS renegotiation is only a temporary workaround until the server (and clients??) get patched.

Is this understanding correct?

If SSL Labs says my netscaler supports "insecure renegotiation", what must I do to make it secure?

Citrix says the vulnerability is "fixed" in newer versions of the software, but what must I do to enable it?

What is confusing me is an internal discussion that this should be disabled on the load balancer with the option of "client". I'm not sure what that means in reality.

Answer 1

Here is an explanation of what this "renegotiation hack" is all about.

An SSL/TLS session begins by a procedure called the "handshake": right after connecting, the client and the server exchange a few administrative messages in which cryptography happens, and afterwards client and server have a shared session-specific secret with which subsequent data is encrypted and integrity-protected. The secure tunnel is established.

The renegotiation is the ability to perform a second handshake within the tunnel. The administrative messages are then encrypted and integrity-protected (with the shared secret which has been established through the first handshake), and they result in a second shared secret, which then replaces the previous one.

Why would anybody want to do that ? Mainly to circumvent the combined shortcomings of HTTPS and Web browsers, in particular Internet Explorer.

It so happens that during the handshake, the server shows his certificate (by which the client authenticates the server), and may request that the client does the same, i.e. present a certificate and use the corresponding private key. The client is free to deny the request (i.e. not to send a certificate) and this is not nominally fatal to the handshake (the server may elect to continue the handshake). Client certificates are rare, but are considered nifty, notably because they avoid the issues with user-chosen passwords (they have their own issues, but not the same). Some banks use client certificates, which they issue themselves to their customers.

Now HTTPS is HTTP-within-SSL. The client (browser) connects to the server, establishes a SSL tunnel, and then, within the tunnel, sends an HTTP request (or several successive HTTP requests, with keep-alive). The tricky point is that the server knows the target URL only at that point, because it is part of the HTTP request; and that's after the handshake. So the server should decide whether to ask for a client certificate or not before knowing the actual target URL.

Unfortunately, requesting a client certificate triggers some inconvenient behaviour in some browsers. In particular, Internet Explorer 6.0, upon receiving a request for a client certificate from the SSL server, displays the following "helpful" popup:

This screenshot is for a French version of Windows, but you get the point: a technical-looking popup asking to select a client certificate within... an empty list. Indeed, IE 6.0 scans the certificates in the local machine for one which matches the request from the server, and shows the popup even if there is none. This kind of behaviour is apt to confuse users, in particular a bank customer who does not have a certificate yet, since he is coming to the bank Web site for the first time, and may opt to register for the certificate-based client authentication system. That is, if he has not been scared away.

IE 9.0 appears to be better behaved in that respect, but the idea remains: client certificates are not well handled by Web browsers with regards to UI, so servers wish to request client certificates only for specific parts of the site which only "trained" (registered) users will try to reach. But since the handshake happens before the sending of the target URL, we need a renegotiation. Things are supposed to happen that way:

• A client connects. A handshake is performed, and the server does not ask for a client certificate. The client is not authenticated yet.
• The client sends the HTTP request within the newly established SSL tunnel.
• The target URL in the request is part of the "registered area" (it is a "GET /registered/index.html" request). The server says Aha! The user must be registered, let's do the SSL thing again, this time with a client certificate.
• The server asks for a new handshake (a renegotiation). This time, the server asks for a client certificate. The client complies. Note that this renegotiation happens at a "lower layer" than the HTTP request; the HTTP request is still pending at that time.
• Now that the server has positively authenticated the client, he may grant the request, and send the HTTP response within the second tunnel, which has replaced the first.

---

Now let's have a look at the hack. The important characteristics of SSL renegotiation are the following:

• The new handshake can be initiated by the server or the client at any time (the scenario explained above assumes that the server triggers the renegotiation, but in SSL the client could trigger it too).
• The whole handshake business happens at the tunnel level, regardless of the applicative data (the HTTP requests and responses) which are transported in the tunnel.
• The handshake messages for a renegotiation are byte-to-byte identical to what they would be for a first handshake (except that for a renegotiation, the messages go through the encryption layer established by the first handshake).

So, now, the attack. We assume a server like the one described above. Moreover, some requests that can be sent to the server have an "effect" which requires client authentication, and is valuable to the attacker (e.g. a request for a fund transfer). So the attacker first puts himself in a Man-in-the-Middle situation: he can intercept, and modify at will, the bytes exchanged between client and server. The following scheme illustrates how the attack goes:

The attack steps are thus:

1. The honest client wants to connect, and thus sends the first handshake message (dubbed "ClientHello").
2. The attacker temporarily blocks that message. Then, the attacker establishes a SSL tunnel of his own with the server, as if he was a normal client. Since the attacker is in the MitM position, he can mimic the client in all its details, including alleged IP address. The server does not ask for a client certificate yet, so the tunnel can be built successfully.
3. Within his tunnel (that's the red part in the schema above), the attacker sends an HTTP request, for a funds transfer.
4. The server says: "hold that thought, client, for a funds transfer I need to authenticate you with a certificate". And the server initiates a renegotiation, by sending (to the attacker) an "HelloRequest" message.
5. The attacker then forwards, encrypted in his tunnel, the initial ClientHello sent by the honest user (who is still waiting at that point).

At that point, the client believes that he is doing his first handshake, and exchanges handshake messages as cleartext. The attacker intercepts them all and encrypts them within the tunnel he established with the server; the attacker also decrypts the handshake messages from the server and sends them to the client. From the point of view of the client, this is the first handshake ever for this connection; from the point of view of the server, this is a renegotiation. But since the handshake messages are identical for both types of handshakes, this works. The honest client successfully concludes his handshake with the server, even though the messages have been transported by the attacker. The server is now content with the authentication from the client...

... and the server just assumes that the client authentication is valid for everything it exchanged since the first handshake, including the POST request made by the attacker. And that is the security issue.

---

So, who is to blame and how to fix ?

The trouble is that while the TLS specification describes the notion of renegotiation, it does not detail the actual security properties which are achieved in such a situation. Roughly speaking, the renegotiation establishes new cryptographic properties which have a forward effect. Notice that in all of the above, the fundamentals of SSL have not been violated: the honest client does a handshake with the server, with authentication, and whatever the client and server send after that handshake is protected and authenticated.

But in our attack scenario, the server wishes to transport the client authentication, obtained through the renegotiation, over data which was received before the renegotiation (the POST request). That's a backward effect, and, as shown above, this is not part of what SSL renegotiation provides.

So we can blame:

• the TLS specification, for not being clear about what renegotiation actually does;
• the server designers, for just assuming a backward transport of authentication;
• the HTTPS designers, for putting HTTP within a SSL tunnel instead of integrating SSL into HTTP with a STARTTLS command;
• the Web browser implementers, for their terrible handling of client certificates.

Blaming is fun but not constructive, so let's see to the fix. For the specific scenario described above, the fix is RFC 5746. It consists in modifying some handshake messages so that messages for a first handshake and for a renegotiation are distinct from each other. Coupled with the cryptographic binding inherent to handshake messages (a handshake message ends with verification messages which are computed over a hash value of the previous messages, so our MitM attacker cannot alter the contents of the handshake messages), this fixes the issue described above. For a more generic solution, the biggest difficulty is defining what we really want; but we know that it entails making the upper layers (e.g. HTTP) aware of the cryptography which occurs underneath. One can have a look at RFC 5056 for a discussion on the subject.

Another possible fix is to modify the application protocol so that the server does not try to transport the authentication in the backward direction. In an HTTP context, this would entail responding to the first request (the unauthenticated request which urged the server into making a new handshake) with an HTTP temporary redirect, so that the client sends the HTTP request again, this time after the new handshake (so the server would first make the new handshake, then send the redirect response).

We may note that the same issue does not raise with client authentication with passwords (HTTP "basic" authentication within a SSL tunnel) because with such an authentication, the server asks for a password, and the client sends it after repeating the target URL. So the issue is not applicable to many Web sites.

Apparently, Citrix found it fit to publish fixes, but without much details. They do not say whether they just changed the way the server asks things (a server-only fix), or whether they implemented RFC 5746, which is a fix only as long as the client supports the extension too. Firefox has supported RFC 5746 since February 8th, 2010. For Internet Explorer (actually Windows, since IE uses Windows' SSL/TLS code), this was part of a patch published on August 10th, 2010.

Possibly, Citrix Netscaler was not affected at all, but the people at Citrix found it smart, as part of Public Relations, to show that they feel concerned about security issues, and added a "fix" which would be more psychological than technical.

My advice would be: apply the patches published by Citrix, and make sure that the client software (OS, browser...) is up-to-date (something which you already want anyway). Then you should be safe from that obscure TLS renegotiation issue.

Answer 2

I am assuming you are talking about the TLS renegotiation Denial of Service issue SSL Labs reports on their automated SSL scans? If so, I would personally ignore the SSL Labs warning unless you really have a particular rare situation which makes it a concern. I think it's highly over-rated as a more serious issue than it really is. I also saw it on one of the scans I performed with their tool, and was surprised it popped up with a red warning.

If you read their own details, and particularly follow the link they include to the very good analysis of the trade-offs on Eric Rescorla's blog, I hope you can then appreciate why this vulnerability might be overstated.

Some quotes:

SSL Labs page

Although that won't substantially help you overall (defending against DoS attacks is notoriously difficult and expensive), it will harden your defences against this particular technique.

Eric Rescorla

Briefly then, we've taken an attack which was previously limited by network bandwidth and slightly reduced the bandwidth (by a factor of about 2 in packets/sec and less than 10% in number of bytes) at the cost of significantly higher computational effort on the attacker's client machines. Depending on the exact characteristics of your attack machines, this might be better or worse, but it's not exactly a huge improvement in any case.

The very brief gist of the analysis, as far as I can interpret it, is that whilst it's a possibile vector for Denial of Service. It doesn't in fact give the attacker much benefit over the much simpler Denial of Service attack involving establishing lots of SSL connections to your server. The latter is usually far easier to execute.

So whilst there might be tweaks and fixes to SSL to prevent client-initiated renegotiation, I doubt they will do much to protect you against DoS since the attackers are still able, and are very likely to use some botnet and simply try to establish bazillion SSL connections (or even simpler SYN floods) to accomplish this instead.