The Heartbleed vulnerability is one of the worst Internet security problems we have seen. I’ll be writing more about what we can learn from Heartbleed and the response to it.
For now, here is a quick checklist of what you can do to protect yourself.
If you are a regular user:
Most of the sites you use were probably vulnerable. Your password might have been leaked from any one of them. Unless you’re sure that a site was never vulnerable, you should change your password on that site. (It’s not enough that a site is invulnerable now, because your password could have leaked before the site was fixed.)
Yes, it’s a pain to change your passwords, but you were really meaning to change them at some point anyway, weren’t you? Now is a good time. (It’s also a good time to turn on two-factor authentication, on sites that offer it.)
But, before you change your password on a site, you need to make sure that that site has closed any remaining vulnerability. Look for an unequivocal statement from the site that (1) they are no longer vulnerable and (2) they have changed the private encryption key they use to protect HTTPS traffic. Once you’re sure that they have done those two things, then you should go ahead and change your password on the site. If they haven’t done those two things, then it’s best to wait until they do. Make yourself a note to come back and check in a few days.
The bad news is that some of your private information might have leaked from a vulnerable site. It will be very difficult to tell whether this happened, even for the site itself, and nearly impossible to undo a leak if it did happen.
If you run a website that supports HTTPS, and you run your own server:
- Go to http://filippo.io/Heartbleed/ and enter the name of your site, to test whether your site is vulnerable. If you’re not vulnerable, you’re done. If you are vulnerable, carry out the following steps.
- Upgrade your server software to a non-vulnerable version. I can’t give you general advice on how to do this because it depends on which software you are running. Once you have done the upgrade, go back to http://filippo.io/Heartbleed/ and verify that you are no longer vulnerable.
- After upgrading your software, generate a new SSL/TLS key and get a certificate for the new key. Start using the new key and certificate. (This is necessary because an attacker could have gotten your old key.)
- Revoke the certificate you were previously using. (This is necessary because an attacker who got your old key could be using your old key and certificate to impersonate your site.)
- Have your users change the passwords that they use to log in to your site. (This is necessary because users’ existing passwords could have been leaked. You need to get your house in order by carrying out the previous steps, before users can safely change passwords.)
If you run a website that supports HTTPS, and you use a web hosting service:
In this case, the hosting service runs the web server that powers your site.
- Find out from the hosting service whether its server was ever vulnerable to Heartbleed attacks. If you’re confident that it was never vulnerable, then you’re good. Otherwise, carry out the following steps.
- Wait until the hosting service has upgraded its software to a non-vulnerable version. Once they have done the upgrade, you should be able to go to http://filippo.io/Heartbleed/ and enter the address of your site, and be told that it is not vulnerable. If this isn’t true yet, ask the hosting service to fix the problem, then wait a while and repeat.
- Once the hosting service has upgraded its software and the test site shows you as not vulnerable, generate a new SSL/TLS key and get a certificate for the new key. Start using the new key and certificate. (This is necessary because an attacker could have gotten your old key.)
- Revoke the certificate you were previously using. (This is necessary because an attacker who got your old key could be using your old key and certificate to impersonate your site.)
- If your site assigns passwords to users, have your users change the passwords that they use to log in to your site. (This is necessary because users’ existing passwords could have been leaked. You need to get your house in order by carrying out the previous steps, before users can safely change passwords.)
I am really happy to read this blog posts which contains lots of helpful data, thanks for providing
these kinds of data.
Everything is very open with a really clear explanation
of the issues. It was really informative. Your site is very useful.
Thank you for sharing!
I would be interested in seeing a follow up post about how existing certification standards like FIPS are succeding or failing to raise the quality bar for security protocols in general. I think this is the 3rd ssl/TLS related defect publicly disclosed within the last few months. It is definitely the case that the existing market forces are not doing a good job in providing robust security for the consumer space. Can we nudge the market to do better, by providing what amounts to a UL seal of approval for security critcal infrastructure? Should that cerification be an extension of things like FIPS or a new industry lead effort?
Basically these bugs in the code are cause by a failure of the actors to be responsible. How do we fix this?
As an ordinary user (with an interest in security), I think Jon Bauman’s comments apply to my situation more than anything else said. This bug has been around for 2 years. I have not had my identity/passwords stolen during that time (to my knowledge–but such theft should probably have manifested by now). Reputable sites have probably acted to protect themselves by now. So I am potentially at risk from the time the bug was announced (Monday, April 7??) until sites I deal with activated protection to correct Heartbleed. In order for someone to steal information via Heartbleed, things have to go just right for the thief, so my window of damage is only a few days. Any damage done to me has already been done. So I think my best course of action is to sit tight and monitor my email and finances for a reasonable period of time (4 weeks??) and not change all of my passwords.
Regards,
Hi Ed, question: Easy enough to check if a site has patched their ssl, but is there an easy way in the browser or with the CA, to see if they’ve revoked/reissued their pk & crt?
I reissued mine and it now shows “Valid from 4/8/2014″…shouldn’t reissued certs show a >= 4/7/2014 start date?
I don’t know of a currently available way to check whether a site has changed keys. To tell for sure, you would have to know what key they were using before. There are some services that have information about past key usage, so one of them could in principle provide a service that checks for key changes. But that hasn’t happened yet.
But, wouldn’t it make sense to set the start date on the re-signed key “today”, to communicate that the keys were not used before that date? I wonder why that’s not the practice, can’t think of a possible security implication.
Anyway, that’s what I did when I re-signed.
It seems to me that the only very likely class of attack that changing my password protects me against is one wherein the adversary previously exploited the vulnerability to gain my password (or information that would allow them to reset my password) and will go back later to do bad things possible with access to my account. Any site worth a damn doesn’t actually store passwords anywhere (only hashes). So really, how does going and changing my password improve my security on any site who’s security isn’t already abysmal?
If the attacker extracted personal info (DOB, SSN, etc.) through the vulnerability, that is already gone and changing my password does nothing.
Thinking about it more, I guess if a server’s encryption keys were compromised an adversary could’ve used that to mount a MITM attack and get my password that way. Still, MITM is not easy to pull off. Are there other scenarios where a password reset helps me I’m not seeing?
Password hashing has no effect on this. The problem was that vulnerable servers were leaking memory contents. If you type a password into a login form it has to be in memory in plain text at some point before being hashed and compared.
We have nothing to hide from heartbleed as our heart already bleeding.
Asking everyone on the Internet to change every password is totally crazy. It may be necessary in theory, but we as security practitioners must realize that there’s no way that that’s ever going to happen. We don’t get to say to the rest of the non-technical world: “Our bad. Now would you kindly start over because we messed up in a way that you don’t understand.”
What would you recommend that users do?
Yeah sure, an Internet-wide password reset is the only thing we can recommend conservatively. But we have to recognize the absurdity of our predicament: we’re forced to advocate something completely unrealistic that we know users won’t do, and that users can’t be blamed for not doing. And what happens when next month’s catastrophic bug is revealed? Are we going to call for another Internet-wide password reset? I think an under-appreciated aspect of heartbleed and the other recent TLS is bugs is that they’ve created a major credibility problem for us as security practitioners. If you think people didn’t listen to us in the past…
> I think an under-appreciated aspect of heartbleed and the other recent TLS is bugs is that they’ve created a major credibility problem for us as security practitioners. If you think people didn’t listen to us in the past…
That’s true. But it’s also true that user passwords are potentially compromised. The choice is only between
“Our bad. Now would you kindly start over because we messed up in a way that you don’t understand.”
and
“Our bad. Your passwords have been compromised because we messed up in a way that you don’t understand.”
If you worry about the credibility of security practitioners, it looks like you’ve already lost the battle.
@ariel Ed asked what you would recommend and you side-stepped answering that question. Instead you just ranted the same dull line again. That’s quite typical of the so-called “security practitioners”.
And why not pass the burden to the end-user for things like personal security, responsibility of compliance, and everything else that stands in the way of getting a half-functioning product to market cheap and fast, That has been the corporate business model for decades, why pretend to change it now.
Here’s a thought. Stop trying to be an isolated island. Don’t do online banking go speak with the tellers, make some friends. Call the merchant instead of putting credit card numbers and private data on the web.
OpenSSL, FSSL, Linux, Apache, and thousands of other products were written by people who had no intent or desire to profit off of it. Some even come from foreign nations that have completely different standards and ethics. Freeware, shareware, and the like. In other words; it really doesn’t matter if it works properly and met the specs.
Corporations use these products because they are cheap to acquire. Then if something does go wrong then they can always point-the-finger at someone else. They’ll pretend to say or do anything to keep that stupid money giving end-user from leaving.
I recommend that individuals change passwords according to their own individual risks. Change retirement account passwords first, banking & credit passwords second, social network & email passwords third, work passwords fourth, then passwords with stored credit cards or the ability to charge (e.g., Amazon) and finally any kind of commenting or other password. Invest in creating the password in terms of how much it would cost or concern you if it were lost. If your Magic The Gathering or OKCupid accounts are what really matters to you, spend some time thinking about a good but memorable password.
We should all eat healthy every day and exercise regardless of our schedules. Our posture should be perfect. But such health advice is not actionable. So try to offer more nuanced actionable advice that respects ordinary human priorities and time constraints.
Of course, you knew I would say this.
-Jean
http://www.ljean.com
Just change the passwords for really important stuff.
You decide how important it is.
If you live and die by Facebook, it’s important.
If you hate Facebook and log in once a year, probably unimportant.
Maybe your bank/CC site is important enough to change your password??
HTH 🙂 🙂 Tom
Tom, I’m just trying to understand what would be compromised in facebook. If a person’s info is all public on facebook anyway, what would having their password do? Thanks.
If you even have a facebook account then re-evaluate your life; because something has gone horribly wrong.
One note on risk factors. Some people who are testing servers say they have not seen servers’ private keys being leaked via Heartbleed attacks. These results should be given some weight. However, there is still a lot we don’t understand — some of which might never be well understood — about the factors that cause one chunk of memory rather than another to be leaked. [Geeky details: It has to do with the layout of dynamically allocated memory blocks in a complex multithreaded program.]
My current view is that the risk that a server’s private key could have been leaked is still too high to ignore, given the consequences that would follow from such a leak. So the prudent course of action is for sites to switch keys and revoke their old certificates.
I would change this advice if I saw stronger evidence that Heartbleed is definitely incapable of leaking private keys.
Ed, of all people I know that understand computer security, I trust your advice more than anyone else’s so I am asking for it specifically, hoping that you may respond.
First, I totally agree with your advice to all users to change passwords, and I yet I also agree with Tom below that priorities based on importance should be held. As a clinically paranoid security minded yet empathic person; that would be my advice to users to change all passwords to anything they find important.
But, as a computer specialist whose job includes so many functions that system administration/security becomes the lowest priority (yet still expected for me to perform); I run into the need for advice. Am I vulnerable, or not, and how to fix it if so?
The links I have found across the web to test for vulnerabilities sometimes say I am “all good” (either fixed or not vulnerable) or say “probably vulnerable.” Who do I trust?
The tech in me questions exactly what is the vulnerability and when was the vulnerability introduced, and the best answer I found was on OpenSSL’s website “Only 1.0.1 and 1.0.2-beta releases of OpenSSL are affected including 1.0.1f and 1.0.2-beta1.”
In keeping with the lower priorities of server management I find I am running OpenSSL 1.0.0 and updating today to OpenSSL 1.0.0d. I take it that means I really am not vulnerable. But again which testing site do I trust?
And, further, I ask your advice, should I try to update to 1.0.1g manually (the older OS [2011] did not give me the option to update to 1.0.1 at all; using the update packages feature)? Or, should I rather look to upgrading to a newer Linux? Is 1.0.0d vulnerable to other attacks I have never heard about, or should I call it good with the older version that is non-vulnerable to this attack?
Here’s what the OpenSSL people say:
“Affected users should upgrade to OpenSSL 1.0.1g. Users unable to immediately upgrade can alternatively recompile OpenSSL with -DOPENSSL_NO_HEARTBEATS.”
So if you’re not able to upgrade to version 1.0.1g, you can still protect yourself by recompiling with
-DOPEENSSL_NO_HEARTBEATS, which turns off the vulnerable feature.
Well that was a response, and I very much appreciate that you did respond to me today. It really didn’t answer my question.
I am using an OpenSSL prior to the heartbeats extension (as far as I understand it), so recompiling would have no effect either way. As I am already protected from “heartbleed,” my question was more along the lines of what else am I not protected from. And you may or may not know an answer to that. Which I would understand.
Sorry, I misunderstood your initial question. Now that I know what you’re asking, I’m afraid I don’t know enough to answer with any confidence.
I believe the relevant portion of his response was “Affected users should upgrade to OpenSSL 1.0.1g.” If you aren’t affected, you don’t HAVE to upgrade. Later versions have newer features (different protocol level support for example) which might be more secure or offer more options than older versions. If you’re running an unsupported version, you should upgrade. If your version is still getting updates, you should be okay for a while.
You could add to this by suggesting whether people with HOSTED websites that use SSL certs should get their SSL certs redone??
For example, if one has a GoDaddy or Verisign SSL certificate because your site offers online shopping or any other kind of servces like email etc., should the SSL cert be regenerated and re-installed??
The question only applies to the certs, the server does not necessarily have OpenSSL on it.
Thank you, Tom
I’ll edit the post to include advice for people who run a site that uses a web hosting service.
Thank you, I had suspected we should before long redo our certificates etc.