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?
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:
Check websites you visit for Heartbleed (incomplete checklist):
Is the server using OpenSSL?
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".
Did any previous version of OpenSSL have Heartbleed?
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:
And if the previous version of OpenSSL was vulnerable:
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.