Ivan Ristić

Is RC4 safe for use in SSL?

I received a rather interesting and informative couple of emails last week from Paweł Krawczyk, who wanted to make a point how RC4 is still safe to use in SSL. I thought that his comments would be of interest to a wider audience, so here they are (with permission):

[...] TLS_RSA_WITH_RC4_128_MD5 [...] is extremely widespread among commercial servers. Main reasons are 1) it's default preferred cipher in most versions of IIS, 2) these two algorithms are absolutely fastest and least CPU-intensive.

However, because there are known cryptoanalytic attacks against both RC4 and MD5, this ciphersuite is notoriously reported as "weak" by some pentesting tools and teams.

This is not true or at least not accurate, as the specific usage of RC4 and MD5 - in SSLv3 with 128 bit key - has no known and working attacks. That's one reason why PCI-DSS v1.2 now doesn't list any specific algorithms for SSL but instead just says you should use "strong" ones. And widespread usage of TLS_RSA_WITH_RC4_128_MD5 among financial organisations seems to confirm the interpretation that it's still considered a strong ciphersuite.

On the other hand NIST SP 800-52 doesn't allow neither RC4 or MD5 because they're not FIPS-approved algorithms, with one exception - connecting in client mode to external, commercial systems with this specific ciphersuite enabled. Which seems to set the balance quite even, because SP is only binding for US federal agencies.

And...

There are two reasons why the new attacks do not apply to RC4-based SSL. First, SSL generates the encryption keys it uses for RC4 by hashing (using both MD5 and SHA1), so that different sessions have unrelated keys. Second, SSL does not re-key RC4 for each packet, but uses the RC4 algorithm state from the end of one packet to begin encryption with the next packet. The recent techniques of Fluhrer, Mantis and Shamir thus do not apply to SSL.

Further resources:

• RSA Security Response to Weaknesses in Key Scheduling Algorithm of RC4
• Forgery and Partial Key Recovery attacks on HMAC and NMAC using Hash Collisions (PDF; concludes HMAC-MD5, HMAC-SHA1 - No immediate practical threats)

Black Hat 2009 SSL Review: Breaking the Myths of Extended Validation SSL Certificates (Alexander Sotirov and Mike Zusman)

Sotirov's and Zusman's talk (the paper and the slides available for download) is a practical exercise in breaking the assurance provided by EV certificates, building on the discovery Collin Jackson and Adam Barth made in their paper Beware of Finer-Grained Origins:

Extended Validation. The browser’s scripting policy does not distinguish between HTTPS connections that use an Extended Validation (EV) certificates from those that use non-EV certificates. For example, Pay- Pal serves https://www.paypal.com/ using an EV certificate, but a principal who has a non-EV certificate for www.paypal.com can inject script into the PayPal login page without disrupting the browser’s Extended Validation security indicators...

The above has the following implications:

1. EV sites generally use components that are delivered from other non-EV SSL places. Thus, if you have a valid non-EV certificate in the name of the server used for the component delivery, you can subvert the EV site.
2. Sotirov and Zusman also point out that browsers don't perform SSL certificate pinning, happily accepting a request from a site with an EV certificate, followed by a request from the same site using another certificate. That allows for what they call SSL Rebinding. Through the same-origin policy, a subverted document delivered with a non-EV certificate can assume control of an EV site.
3. They further point that it is possible to perform SSL cache poisoning, which is a side-effect of the caching subsystem in browsers being separate from the security system. For browsers, a file from a non-EV site is the same as a file from a EV site:
   1. A user is somehow lead into requesting a file supposedly from an EV site (e.g., a script file), but the file is delivered by an attacker performing a MITM attack and using a valid non-EV certificate.
   2. The user goes to the real EV site, at which point his browser will attempt to refresh the previously cached script file.
   3. If the EV site responds with an 304 (Not Modified) response, the browser will continue to use the subverted version of the script.

