Did you change your passwords when you heard about Heartbleed? Does it matter? Maybe.
Heartbleed is an information leak enabled by a widely-used open source SSL package. Some versions of Red Hat were vulnerable. Microsoft IIS obviously does not use OpenSSL. However, some companies which use Micsoft IIS still use load balancers that include OpenSSL. So the impact was felt widely across the Internet.
The immediate responses were to advise people to change all their passwords. Not that anyone actually knows all their passwords, but changing passwords for email, social networking, and banking are all important risk-minimizing choices. Accounts with associated credit cards are less critical as the card providers have complex and effective anti-fraud programs.
But does it matter if you changed your passwords? It is only effective if the site manager has both patched the vulnerability and updated their public key certificate (PKI). Remember that a public key certificate authenticates a link between the domain name and the knowledge of the secret key half of the public key pair. Since Heartbleed enabled repeated, automated peeks at active processing memory and secret keys are used in establishing session keys, secret keys must be loaded into active processing memory. If an attacker obtained the keys before a service was patched, then this repair would not protect a new password. (Unless the encryption enables perfect-forward secrecy. Google does, but most do not.)
Seeing that a server has been patched is straight-forward, determining if a certificate has been re-issued is less so. One way to evaluate the certificate is to simply look at the dates when it is valid. However, the “not-valid-before” date is not a reliable indicator. Certificates are purchased before they are deployed. Certificates may also be purchased to replace other certificates (for example, ones that were possibly subverted during the vulnerable Heartbleed period). In that case, a company may want to request a certificate that covers the period not only after the certificate was issued but also during the time that the previous public key pair was vulnerable.
Knowing that a certificate has changed requires having looked at the certificates before the change. And since Heartbleed is part of the global infrastructure, these changes should be happening across the planet.
Fortuitously, the Indiana University research group has been looking at rates of change in certificates since December 2012. From three countries we have been observing the certificates of the top million websites plus the American banking infrastructure. We expected a massive spike in the rate of change in certificates. Over the past two years we have seen an average daily rate of change of about 17,404 certificates a day. April 8th, this went to over twenty-five thousand, doubling to fifty thousand by April 11th, with new average of thirty-three thousand since April 8. The particularly quick at math will notice that this is about 20% cumulatively of the sites we have examined. In contrast, market share in 2013 for Apache (which is open source and was vulnerable) was 50%, with the unaffected IIS hitting the 20% mark. Recall that even if the server is IIS, balancers could have leaked the key.
The change data for the top sites is available at http://zhdong.net/certs/CertChangeReport.html.
So if you were very responsive and changed your password before the certificate change date on this list, you may want to change it again. And if your service provider is on the vulnerable list (https://github.com/musalbas/heartbleed-masstest) but not on our changed list (http://zhdong.net/certs/CertChangeReport.html) you might want to wait a bit. In my case, I spent a bit of time that would have gone into password regeneration into writing a note to the service provider.