[nSLUG] Nasty zero day vulnerability in openssl CVE-2014-0160

Mike Doherty mike at mikedoherty.ca
Tue Apr 8 21:30:24 ADT 2014

Yes, this is all absolutely correct. I had been thinking about the time
frame in which a private key could have been obtained from the server,
but wrote about the time frame for traffic that could be retrospectively
decrypted. This is why PFS is so critical.

Unfortunately, certificate revocation is nearly useless, which is why
Chrome doesn't bother: "Revocation checks are like a seat-belt that
snaps when you crash. Even though it works 99% of the time, it's
worthless because it only works when you don't need it." I believe OCSP
stapling is the first revocation strategy that can help, and it isn't
widely used yet.


On 14-04-08 09:23 PM, Julien Savoie wrote:
> On 08/04/14 08:59 PM, Mike Doherty wrote:
>> You should consider using perfect forward secrecy if you don't already
>> do so. Without PFS, any traffic over the past 2 years (since the bug was
>> introduced into OpenSSL) can be decrypted if the private key is
>> compromised today. With PFS, that's not the case.
> Once your private key is lost you're in trouble.  Even if the traffic
> was encrypted with an entirely non-vulnerable version of openssl.
> The vulnerability was introduced 2 years ago, but once the private key
> has been compromised you can go back as far as you like (2 years not
> withstanding) and decrypt traffic provided it was encrypted with the
> compromised private key, and it was non-PFS.  For example, if your
> private key is 4 years old and someone captured non-PFS traffic sent to
> your server 4 years ago, they can now decrypt it.  That is assuming
> they've used heartbeat overruns to extract your private key, or any
> other mechanism for that matter.
> Even if the private key was generated with openssl 0.9.8 and lost with
> 1.0.1, the traffic encrypted with 0.9.8 is vulnerable to decryption. 
> Even with PFS, once your private key has been compromised you maybe
> freely MITM'ed.  Revoking and re-issuing doesn't necessarily stop MITM
> if the browser isn't checking to see if the certificate has been revoked.
> _______________________________________________
> nSLUG mailing list
> nSLUG at nslug.ns.ca
> http://nslug.ns.ca/mailman/listinfo/nslug

More information about the nSLUG mailing list