Let's remedy that.
The Heartbleed vulnerability is a bug in the OpenSSL implementation of TLS (Transport Layer Security). It can lead to web servers' private keys being leaked when the TLS connection is being established.
Wait... what?
But, what does that mean?
Say you want to log in to your banking website. It'll ask you for a username and password before giving you access to your bank account. You enter your username and password in the web browser, which then needs to send them to the bank's web server so it can verify their validity.
Of course you wouldn't want to transfer your login information directly as clear text, because that means that anyone who could access that bit of information, would have full access to your bank account. You probably also wouldn't want the pages of your account summary to be transferred in the clear, bare for the world to see.
That's where TLS comes in.
TLS secures communication between your browser and a web server by using two means of encryption. First, it uses asymmetric encryption to set up a connection.
Asymmetric encryption (also known as public key encryption) generates two encryption keys that belong together, known as the public and private keys, forming a key pair. Through some amazing mathematical magic, anything encrypted with the private key can only be decrypted with the corresponding public key, and vice versa.
What this means is that, to securely communicate information from Alice to Bob, Bob has to only share his public key, keeping his private key, well, private. Alice can then encrypt a message using Bob's public key, and only Bob will be able to decrypt it, because only he has the corresponding private key.
In TLS then, your bank's web server is first going to send its public key to your web browser, setting the stage for secure communication.
As the second step, your browser now randomly generates a new symmetric encryption key.
In symmetric encryption, information is encrypted and decrypted using the same key. The disadvantage is that of course, if someone can grab that key, they have full access to all communication encrypted with it. The advantage is that it's usually mathematically simpler, and faster to encrypt data with.
So, your browser creates a symmetric key, that it then encrypts using the bank's public key, and sends to the bank's web server. Assuming the bank's private key has not been compromised, only the bank will be able to decrypt the symmetric key. Consequently, the symmetric key is then used to encrypt all further communication between you and the bank.
The symmetric key is only valid for one session - as soon as you close the browser window or log out of your banking web site, the whole process starts from scratch.
So, here's the process, grossly simplified, step by step:
1. Browser: Hey bank, I want to establish a secure session.
2. Bank: OK, here's my public key.
3. Browser: Cool. Let me generate a symmetric key and encrypt it with your public key. Here you go.
4. Bank: Thanks. I'm going to assume everything from here on out will be encrypted with the symmetric key
...
5. Browser: Hey bank, I'm logging out and forgetting the symmetric key we shared.
6. Bank: Then I'm forgetting about it too. Thanks for stopping by.
Heartbeat
Now, sometimes it takes a while for a user to do something after the initial TLS negotiation. They get distracted, start browsing another web site, need to step away from the computer for a short while, or maybe there's an error in data transfer, since HTTP uses TCP, which is an unreliable protocol (packages are not guaranteed to arrive in order, or at all, at the destination, depending on network congestion and prioritization).If things take too long, or there's an error in transferring data, the connection between browser and server may be lost. In order to remedy having to renegotiate a TLS session in cases like that, the heartbeat extension to TLS was proposed in February 2012. This allows the browser to periodically send 'I'm still here' messages to the server, expecting corresponding replies, essentially separating the TLS negotiation from the other connections to transfer data between client and server.
Sounds pretty safe
All clear so far? Good, 'cause this is where it gets interesting, so keep paying attention if your eyes aren't bleeding yet.
The Heartbleed vulnerability, now, is a bug in the TLS Heartbeat extension implementation of OpenSSL, used many web servers. In order to use its private key to decrypt the browser's message from step 3, the web server will need to have it in memory somewhere. The steps above are very much simplified, as there's a lot of negotiation about TLS versions and encryption algorithms going on.
The bug comes to life when the web server doesn't check how many characters it should send back as a response to one of the messages the web browser might send in the context of the heartbeat extension.
The server will use a block of memory for the response and write the response to that memory - but the memory it reserved for that purpose may be right next to a block of memory that still contains the private key from a TLS crypto negotiation - and the entire requested amount of memory is sent back to the browser, regardless of the length of the response - including possibly the block next to it that holds the private key.
The memory OpenSSL uses isn't cleared (overwritten with zeroes) before using it in a response, so that if that block of memory happened to hold the server's private key, that too is sent back with the response in clear text. A recent xkcd comic explains this better than words can.
So, all a malicious person needs to do is elicit that too-long response from the server many times (in a challenge set up by CloudFlare, it's been between 100,000 and 2,500,000 times), and chances are they'll eventually find the server's private key in one of the responses.
Once someone has the private key and can intercept the communication between your browser and the bank (not too difficult for someone who knows what they're doing), they can decrypt the message from step 3 above, get access to the symmetric key your browser has generated, and decrypt all further communication between your browser and the web server - including your login name and password.
That's for compromised usernames and passwords. There's another aspect to the vulnerability when it comes to server certificates.
Server certificates are pieces of information that are supposed to tell your browser that the website you just connected to is really in fact your bank's web site, and not one your evil neighbor has set up in order to trick you into logging into it instead and revealing your username and password.
The way that's done is also through asymmetric encryption. A certificate is a piece of information uniquely generated for a particular web site and electronically signed by a trusted party, usually a CA (certificate authority), by encryption using their private key. I won't go into too deep of a discussion of digital certificates here, but suffice it to say that if private web server keys are leaked, there's a possibility that certificates could be forged, and someone could pretend to be your bank without your browser ever being able to tell that it's been duped.
Everybody panic!
Now, how likely is this to have happened? It's difficult to gauge, for many reasons. If you need to send 100,000 requests to the server to get at the key, it's quite likely that a properly configured server wouldn't easily let this happen. Any site admin worth their (non-cryptographic) salt would likely configure the server to block any IP that tries to make such a large amount of requests in a short amount of time. Additionally, the more requests are received and serviced by the server, the more likely it may be for the memory pages that contain this sensitive data to have been overwritten with something else when the next malicious request comes in.
Then again, the bug has been in the wild for a long time. If someone sends fifty such malicious requests a day, it's possible that they'd eventually received a block of memory with a key in it.
So, yes, this vulnerability is a big deal, especially because it's been around for such a long time, and has such potential for wide spread impact.
Should we panic? I don't think so (I think panic is rarely useful in any situation at all), but safe is better than sorry, so changing website passwords is probably in order.
Most importantly, inform yourself. I do believe everyone who uses web sites, e-mail or any other form of electronic communication should know how these things work. No hardware, no software, is foolproof, and as we rely on it, we have to educate ourselves in order to be able to tell if and when something is amiss. Whether it's hackers or the Government, you shouldn't give anyone free run with your data, just as you wouldn't with your house, your car, or any other personal property you have. It's your data. It's your responsiblity to protect it and make sure the front door isn't standing wide open.
Read the Wikipedia articles on encryption. Talk to someone who knows more and ask them questions. Learn, then make informed decisions based on what you know.
No comments:
Post a Comment