Were Intelligence Agencies Using Heartbleed in November 2013? (opens in new tab)

"However, a HeartbeatRequest message SHOULD NOT be sent during handshakes. If a handshake is initiated while a HeartbeatRequest is still in flight, the sending peer MUST stop the DTLS retransmission timer for it. The receiving peer SHOULD discard the message silently, if it arrives during the handshake. In case of DTLS, HeartbeatRequest messages from older epochs SHOULD be discarded."

But that doesn't make sense to me because the PoC code didn't complete the handshake did it?

Edit: according to Google the reason is that OpenSSL does not honour the "SHOULD" part of the spec :/

I conjecture that the TLS handshake was used to fingerprint the server, since not all 3 versions of the payload will succeed on all TLS versions.

[0] http://vrt-blog.snort.org/2014/04/heartbleed-memory-disclosu...

If you don't mind me asking the question I always ask people when helping with their security (both cyber and physical) and eliminating an element of potential paranoia:

Would your work/life make you a worthwhile legitimate target? (don't mean to sound rude but I guess it differentiates between random attacks and targeted ones)

I would say that generally it depends on the threat model and risk versus potential adversary (some African states would be different to China in capabilities etc). I think also a big part is really internalising and enforcing the idea that you will be breached at some point and acting accordingly, to minimise the data lose and be able to recover. So for example, if your only doing low risk stuff then the convenience of something like Windows/Mac and normal email service outweighs any risks from a breach (as long as you know how to access risk correctly and take the sensible/basic precautions). However for higher risk stuff then generally open-source solutions can potentially offer more security (too many to mention but tons of good ones here - Tails, TOR etc: https://prism-break.org/‎).

I would caveat though that I am not someone who always drink the open-source koolaid all of the time. I think the recent Heartbleed and suspicions about TrueCrypt goes to show that occasionally we are make assumptions about the security of these tools based on a false sense of security. Proper security is a longer process of peer review, code audits etc that everyone kind of just takes for granted are done with open-source projects.

Sometimes I think it's a little bit like the "free rider" problem, were everyone (including so many in relation to OpenSSL) is happy to use the tool but don't want to spend time/money/brainpower looking, adding, reviewing the underlying code. Then we get a lot of myths emerging (TrueCrypt is very safe for example - that might be the case but has it really been audited yet? Also, who is doing the auditing? etc).

Obviously the fact that open source stuff is free and the code can be looked at and eventually fixed is a very good thing. Also, usability is a security feature and I think some of the secure open-source alternatives have problems in this area - though the work of the Guardian Project, Whisper Systems etc is doing a great job of fixing this aspect of things.

Apologies if I got a bit sidetracked on this answer. If there is more specific advice you want, drop me a mail to the email (low risk stuff only) in my profile.

Some dude finds a 0day and sells it to some agency.

As far as I know, we presently have no way of determining whether or not the NSA had knowledge of the bug.

From the CVE[1], we see that OpenSSL versions from the very start in 2012[2] were vulnerable.

1 https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-01...

2 http://www.openssl.org/source/ (Jan 3 14:41:35 2012 openssl-1.0.1-beta1.tar.gz)

>"For the past decade, NSA has lead [sic] an aggressive, multi-pronged effort to break widely used internet encryption technologies," stated a 2010 GCHQ document. "Vast amounts of encrypted internet data which have up till now been discarded are now exploitable."

> An internal agency memo noted that among British analysts shown a presentation on the NSA's progress: "Those not already briefed were gobsmacked!"

Which certainly sounds like SSL traffic was broadly compromised as far back as 2010.

That doesn't conclusively prove heartbleed isn't of use to these agencies though; for example one possible scenario is that the British analysts were "gobsmacked" by some other undisclosed vulnerability similar in scope to this one, which has since been fixed (and, if you're inclined that way, you could theorize that heartbleed was introduced to replace it..)

[1] http://www.theguardian.com/world/2013/sep/05/nsa-gchq-encryp...

The vulnerability is over two years old. I second scott_karana in thinking that you're wrong.

So it is entirely possible that CAs have been compromised and Glenn Greenwald and the rest of those with the Snowden cache have no idea.

Thinking about it more, it would actually be awesome. The cabal of CAs would fall and hopefully a bulletproof distributed system model would eventually replace this snakeoil industry.

EDIT: ...might've come later. exact timeline probably unknowable.

Yes. An attacker would have to collect that information, AND have grabbed the private keys from a vulnerable site. But there is nothing technically stopping that from happening. (And of course I expect there may be a market for those keys now)

But that would just be crazy, right?

Yes. Crazy but possible.