Sotirov and Zusman offer a number of suggestions to fix the above problems, but admit that most of them are not likely to happen. The problem here is that it is the browser vendors who should be pushing the security envelope (no one else is in a position to do it), but doing so would break sites and the vendors, who are primarily focused on winning market share, won't risk breakage. The only realistic solution seems to be to make it possible for sites to elect to be more secure so that, in time, we can upgrade to a more secure Internet.

I still maintain that a comprehensive solution (in a way similar to that I proposed in the Secure Browsing Mode document) is the best way forward. Band aids can only do so much and, for once, we need to do a job properly.

Black Hat 2009 SSL Review: More Tricks For Defeating SSL In Practice (Moxie Marlinspike)

Moxie Marlinspike has a story to tell, and it's a story about SSL implementation flaws. His talk at Black Hat 2009 (get the slides and the movie from Black Hat Archives) is a continuation of his previous activities, which go way back, as early as 2002 (or something). I liked this talk, because it was delivered in a low key, here-is-what-I-discovered, way.

1. You first learn about the chained certificate validation flaws from the past, which were possible basically because X.509 is complex and programmers don't understand it. It was possible to exploit such flaws with the use of any valid certificate.
2. Moxie wrote and published his first SSL tool, sslsniff, because Microsoft claimed the chained certificate validation flaws could not be exploited. This tool automates the exploitation and makes MITM attacks really simple (as most Moxie's SSL tools do).
3. Next comes sslstrip, again a MITM tool, which relies on the fact that most people first browse using plain-text and let sites guide them to SSL. The tool strips away the links to SSL, leaving the user to communicate via plain-text.
4. The new stuff is about the same problem Dan Kaminsky pointed out in his talk (but independently discovered), which is that most SSL implementations are vulnerable to NUL-byte attacks. As a result, it is possible to get a CA to sign a certificate that effectively allows you to impersonate a web site you do not own. Combining this attack with a wildcard certificate, you get a certificate that can be used to impersonate any web site.
5. Moxie further discovered that it was possible to interfere (from a MITM position) with OCSP certificate validation to prolong a life of a revoked certificate. 
6. Even worse, he discovered that it was possible to use a NUL-enriched wildcard certificate to subvert the Firefox and Thunderbird update mechanism.

The good thing about implementation flaws is that they are reasonably quick and easy to fix. The first issue is old news, so it's not a problem any more. The new flaws (#4, #5 and #6) are either fixed (I know they were fixed in Firefox) or will be fixed soon. You can make sure you're using a version of the browser that is not vulnerable. There's going to be a lot of people using older browsers, who are going to remain vulnerable. To help them, it is the CAs who are going to have to make sure they don't issue any more rogue certificates.

Although sslstrip is old news, I am worried about the fact that people can't recognise when a connection (to a web site) is insecure. No, scratch that. Why should people need to recognise that? I know how to and I do, but that's only out of necessity. I am really more worried about the fact that it's necessary to think about such things at all. Web sites should just be secure, period.

Short term, EV certificates help. That really means that they help me and you, but I don't believe they help normal (i.e., non-security) people. Can we do anything to help them? A solution comes to mind, and it consists from two parts:

1. Use only SSL and make plain-text connections impossible.
2. Refuse to connect to web sites that do not have valid certificates.

Black Hat 2009 SSL Review: Black Ops of PKI (Dan Kaminsky)

SSL was again in the centre of attention at Black Hat USA this year (2009). I say SSL, as do many others, but most of the discussion wasn't about SSL but, rather, about the technologies on which it relies. I will cover the Black Hat SSL talks in a series of blog posts, the first of which I publish today.

Dan Kaminsky's talk (get it here as a QuickTime movie) has several very interesting points, but it fails on delivery. When you take the interesting bits out, the rest is a strange mixture of ranting, sarcasm, irrelevant detours and unproductive technology bashing, which I didn't enjoy. Here's my summary of what Dan said:

1. Humans are imperfect.
2. We generally care first about getting things done, with security always an afterthought (if we're lucky).

If you want to be more specific, that translates to:

1. We don't know how to write secure code.
2. We are using tools and languages that are inherently insecure (e.g., the C programming language, with its buffer overflows and NUL-terminated strings).
3. Specifications are often ambiguous.

It's hardly news. My biggest complaint to Dan's talk (his attitude aside) is that he doesn't tell us how to improve things. He mentions DNSSEC as a possible improvement, but how do we guarantee that DNSSEC and its implementations do not suffer from the same problems that plague our software today?

The very interesting new points (what Dan really said), are as follows:

1. MD2 is insecure, yet we are slow in retiring it. There's even one commonly deployed root certificate signed with it. This one MD2 signature could be abused through an preimage attack. Such an attack is not practical today, but it may become practical soon enough for us to be worried. Dan apparently orchestrated a synchronised removal of MD2 from the popular programs and libraries, which is great.
2. CAs, programs and libraries all have issues with input validation, the result of which is that it's possible to get a certificate with a NUL byte in the common name. This is the issue that was independently discovered by Moxie Marlinspike, who also spoke at Black Hat. (I will discuss his talk in a subsequent post.) The differences in the interpretation of such common names allow such certificates to be abused so that you get a certificate that works for the domains you do not own. It's even possible to get a wildcard certificate that works for all domain names (in some browsers). This problem is being fixed. (As an aside, Dan doesn't mention the alternative names field, so we don't know if it's vulnerable too. It would be very ironic if everyone would fix the problems in the common name field, yet leave the alternative names vulnerable. Perhaps that's an opportunity for a talk next year.)
3. It is possible for certificates to have more than one common name (e.g., the domain name, in the context of SSL servers), but its implementation-specific which one will be used.
4. Ambiguities in ASN.1 (which is used to encode certificates) and flaws in ASN.1 implementations can be used to insert OIDs that some consumers interpret as common names, but others don't.

Improved SSLv2 detection in SSL Labs

One of the benefits of public testing is that you get exposed to, well, real life. I love that phase of development because you generally get to polish your code until it is perfect. Thus, after my SSL server assessment service went online, I monitored its performance closely, expecting to encounter a number of unforeseen cases, or cases that I didn't handle well.

One such area was SSLv2 detection. My first approach was to simply detect the cases where servers accept to negotiate a SSLv2 connection, but I soon discovered two edge cases:

1. Some servers have SSLv2 enabled, but all of the SSLv2 cipher suites disabled. Technically, although they support SSLv2, it is impossible for the handshake to complete, which has the same end result as protocol disablement.

2. Some servers accept SSLv2, but they always respond with a special error message to all requests. This is actually a very good idea from the usability point of view. An SSLv2 user connecting to a server that does not support SSLv2 is only likely to get a cryptic error message from their browser, which may leave him wondering what to do. Accepting a connection, only to deliver a user-friendly error message is a very good idea.

Now, dealing with the first case is easy: you just keep a would-be SSLv2 connection open for a bit longer. A failure to negotiate a cipher suite means SSLv2 connections are effectively impossible.

Handling the second case is difficult because there is no standard way to deliver user-friendly protocol errors. For example, this is what Amazon gives you (I suspect the error page is delivered by the load balancer, although it's perfectly possible to implement it on the application level):

HTTP/1.1 500 Internal Server Error
Connection: close
Content-Length: 309
Content-Type: text/html

<html><body><b>SSL Protocol Alert</b><p>The SSL protocol version that your
browser uses is SSLv2 and it is not compatible with the server settings.
</p><p>Please try the following:</p><p>- Check the SSL protocol settings
on your browser for SSLv3/TLSv1 protocol support and enable the same.
</p></body></html>

Amazon is kind enough to indicate that there is a problem by setting the response code to 500, which is easy to detect. Adding a check for this special case was easy. In a general case, however, I can't just assume that everyone is going to do the right thing. I know they won't. So, for the time being, I am logging all unusual responses to requests over SSLv2 connections. In time I plan to automate the detection by observing if the tested site "looks" substantially different over SSLv2 (not sure what exactly that means, but I will figure it out).

Thanks to Bo and Brandon, who emailed me to discuss the above two issues.