SSL is compromised! Not!

The "SSL is hacked/broken/compromised" story is, as told by most "news" sites, an alarmist and information-free beat up, made by people who should know better! They mix up 4 different risks, 2 protocols and a good dash of FUD, and bake us up another Henny Penny headline that only serves to confuse people further!

The first thing that is not made clear by most "news" sites is that the original Blackhat paper actually discusses four different risks, but none of these risks have anything to do with a vulnerability in SSLv3.1 (aka TLS).

The first risk is that browsers (and, I guess, other HTTPS clients) might not check certificate basic constraints, and so may parse a bogus certificate chain in error.

The second risk is that commercial CAs may have poor certificate-signing operating procedures, and so may sign certificates without checking the credentials of the organisation that submitted the SR.

The third risk is that an attacker may compromise some host (either the client computer, or an intermediate router) and so may either poison/modify DNS records, or may introduce a malicious proxy service which is able to intercept HTTP/HTTPS traffic.

The fourth risk is that users may click on URLs contained in emails or on compromised/malicious web sites, and may therefore end up with a browser that talks to a malicious web server.

Its worth separating these four risks, in order to be able to assess your exposure.

Considering risk 1, the author notes that, should the browser not correctly parse each certificate in a cert chain, then the browser may accept a certificate for a bogus look-alike site. There was a vulnerability (in IE, I think) about 6 years ago, where the CA basic constraint was not checked. However, we are not aware of any current browser which currently fails to check basic constraints correctly. Assuming the client is using an up-to-date and patched browser, risk 1 is in general, rated as low.

Considering risk 2, the author notes that some CAs may have poor certificate-signing procedures and practices, and may therefore erroneously sign server or wildcard certs. This could certainly happen, but our experience with a couple of the commercial CAs is that their practices are very secure, and we have trouble in getting legitimate certs renewed (let alone signed for the first time) for many of our customers. Of course, all it takes is one mistake from a commercial CA for this kind of attack to be realised, but we would still see risk 2 as low.

Considering risk 3, the "news" sites imply that SSL/TLS is broken, and that an attacker can intercept and read HTTPS (encrypted) traffic. This is rubbish. Once an HTTPS session has been established between a legitimate client and server, no one (except maybe organisations with access to a couple of thousand years of CPU time, or some unpublished cipher back-door) can intercept the traffic. What the author *can* do is, compromise or create a malicious intermediate proxy-host, and trick the user into connecting to his malicious proxy-host, instead of the intended server site. This is where most of the sky-is-falling confusion seems to come from, so lets look at what we need to make this kind of attack work:

1. A HTTP/HTTPS proxy. No worries; that software is everywhere. I like web scarab the best, but everyone has their own favourites.
2. A computer/web-server to host the proxy on. Yep. I've got one of those too.
3. A means to get the user to connect to the proxy on my site. Now it gets tricker. For this step to work, I need to do (i), then also do either (ii) or (iii) as listed here: (i) Exploit the vulnerabilities associated with Risk 1 or 2, above. (ii) Corrupt the user's DNS. (iii) Compromise a router between the client and legit web site. If an attacker can achieve these goals, he/she can get the user to connect to their bogus HTTPS site, and can then proxy the HTTP traffic to/from the legit site for as long as they like. Of course, as outlined above, there are a couple of significant hoops to jump through first, so we are happy to rate risk 3 as low-medium.

And that leads us to consider risk 4: users may click on URLs contained in emails or on compromised/malicious web sites, and may therefore end up with a browser that talks to a malicious web server. The paper describes a neat way to trick users into clicking on a link, by registering a domain that includes i18n 'special characters' such as characters that look like slashes.

But look: If the user is going to click on links in emails, they (and/or the hosting site) is going to be attacked eventually.

Its hard to remember the number of 'secure' applications that we have reviewed over the years, which are vulnerable to scripting attacks, and which can be exploited by getting a user to click on an apparently legitimate link in an email or on a compromised web page. To be sure, the Blackhat paper is not talking about scripting attacks, but the technique of presenting an acceptable-looking URL by using i18n chars is conceptually no different to that of making acceptable-looking URLs by obfuscating malicious script parameters.

We rate risk 4 in general as high, because we know that most users will click on things they shouldn't, and we know that most web applications are vulnerable to attack. And that raises an interesting point: If an attacker knows that a web app is vulnerable (and most are), and if that web app requires client-side scripting (many do), then it is very likely to be significantly easier for the attacker to shadow the user's web session and steal keyboard strokes and screen shots via a scripting attack, than it would be to engineer an attack as described in Risk #3.

Which leads us to the end of this month's topic. In summary, the Blackhat paper presents some excellent techniques that have been shown to work in practice, but SSL/TLS has not been "hacked" or "broken". There are of course some risks as outlined above, which means that, of course, you should probably conduct a more formal risk assessment before considering your options. And those options are likely to include some combination of (for example) secure application deployment, 2-factor authentication, improved key and certificate management, secure DNS, and user-awareness. And a critical assessment of popular "news" sites that rely on alarmist headlines, rather than a detailed analysis.