One Month Later: 300,000 Servers Remain Vulnerable To Heartbleed 60
DavidGilbert99 writes: "The Heartbleed Bug cause widespread panic from internet users around the world worried their sensitive information was being targeted. While system administrators were warned to patch their systems, a security researcher notes that 300,000 servers remain vulnerable to the heartbleed flaw a full month later. He said, 'Last month, I found 1-million systems supporting the "heartbeat" feature (with one third patched). This time, I found 1.5-million systems supporting the "heartbeat" feature, with all but the 300k patched. This implies to me that the first response to the bug was to disable heartbeats, then later when people correctly patched the software, heartbeats were re-enabled. Note that only OpenSSL supports heartbeats, meaning that the vast majority of SSL-supporting servers are based on software other than OpenSSL.' A developer at Vivaldi Technologies AS also pointed out that a significant number of server administrators botched their response, going from safe to vulnerable."
Certificate extortion (Score:5, Interesting)
What would help is if there were some certificate system that didn't rely on extortion or exorbitant prices. I know several admins that mitigated the hole but couldn't replace their certificates either because the signer charges a ridiculous revocation fee (I'm looking at you, StartSSL), or because the cost of cutting and signing new certificates was too high. We need a better trust system.
12 of those are mine. (Score:4, Interesting)
We have are 12 dev/test servers that I didn't bother to patch because they'll be decommissioned in a month or two along with the rest of the datacenter they are in, and even though they support SSL connections (with a disposable cert from our private CA), they are generally only used with HTTP and have no private data to protect, and are almost completely unused now.
If someone wants to spend time trying to steal the server's private key or steal user data from the server, that's fine with me, I'd rather have them spend time on my disposable server than someone's real server.
Safe to vulnerable (Score:4, Interesting)
I'm guessing a lot of these are going to be people running older stable distributions that were running versions of OpenSSL from before the bug was introduced. On hearing the news, they may have quickly looked to see if there was an upgrade, seen that there was not, and either installed a newer rpm/deb they found somewhere, or downloaded the latest source they could find (in a source repository for their distro perhaps) and built from source. Meanwhile the patch for the bug had only just been checked into git.
Re:Let me expose my ignorance... (Score:4, Interesting)
As I understand this, a vulnerable server can expose its private SSL key to an attacker. With this private key, I can decrypt all of its encrypted SSL traffic.
As already mentioned, it's anything in the server's memory. Or the client's, since Heartbleed affects clients too.
Now, as I understand this so far, having the private key is great, but I need to be able to MITM the connection to decrypt anything.
It depends whether the connection is using perfect forward secrecy or not. If it's using PFS, then you need an active MITM to grab the session keys, so you can't decrypt old captured traffic and you need to keep your MITM up for new traffic. If there's no PFS, then all traffic ever sent with a given SSL cert can be decrypted with access to that cert's private key. All you need is to passively sniff it, then store it for later on the off-chance you ever get (or crack) the key.
(I'm going to write a small essay on this, because it's important but very poorly documented on the web.)
Given that, you'd think PFS would be common, but according to this study [linshunghuang.com] it's only available on 60-70% of web servers (they don't give a precise number, just 60% that support DHE and 18% that support ECDHE, but those two sets overlap), of which 80% prefer to use cipher suites without PFS, so about half of webservers either don't support PFS or typically won't use it. Slashdot [slashdot.org] doesn't, for example. Neither does microsoft.com [microsoft.com]. I guess that's just the homepage, but then windowsupdate.microsoft.com [microsoft.com] doesn't use it either. It's not supported on outlook.com's web, IMAP, POP3, or SMTP servers. addons.mozilla.org [mozilla.org] and marketplace.firefox.com [firefox.com] also join the club, but their main website and the Firefox update sites do PFS at least. I couldn't find a Google property that didn't do PFS.
And on top of that, of those sites that do use it, 99.3% use 1024-bit DH parameters, which essentially lowers the length of their RSA keys to 1024 bits (which affects the 80% of sites with 2048-bit or longer RSA keys).
If you want to make sure you're actually using PFS, and with decent DH parameters, you generally need to make sure to configure it. Apache does this for you automatically from 2.4.7 onwards (before that, it'll use PFS but only with 1024-bit DH parameters). A lot of other software requires being fed DH parameters manually -- for instance, Courier's IMAP/SMTP servers, ZNC, ircd-hybrid etc. (And when was the last time you configured DH parameters for a server?)
You can check if any given connection supports PFS by looking at the cipher suite in use. If it starts with DHE or ECDHE, it has PFS. (The "E" at the end stands for ephemeral; if it says DH, ECDH, or doesn't mention either of those, then there's no PFS). You can check with e.g. CipherFox [mozilla.org] in Firefox, or using the openssl command-line tools:
$ openssl s_client -connect www.debian.org:443 | grep Cipher
Cipher : DHE-RSA-AES256-GCM-SHA384
If you point it at servers you use regularly, you'll probably be pretty depressed at the results. I know I was when I was making that list above...