Tag Archives: SSL

Heartbleed SSL attack

The latest SSL attack in the form of Heartbleed ( ref. CVE-2014-0160 ) has burst onto the scenes in the last 24 hours with a bang. Effectively, Heartbleed is a weakness in OpenSSL that allows the theft of information that is under normal circumstances protected by SSL/TLS. It allows the memory of affected systems to be read and information extracted ( including passwords and other vulnerable information ), and it also allows the keys ( both public and private ) used on those systems to be compromised.

The solution is to upgrade to the latest version of OpenSSL ( 1.0.1g ) – however that alone may not be enough. If your site was compromised previously, there would be no trace of that attack and simultaneously, your keys may be compromised. So you may need to regenerate private and public keys for these systems.


The media coverage of this is extensive, and to be fair, this is a very serious issue. However, we need to consider what the attack surface is. And in my own testing, the attack surface is low to non-existent – every single client of mine that I’ve tested, does not have a vulnerable implementation of OpenSSL or is not using the SSL Heartbeat extension ( this may be simply because I stick to 2 Linux distros alone ). Is this issue being blown out of proportion? I can’t talk for others but my own experience says yes.

That’s not to say you should not be vigilant – as a security professional, it’s always best to err on the side of caution. Prevention is better than cure …

There are a number of tools available for testing purposes as well as online SSL checkers like those from Qualys and Comodo. Test and make sure you’re covered.

UPDATE: The guys who wrote masscan, scanned the entire internet today and released some interesting numbers on vulnerable systems: approximately 600,000 out of ~ 28 million SSL-enabled servers. That’s 2.1% … not an entirely significant no but still a big issue depending on which sites are vulnerable.

There has been a lot of calls in the media for users of websites to change passwords. Make sure though that you change your password AFTER the affected site has been sorted out otherwise you’re just perpetuating the issue.

OpenID and SSL/DNS poisoning

Ben Laurie of Google’s Applied Security team, while working with an external researcher, Dr. Richard Clayton of the Computer Laboratory, Cambridge University, found that various OpenID Providers (OPs) had TLS Server Certificates that used weak keys, as a result of the Debian Predictable Random Number Generator (CVE-2008-0166).

In combination with the DNS Cache Poisoning issue (CVE-2008-1447) and the fact that almost all SSL/TLS implementations do not consult CRLs (currently an untracked issue), this means that it is impossible to rely on these OPs.

In order to mount an attack against a vulnerable OP, the attacker first finds the private key corresponding to the weak TLS certificate. He then sets up a website masquerading as the original OP, both for the OpenID protocol and also for HTTP/HTTPS.

Then he poisons the DNS cache of the victim to make it appear that his server is the true OpenID Provider.

There are two cases, one is where the victim is a user trying to identify themselves, in which case, even if they use HTTPS to “ensure” that the site they are visiting is indeed their provider, they will be unable to detect the substitution and will give their login credentials to the attacker.

The second case is where the victim is the Relying Party (RP). In this case, even if the RP uses TLS to connect to the OP, as is recommended for higher assurance, he will not be defended, as the vast majority of OpenID implementations do not check CRLs, and will, therefore, accept the malicious site as the true OP.