The fallout from heartbleed seems to be manifesting itself in a range of ways. I’ve been required to set new passwords for a small number of online services, and expect I may encounter others as and when I next access them.
The main contrast seems to be between admins who tell you what’s happening, vs services that just stop working. Contrast Apache and Google:
Apache: email arrives from the infrastructure folks: all system passwords will have to be reset. Then a second email: if you haven’t already, you’ll have to set a new password via the “forgot my password” mechanism (which sends you PGP-encrypted email instructions). All very smooth and maximally secure – unless some glitch has yet to manifest itself.
Google: @employer email address, which is hosted on gmail, just stopped working without explanation. But this is the weekend, and similar things have happened before at weekends, so I ignore it. But when it’s still not back on Monday, I try logging in with my web browser. It allows me that, and insists I set a new password, whereupon normal imap access is also restored. Hmmm … In the first place, no explanation or warning. In the second place, if the password had been compromised then anyone who had it could trivially have reset it. Bottom of the class both for insecurity and for the user experience.
There is also secondary fallout: worried users of products that link OpenSSL asking or wondering what they have to upgrade: for example, here. For most, the answer is that you just upgrade your OpenSSL installation and then restart any services that link it (or reboot the whole system if you favour the sledgehammer approach). Exceptions to that will be cases where you have custom builds with statically linked OpenSSL, or multiple OpenSSL installations (as might reasonably be the case on a developer’s machine). If in doubt, restart your services and check for the OpenSSL version appearing in its startup messages: for example, with Apache HTTPD you’ll see it in the error log at startup.