By now everyone has likely heard of heartbleed. It is a dangerous exploit that reveals the contents of a server's memory to the web on any server running an unpatched or pre 1.0.1 version of OpenSSL. The fear by most is that the private key of a servers SSL Certificate may have been compromised since servers keep that information in RAM at some point.
- Disclaimer: Facebook and other sites used in this article are used mearly as a familiar example and are not known at this time to be vulnerable of anything *
When an attacker gets your SSL Private key it enables them to sign SSL traffic as your site. This mean if the attacker has facebook.com's private key, they can impersonate facebook.com and have you send traffic to facebook.com and through various ARP and DNS poisoning have you really be sending data to them. Historically SSL has mitigated this type of attack because if you expect to send traffic to https://www.facebook.com the attacker won't have a valid cert and private key for that domain so you will see an error that says the certificate being used is invalid. However with this attack its possible for a private key to be compromised to an attacker could have a valid Public Cert and the real private key being used by facebook.com so you would never know, they would decrypt your traffic with private key then read/store it, then re-encrypt it and pass it to facebook, get a response and pass it back to you. This is known as a Man In The Middle attack.
Ok, so now you are probably thinking, can't a website just say that that certificate should be disposed of. Yes, they can and most already have, there are 2 protocols for this, 1 is a Certificate Revocation list, this is basically a blacklist that software can download and check to see if the certificate being provided to them has been revoked. The other is a more complicated protocol called OCSP ( Online Certificate Status Protocol ) which is a more realtime protocol for asking a TLS/SSL certificate provider if a certificate has been revoked or not.
The failure here is products like Google Chrome and Firefox do not trust that OCSP / CRLs work. The view it as single point of failure and are worried about false positives / negatives. If a client has to wait for a response from a CRL or OCSP this increases latency, if they service is overloaded or down it would esentially tell every user that the cert of the site they are looking for is invalid, much distrust. So, the solution was to disable CRL checking by default, fine I mean how often is this even a problem, rarely in the world of modern webapps, until heartbleed.
Today every major news outlet is telling everyone in the world, change your password ASAP. This, while well intentioned, and the typical response is horrible advice. With potential SSL certificates being compromised and a broken Certificate revocation system, its likely more password will be compromised via MITM (Man-In-The-Middle) attacks than were ever compromised in the original heartbleed attack.
The solution is simple, before changing your password ensure that the browser you are using is doing revocation checks and then don't disable these checks until every site you trust's existing certificate has expired. Also do not use a browser that has these checks disabled, you need to ensure the check is done on every browser you use.
Not all SSL providers support OCSP or CRLs, the list will be huge after heartbleed and could slow down access to SSL websites. CRL checking may also cause issues while in captive portals such as hotel wifi or large Enterprise wifi networks. Even with the check on you cannot be sure the site is secure, but most major sites you used Amazon, Facebook, Banks should be on the lists if they revoke a cert. Also, a MITM attacker could block OCSP and CRL lists, making the problem even worse considering most browsers use a soft-fail approach where if they cannot determine if a certificate is revoked, they assume it is not.
If you have questions tweet @j_mcnally
Resouces
Sources