It's easy to want to think the reaction to the Heartbleed OpenSSL vulnerability is overblown; Sadly, it's not. Heartbleed is bad. It's not hyperbole; it's a major problem.

In fact, Heartbleed has the potential to be one of the biggest, most widespread vulnerabilities in the history of the modern web. Frustratingly, however, because the problem is technical — very technical — it's difficult for regular users to understand why this vulnerability is a big deal, what services have been vulnerable in the past and what services remain vulnerable now.

Even worse, the technical nature of Heartbleed means that as an end user, you are limited in how to protect yourself. The onus is on the person who manages the web service — or who manages the back-end service the web service uses — not the end user.

Writing about Heartbleed, security expert Bruce Schneier says "'catastrophic' is the right word. On the scale of 1 to 10, this is an 11." That's about right.

So why is Heartbleed so bad? Why is this such a big deal?

Geeksplaining OpenSSL

At the root of Heartbleed is encryption. The idea of encryption to make sure the information you send from your computer to someone else (or to another web server) is protected and secure. The larger conversation surrounding the need for encryption has increased since last summer's NSA revelations.

As an Internet-using populous, we're more aware than ever of the importance of keeping private and confidential information "secure."

Think of encryption like a secret language between two people. The two of us are the only people that know the language; to everyone else, what we're saying sounds like gibberish. In encryption terms, this language works as a set of encryption keys.

The user (that's you) has a copy of the encryption keys on their computer and the client (that's the web app or server) has a set. Obviously, it's super-important to keep those keys secure.

The Internet has a set of protocols for handling security, commonly referred to as Secure Sockets Layer (SSL) and its successor Transport Layer Security (TLS). SSL/TLS is a major part of how the modern web works.

And like a lot of other web protocols, there are various out-of-the-box solutions for providing SSL/TLS functionality to a website or app. The most common implementation is set of open-source tools known as OpenSSL. OpenSSL is free — which is always good — and it was designed in such a way that can be used in lots of different types of projects.

Tons of major web services and web apps OpenSSL as a way to provide SSL/TLS functionality. Out of the box, OpenSSL is included with lots of versions of Linux, including Debian, Suse, Red Hat and Ubuntu. Two of the most popular projects for acting as web servers, Apache and Nginx, use OpenSSL.

It's not just apps and services that control web pages. Lots of email services, instant messaging clients, network routers and even printers can use OpenSSL.

OpenSSL runs on 66% of the web. Even if you don't ever see OpenSSL or know what it stands for, chances are, you interact with it several times a day. That interaction can be as simple as entering in a password for an email account or as complex as sending a private message or photo or even filing your taxes.

Why Heartbleed is so scary

Okay, so OpenSSL is a major part of the modern Internet. What would happen if OpenSSL had a flaw? What if that flaw meant those secret keys between you and the server were suddenly accessible by someone else?

What if the flaw meant that someone could secretly gain access to the keys the server has, make a copy for themselves, and eavesdrop on everything you say to that server? What if that flaw was impossible to detect?

That's Heartbleed. It's a vulnerability that, thus far, has operated without detection. Plus, it's designed in such a way that with enough effort and enough time, lots of information could be accessed by someone else. And you (and the server you talk to) would have no idea.

As bad as that is, the worst part is that this vulnerability has actually been around since December 2011. Lots of software packages started using the vulnerable version of OpenSSL in May 2012. So for two years, any app, website, bank or private messaging app that uses OpenSSL has been vulnerable to this bug.

Now, it's important to note that not every web server or application uses OpenSSL as its SSL/TLS implementation. It's also true that if an app was using something older than OpenSSL circa 2011, this bug won't effect it. As we've seen, however, the vast, vast majority of OpenSSL implementations running on the web before Monday were running a version vulnerable to Heartbleed.

Fixing the Problem is not that simple

A patch that fixes the Heartbleed vulnerability in OpenSSL is already widely available. Every major Linux distribution has issued patches, major web and cloud hosts such as Heroku, Cloudflare, Amazon and others have patched their own servers and fortunately, this is an international story.

The patch itself isn't that difficult to implement, but the problem is that along with patching the software, some applications need to look at whether or not they need to revoke and reissue various digital certificates. A digital certificate is most commonly used by a web browser to validate that a web server is secure. The website applies for a certificate with a certification authority (CA) as away to prove it is who it says it is. This certificate shows that website X is connected with a specific name, email and DNS address, which helps "prove" its identity. Codenomicon, the security firm that along with Google's Neel Mehta discovered Heartbleed, found that it was able to use the vulnerability to steal the secret keys attached to its own X.509 digital certificates. X.509 is an extremely common cryptographic protocol for digital certificates.

Codenomicon's discovery means that It's possible that any certificate issued before the Heartbleed vulnerability was patched could still be compromised. If someone was able to sneak in an grab a site's digital certificate before the site was patched, it could make changes to the certificate or masquerade another site as having a different identity.

Organizations have to make the determination whether to revoke and reissue all certificates via a CA or wait for current certificates to expire. It's not trivial to just revoke and reissue a bunch of SSL certificates, it takes time. With the number of potential certificates that need to be revoked or reissued, it could take days or weeks for every CA to catch-up for every service. If the certificates were issued when the site was still vulnerable

There's nothing you can do about the past

In the wake of the Heartbleed disclosure, system administrators have been scurrying to secure their systems, revoke certificates, check for other patches and change login data.

What these admins cannot do, however, is go back in time and prevent any person (or organization) who may have taken advantage of this vulnerability to access information not intended for them.

Even scarier, it's not even clear that it's possible to tell if anyone bypassed the vulnerability in the past. In other words — patching a system today is great — but that can't prevent any silent destruction that has already happened.

This thing has legs

As Jason Lefkowitz points out, the most jarring aspect of this entire bug is that it has lots and lots of potential vectors.

For instance, we all know that at least for a time, Yahoo! Mail was vulnerable. That means that if you used your Yahoo! Mail password for any other site between Dec. 2011 and now, that password also needs to be changed.

Most of us use the same password, or a set of passwords, rather than using a unique password for every login. I'm a huge proponent of password managers and I still find myself using the same three or four passwords all too often. Most of the time its trivial (I use a unique password for every email, bank and major social media account), but discrepancies do happen.

So not only is every password you've used at a vulnerable site at risk — the bigger problem is that although major vendors and websites are scurrying to fix this problem now, smaller apps and sites might take more time. Or worse, they might ignore the problem altogether.

It's easy to check to see if your email provider or bank has updated its security to protect against Heartbleed, but what about a local restaurant? Your doctor's office? A company you used once to get a ride to the airport? A boutique hotel you booked online directly through their website? You might be surprised (and scared) to realize how many places have your information — and how poor their security practices might be.

What Next?

Before rushing into changing all of your passwords, it's worth waiting to make sure that each service you use has patched its servers. That way, you don't have to change things twice.

Other than that, Heartbleed is just a scary example of what can go wrong when software we all rely on turns out to be unsafe.

The existence of Heartbleed has no big takeaways or "lessons for next time." This is just a bad situation with no winners and millions of losers.

Have something to add to this story? Share it in the comments.