Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Trying to understand everything while reading http://heartbleed.com/

This sentence Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will this sounds pretty serious.

Now there are many private/small company websites that don't necessarily have SSL encryption for their site. Is this kind of malicious behavior also possible without heartbleed and SSL? If so does that mean every non SSL site could be an impersonated version? Is the information obtainable with heartbleed the same information hackers can get if a site is non-ssl encrypted or less/more?

share|improve this question

2 Answers 2

In answer to the title question, and as is so often the case with technology, it depends. A single heartbleed attack allows an attacker to return up to 64k of what ought to be the server's private memory, and read whatever's stored there.

What will be stored there? It depends. So far, secret keys, session keys, and HTTPS payload data are amongst the things attackers have found in the returned datastream. It could in theory be anything, but because of the way memory is allocated by computers, it's hugely likely to be something that the attacked service was thinking about at the time: crypto keys for all services, HTTP logins for web servers, mail messages for IMAP servers, and so on. I'm not aware that any attacker has caused a service to return anything other than service-related secrets, and as long as that's true, heartbleed exposes nothing worse than doing everything in plaintext would have done.

One important respect in which heartbleed is worse than plaintext connections is that with crypto, people had the expectation of privacy, so may have behaved in a manner that they wouldn't have done under plaintext, and therefore more might be exposable. But that's a social, not a technical problem.

share|improve this answer
OK, this is quite a good answer, but getting "64k of what ought to be the server's private memory" is not possible on a non SSL connection right? –  Moak Apr 11 '14 at 16:50
That is correct (at least, modulo some other bug we don't yet know about). –  MadHatter Apr 11 '14 at 18:49

yes, a non SSL connection can be viewed by any router/server that the traffic flows through and as the internet is routable in theory this could be any server anywhere(it isn't but could be).

If an attacker has been monitoring capturing all traffic with a malicious router/server but the data has been SSL encrypted then the data is essentially safe as long as the attacked does not have the keys to decrypt the data as the end server will have.

If the attacker uses heartbleed and retrieves the keys from the destination server then any encrypted data can be decrypted. Excluding servers employing PFS that the attacker would not be able to decrypt past SSL sessions from.(thanks @MichelZ for point it out)

The other reason to use SSL is that the connection cannot be spoofed/changed without you noticing.

As with all things security, with enough resources all these are moot points.

share|improve this answer
"If the attacker uses heartbleed and retrieves the keys from the destination server then any encrypted data can not be decrypted." I'm sorry, but that's simply false. –  MadHatter Apr 11 '14 at 8:25
sorry, that was exactly the opposite of what I was trying to say and of course is the whole point of the flap about heartbleed. –  rob Apr 11 '14 at 8:31
Which is wrong again. If you had used Perfect Forward Secrecy (PFS), your previously captured SSL data is useless and cannot be decrypted by a compromised key. –  MichelZ Apr 11 '14 at 8:59
good point but I can find little evidence that the magority of server are using it even now blogs.computerworld.com/encryption/22366/… I will update my answer as I have never heard of PFS before. –  rob Apr 11 '14 at 10:12

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.