HeartBleed: Inside the heart, what happens to a normal WEB user?
To be brief, our email, IM, facebook etc. are at the risk, so try to minimize the access in these few days. Especially we should try to avoid log into our internet-banking, because we may expose our user id and password. Also later when the service providers fix the bug, we would better to change a new password for all the web accounts that are important to us.
Here comes the technical explanation.
You might notice before that a lot of websites use URL starting with "https". For example, https://www.google.com.sg. HTTPS literally means secure HTTP, as the "s" stands for secure. Both HTTP and HTTPS are the protocols to standardize a way for data to be communicated in the network. Just HTTPS signals our browser to have an extra encryption process running behind the screen, so that our data is better protected. Now I am going to show you how the encryption process works and how we are hurt by the bug.
The Heartbleed Bug is regarded as a nuclear bomb in the Internet world, because it may affect a lot of giants we know, i.e. Yahoo, Google, Amazon, and it may expose the most critical piece of information--the private key.
Let's illustrate the idea using a made-up story.
A company called "*bay" firstly generates a pair of two different keys, namely the Private Key and the Public Key. The private key should be kept as a secret and only *bay knows it. The public key is to be distributed to the people, whoever might need to communicate with *bay. Then *bay register with a third party called Certificate Authority, who can verify that *bay is a well-established company and its public key can be trusted. (Usually our computer system already knows some CA and sometimes we can manually add a CA to the list ourselves.) After verification, CA issue a certificate which includes some info about *bay and ebay's public key.
When *bay sends us this certificate, we can know that the public key is actually from *bay, based on the assurance from the CA who we already know. Then we use this public key to encrypt our data submitted to *bay, and *bay can use its private key to decrypt. (In reality, the public/private key pair consumes too much bandwidth and computational power. One shorter length key called session key is shared between *bay and us, and the session key is used to encrypt/decrypt our data, and the public/private key encrypts/decrypts the session key.) In addition, when *bay talks to us, a digital signature is generated by *bay's private key. Just like a physical signature, it verifies the identity of *bay and make the data from *bay non-repudiation(meaning *bay cannot deny what it says).
The BUG allows an attacker to unlawfully retrieve some random parts of server's memory, and they could be able to see *bay's private key and user information (or just garbage, if bad luck). As long as the private key is compromised, the attacker will not only see the current exposed data, he or she can also decrypt any data that is captured in the past.
Most popular Linux enterprise versions come with the OpenSSL library, and Linux is widely used in the Internet companies and even some high end places (banks, financial institutes and high-performance computer centers). So it is safe to say the potential risk due to this bug is pretty high.
For now, we can only quietly wait for the service providers to fix this bug. After they redistribute the new certificates and session keys, we probably want to update our accounts' passwords too.
You may also be interested in our code analysis about the HeartBleed bug.
After changing one line of code, everything doesn't feel good.