Heartbleed: Why SSL Certs Have To Be Reissued…and Salts
11 April 2014
A friend of mine who’s a geek and I were talking about Heartbleed a couple of days ago. Said friend has never been a coder, and thus never really spent a significant time looking at memory dumps, unlike us old school programmers who have (especially back when we were, um, trying to argue with copy protection on games we owned back in the 80s when apps were traditionally copy protected).
So my friend said, “I don’t get why SSL certs have to be reissued.”
This friend doesn’t run SSL (nor do I). But I see exactly the gap that some technical people have.
Also, I haven’t heard a lot of people talking about the problem of non-obviously SSL security complications of the heartbleed attack, like password and cookie salts.
The short version of SSL is that there’s a public key, handed out to anyone who wants it, and a private key. This private key is not a file that the web server is supposed to be able to read. I’m not saying that this is never misconfigured, just standard practice is to only permit web servers to read files that web servers should send to other people.
The private key part of SSL is not one of those.
So, my friend was thinking, if it’s not something the web server can serve, how can that happen?
Because the private part of the SSL key needs to be in memory, at least temporarily, in order to decrypt an SSL request.
The heartbleed bug does spew random memory, which could include the server’s private key. Given that SSL servers decrypt often, it’s arguable that it’s more likely to be served than other contents of memory. Request frequently enough, and you’ll have the private key at some point. Piecing it together is another matter.
]
So here are a few other things you may not have thought of that you’ll need to change if you run a server that may have been compromised. By “may have been compromised,” I mean if it ran an affected version of SSL and served any SSL content, even if that content was just spacer.gif.
- Change salts for password hashes. This will force password changes (even for people who haven’t logged in recently). Yes, I’d hope that in this day and age, each user has a unique, contemporaneous to their account creation, password salt. However, I know this isn’t reality.
- If you run WordPress, you’ve got cookie salts in ~/wp-config.php Generate new ones. You can go here to get new random salts. If you don’t have random salts there, you should fix that.
- If you have cookie salts in other apps, change those. Yes, existing cookies will be invalidated….
For those who don’t know what salts are here’s the wikipedia page. Short version: they make cookies and password storage one-way encryptable. What this really means, though, is that if cookie/password salts are compromised, it’s far easier for them to pretend to be you.
Edited to add the following:
Researcher proves Heartbleed leaks SSL keys.
Cloudflare’s Heartbleed challenge—and winners.