Misconceptions about Mitigating Heartbleed

When my team caught wind of the Heartbleed OpenSSL vulnerability we immediately responded with a blur of auditing and patching and restarting services on all of our affected systems. (I mean, of course we did, didn’t everyone else?)

That followed with the tedious process of rekeying every single SSL certificate that was used on those systems. It took quite a bit of time, but we put together a process to verify that everything got changed (we’ll get to that shortly). When done, we revoked our old certificates.

Some customers came to us with their own minted cert/key pairs and we eventually got those deployed too. Some of that was fully automated, but not everything. At least we had a script that did most of the heavy lifting for the stuff that isn’t self-service.

It took around a few days to work through everything, but eventually we were done and back to our usual duties.

And then Lastpass released a checker tool that purportedly determines whether or not certificates were recently reissued. It seems it is done by looking at the issue date of the SSL certificate. Customers were notifying us that our certificates have not been reissued when in fact they were.

I mean, after all, if a cert was reissued after April 7’th when the disclosure took place, then we know then it got rekeyed and all is well again, right?

WRONG.

It isn’t the certificate body that indicates whether or not a private key changes. It’s the RSA modulus. When you generate an RSA private key to create a certificate request with to rekey a certificate, your computer selects two really large prime numbers and multiplies them together. That product is the modulus. This value can be accessed via:

For certificates:

openssl x509 -in cert.pem -noout -modulus

For private keys:

openssl rsa -in cert.key -noout -modulus

If you wanted to check the modulus of a remote server:

 echo "01 logout" | openssl s_client -connect server.domain.tld:443 2> /dev/null | openssl x509 -noout -modulus

You could then pipe that through ‘openssl md5’ to create a hash for the sake of brevity.

The point here is: we shouldn’t be checking if the issue date on a certificate changes. We should check if the modulus has changed. Besides, when certs get rekeyed, most CAs don’t change the certificate body at all, including the issue date, which is what caused the false alarms on LastPass’s checker. Since few people (read: nobody) are storing RSA moduli values over time on every SSL/TLS site they visit, they aren’t going to know when a site’s key has changed. Maybe in the future we should as part of normal functionality in our browsers.

Anyway, if you’re a sysadmin or Ops person, you can use the above to show to your customers that you performed your due diligence. Lucky for us, we stored the modulus values of all of the cert/key pairs before we changed them, so we could verify our work and show those who inquired later.