Heartsick about Heartbleed

Ed Felten provides good advice on this blog about what to do in the wake of Heartbleed, and I’ve read some good technical discussions of the technical problem (see this for a particularly understandable explanation).

In this brief posting, I want to look at a different angle – what’s the scope of the vulnerability? I’m going to be (moderately) optimistic and suggest that within a week, major sites of all shapes and sizes (banks, e-shopping, government) will have installed the patches to their web servers and generated new keys/certificates, so it’s safe to visit them to change your password (if it’s an important account), and move on with your life. [That's being optimistic - the realist in me says that there will be some sites that will take months to get patched, because the approval process for big corporations and government agencies is some cumbersome that they can't say "emergency override", and fix the problem quickly.]

But there’s three other classes of sites we should also be concerned about.

1. First, there’s the medium sized companies – too big to use an outsourced hosting provider that will automatically do the patching for them, but not big enough that they have a well-defined process for rolling out an emergency patch to production web servers.  A lot of e-commerce sites fit into this category – and these may well be the riskiest sites.  Those using hosting providers – like the mom & pop pizza shop – may get upgraded by the provider, but probably won’t know that they need to replace their certificates.  Certificate Authorities should reach out to their customers to encourage them to get a replacement – but unless they offer significant discounts, that offer may fall on deaf ears.
2. Second, the products out there that aren’t web servers, but still use OpenSSL.  There’s lots of these sorts of products, and in many cases the organizations that use them have no idea that OpenSSL is buried deep inside – and the vendor itself may not be aware, since OpenSSL may be embedded in a library that gets embedded, or it may have been inserted by a programmer who left the company years ago.  (We saw a scenario similar to this a few years ago when there was a serious vulnerability in a low-end Microsoft database product – and many products had it embedded but no one knew about it.)
3. Third, and scariest, are the embedded devices.  How many ATMs, manufacturing devices, monitoring cameras, etc use OpenSSL because vendors got burned when it came out that their communications were unencrypted?  So they did the “right” thing, embedded OpenSSL – and now perhaps made things even worse.  True, these devices aren’t likely to have a lot of passwords to be stolen from memory via the Heartbleed vulnerability, but there may be other sensitive information that can be retrieved.

Obviously there’s some overlap between the second and third of these, but I separate them out because 2 is fundamentally about “computers” in the traditional sense that are not running web servers, and 3 is about embedded devices that happen to be running web servers.

The threat that every password and every private key have been stolen are almost certainly overblown.  But at the same time, we shouldn’t draw the line too narrowly – there are a lot of things beyond just “Apache running OpenSSL” that need to be examined.