Welcome to the world after heartbleed. We've patched our servers and are replacing our SSL certificates. But just because our servers are fixed, that doesn't mean that the rest of the internet is fixed. We have employees, and they use the internet to exchange secrets such as credit card numbers and logon credentials. They are looking to us for advice.

We can advise our clients to use a Heartbleed test page to see if the site they want to go to has the vulnerability. If a site returns positive, then don't exchange secrets with it. But if a site does not return positive for Heartnet, then the situation may be any of:

  • The site never had the vulnerability (good)
  • The site had the vulnerability and has fixed it, but is still using the possibly compromised SSL certificate (bad)
  • The site had the vulnerability and has fixed it, and regenerated the SSL certificate but without regenerating keys (bad)
  • The site had the vulnerability, fixed it, regenerated keys, and replaced the SSL certificate. (good)

Is there any means we can give our employees, before they type their credit card number into the form, to tell the good scenarios from the bad ones?

How do we instruct our employees to minimize their exposure to servers which are compromised by Heartbleed?

  • 2
    Don't trust any certificate issued before today...
    – MichelZ
    Apr 8, 2014 at 20:39
  • 1
    @MichelZ That is incomplete advice. You really can't trust any certificate unless you can verify that it was reissued with a freshly-generated key (i.e. "There is no way you can know if any given certificate is compromised" - You can HOPE a new key was used when the new certificate was issued, but you can't know for sure). You also need to be worried about whether the OLD certificate was properly revoked (if it wasn't browsers will treat it as valid, and it can be used for MITM attacks). It's not simple, thats why this bug is so terribad.
    – voretaq7
    Apr 9, 2014 at 5:31
  • @voretaq7 Yes, this is true. I did not mean "trust any certificate issued after today", I meant "don't trust certificates issued BEFORE today". So I do "blacklisting" not "whitelisting" :)
    – MichelZ
    Apr 9, 2014 at 5:40
  • @MichelZ blacklisting based on cert dates has the problem of false-flagging a bunch of sites (e.g. all of my environments which have been running OpenSSL 0.9.8 - No heartbeat, so no vulnerability, so I'm not reissuing certs). The false positives are better than false negatives certainly, but you really need a statement from each company you're dealing with to know the state of the universe at this point (hugely impractical, but really The Only Way :-/)
    – voretaq7
    Apr 9, 2014 at 5:44
  • 1
    @MadHatter That question appears to have been understood as being from the admin's point of view: its answers are all about how to fix your server, not about what to tell your users. Apr 15, 2014 at 13:31

1 Answer 1


Essentially, no, there is no one way to tell the good scenarios from the bad, because your users don't have full visibility of the systems they're using.

The extent of the damage caused by the bug is still largely unknown, most of the damage was potentially done in the past and will continue to impact the internet for a long time. We just don't know what secrets were stolen, when, or by whom.

For example: Google's OpenSSL heart bleeds for about a year. Unknown adversaries harvest the servers and look for interesting secrets - again, there is no way for us to know whether they did this or not - until they find an account belonging to someone with authorized access to another system, say Twitter.com or AnyBank.co.uk or dev.redhat.com. With access to such accounts, they could potentially keep digging, gaining access to other systems, doing other damage (visible or not), further compromising other accounts - without anyone suspecting the origin of the breach. At this stage you're already far away from the bleeding OpenSSL servers, and this is one of the nastier consequences of Heartbleed. Added to that is the risk of servers' private keys being compromised.

Trust takes a long time to build up, and can quickly be lost. I'm not saying that we didn't have trust issues on the internet before, but Heartbleed definitely didn't help. Repairing the damage will take a long time, and understanding this is part of understanding how you can protect yourself and your employees/clients/bosses etc - and how you cannot. There are some things you can control, to limit your exposure to the vulnerability, and there are things you cannot control - but they will still affect you. For example, you cannot control how everyone else decides to respond to this vulnerability - the NSA reportedly discovered the bug but kept quiet. That was pretty bad for the rest of us, but we had no way of protecting us against it.

As an internet user you can and should:

  • Understand just how bad the bug is
  • NOT reply to/follow links in e-mails telling you to reset your password - instead go to the website of the company/organization directly and actively reset your password. Times like these scammers like to go phishing
  • Check your Android phone for Heartbleed. There's an app from Lookout Mobile Security that checks your version of OpenSSL.
  • Check websites you visit for Heartbleed (incomplete checklist):

    1. Is the server using OpenSSL?

      • No: You're not directly impacted (by this bug). Keep using the site, but change your password in case another server directly or indirectly affected by the bug had access to your password. This assumes, of course, that all such servers on that network have been patched, issued new certs... etc.
      • Yes: Go to 2.
    2. Is the server on a Heartbleed-free version of OpenSSL? Make sure that your check-for-heartbleed-tool actually checks for the vulnerability and not the HTTP header or some other "indicator".

      • No: Don't submit any secrets to the site, but if possible submit a note to the webmaster.
      • Yes: Go to 3.
    3. Did any previous version of OpenSSL have Heartbleed?

      • No: Some admins didn't upgrade to the latest OpenSSL version, because it hadn't been field tested long enough. Their servers were never vulnerable to this bug, but for reasons presented above, you may still be better off changing your password.
      • Yes: The server was vulnerable, and it is possible that any in-memory data was compromised between the time of upgrade to the vulnerable version and the time of disclosure (up to two, or even three years).

Here we come back to trust: When you lose someone's trust, that's a bad thing. Especially if that someone is your user/customer/boss. To regain their trust, you have to start building again, and open up for a dialog.

Here's what a web admin can publish to get that started:

  • Previous OpenSSL version(s) (vulnerable/not vulnerable)
  • Current version and when it was updated

And if the previous version of OpenSSL was vulnerable:

  • When the current SSL certificate was generated
  • Detailed description of how the old certificate has been revoked
  • Assurance that a new secret was used for the new certificate
  • Suggestions for users based on the above information

If you're a user, you have every right to ask for this kind of information, and you should, for the sake of all users of the service. This would increase the visibility for the security community, and make it easier for users to minimize their exposure to compromised servers.

Not the answer you're looking for? Browse other questions tagged or ask your own question.