One of the issues Context encounters time and time again is web servers that support version 2 of the SSL protocol. The weaknesses in SSL2 are a significant issue that has been known about for fifteen years [1], they can aid an attacker in decrypting traffic between his victim and the target website. However, considering the severe consequences, surveys have shown 35% of web servers on the internet still support it [2]. This blog post explains the biggest weakness in SSL2; the method used to exploit it, and asks the question, should SSL2 be keeping you awake at night?
For those who aren’t already intimate with version 2 of the SSL protocol, we’ll start with a quick explanation of why it is flawed, and then how attackers can take advantage of its weaknesses.
First of all, SSL is not an encryption scheme; amongst other things it is a protocol for agreeing the type of encryption to use for a secure connection. This is done by a series of ‘handshakes’ where the client and the server describe to each other which kinds of encryption they support. The fundamental flaw in SSL version 2 is that the cipher agreement part of this 'handshaking' is performed unencrypted and unauthenticated. An attacker in a position to modify traffic between his victim and target website can simply swap out all the strong ciphers and leave only the weakest ones, resulting in a weak cipher being chosen. The attacker can then set about cracking the weakly encrypted session without the server or victim noticing anything untoward with the encrypted connection.
Fortunately this weakness was noticed in 1996 and the later SSL version 3 fixed the problem. In fact, of the modern browsers which make up over 70% of online traffic, the following table shows that by default none of them support SSL2. So why are we still reporting it?
However, as anyone who works in web development will know only too well, Microsoft’s infamous Internet Explorer 6 still accounts for around 10% of browsers online [3]. Originally IE6 supported only SSL2, and despite security patches enabling SSL3 as default, a man in the middle attacker can still trivially knock it back to using SSL2 by exploiting its fallback mechanism [4].
So where does this leave us in terms of a good night’s sleep? Well clearly anyone who can be sure the browser being used by their user base is not IE6 can stop reading here, safe in the knowledge their users will not be going anywhere near SSL version 2. For example those in charge of internal corporate sites or intranets where browsers are controlled by the IT department have nothing to fear from SSL2 as user browsers will by default protect them from it. But what does this mean for those who own an Internet facing website used by a variety of Internet citizens, for example an online banking site?
The irony is that support for SSL2 is not the only security problem with IE6. In fact, it is vulnerable to much worse than the SSL2 attacks. The vulnerability tracking website Secunia states that IE6 currently has 23 unpatched vulnerabilities, some of which allow trusted site content spoofing and remote code execution. This means if your users are running IE6, the SSL2 issue is probably the least of your worries. This point was demonstrated when hackers targeted a code execution vulnerability in IE6 to breach Google’s security last year [5].
Of course there is still a threat, but it’s worth pointing out that the cipher downgrade attacks rely on the server supporting weak ciphers. If the servers only support strong ciphers, the man in the middle will never be able to downgrade the connection to use weak encryption. So by eliminating weak ciphers the SSL2 cipher downgrade attack can be mitigated.
There are other weaknesses with SSL2 though, and we will still recommend that SSL2 is disabled in all situations as part of a defence in depth approach; a key principle of good security practice. We do appreciate though that for businesses security is always a balance between risk and cost, so the real question for IT decision makers is probably “can I justify the cost involved in disabling SSL2 on all my servers”? The answer to this question will differ for every situation, for example if you want PCI compliance. But hopefully this blog post has thrown some light around the real issue, and the next time the reader sees “Support for Weak Protocol SSLv2” in one of our reports, they’ll have a better understanding of the real threat... or lack of.
References
[1] - The Open Source Vulnerability Database - 56387: SSLv2 Protocol Multiple Weaknesses
[2] - Internet SSL Survey 2010
[3] - Netmarketshare.com: Browser Version Market Share
[4] - Adrian Dimcev: SSL/TLS version rollbacks and browsers
[5] - Microsoft’s Internet Explorer flaw behind Google’s security breach