Update 2014-04-11: Updated information on our later analysis here.
We're getting a lot of questions about the OpenSSL Heartbleed fix. What follows are the most commonly asked questions, with our answers.
The Heartbleed bug affects a heartbeat functionality within the TLS/DTLS portion of the library. It allows the attacker to -- silently and without raising alarms -- dump portions of the servers memory to the client. This can allow the attacker to walk through the memory space of the server, possibly dumping private SSL keys and certainly exposing important secrets.
All versions of the OpenSSL library between 1.0.1 and 1.0.1f contain the Heartbleed bug and should be updated to 1.0.1g as soon as possible. (The vulnerability researchers have posted their analysis, and an excellent analysis is up on Sean Cassidy's blog.
What information could an attacker extract? Estimates vary, with it being everything from keying material (yes, the private SSL keys) to data from that or other SSL connections. Attackers could gain access to more information than just reading a cleartext stream, which may make this one of the worst SSL vulnerabilities to date. It's certainly different in nature than most. Readily available example scripts make it easy to extract user passwords and session cookies.
For Akamai customers, the important questions:
Are Akamai systems patched? Yes. We were contacted by a member of the OpenSSL community in advance. As a result, Akamai systems were patched prior to public disclosure.
Were my private keys safe? Akamai uses a custom secure memory allocation scheme, controlling which portions of memory each library can use, and more specifically controlling the storage location of SSL keys and other secrets. Our initial assessment suggests that this memory allocation provided better protection than the ordinary `OPENSSL_malloc` memory allocator. At this time, we don't believe it possible to overflow a buffer from the ordinary heap to the special custom key heap. We are continuing to investigate.
Should we revoke and reissue certificates? This is a hard question. If you operate your own internal CA, and can use OCSP to communicate the revocation, probably. But check first: Most desktop browsers don't honor revocation anyway. Most CAs don't have the scalable infrastructure to support revocation lists with millions of entries.
What could have been compromised? While public commentary has focused on the possible loss of long-term key secrecy, we may miss the absolute certainty in the breach of confidentiality around user information: login credentials and cookies. Application developers should urgently consider whether or not to invalidate any login cookie issued prior to patching this vulnerability.
What about my origin? If your origin was behind an active Site Shield configuration, then it was probably safe--but should be updated anyway.
Andy Ellis is Akamai's Chief Security Officer