Heartbleed Update
blogs.akamai.com
Heartbleed Update
1–10 of 14 posts
Re: Heartbleed Update
#2Maybe Akamai should create a challenge just like Cloudflare did...
Re: Heartbleed Update
#3> Do you have any evidence of a data breach?
> No. And unfortunately, this isn't "No, we have evidence that there was no breach of data;" rather, "we have no evidence at all." We doubt many people do - and this leaves data holders in the uncomfortable position of not knowing what, if any, data breaches might have happened
I like their honesty - many organizations simply stated "our evidence suggests there was no breach"
Re: Heartbleed Update
#4Maybe Akamai should create a challenge just like Cloudflare did...
We did, internally. We got key extraction in an hour, about the same as Cloudflare---so we save $10k and rotate exposed keys. Since we renew most certs on an annual basis, all our easy-to-rotate certs were flipped months ago. The outliers are weird custom stuff, or two-year EV certs.
You ever try rotating 400 EV certs in a weekend? Neither have most Certificate Authorities. They say security is people, processes, technology. Our tech worked well---but not so well I can't wish it was better. Our people did awesome, stalwart work. But the PKI industry processes are due for some serious reconsideration.
I can't tell you how badly I want TACK or DANE or CT live and working right now.
Re: Heartbleed Update
#5Maybe Akamai should create a challenge just like Cloudflare did...
What would that solve? We already know that it's possible to compromise the private key using this bug. The problem is that no one knows whether attackers have actually done so, since very few organizations will log all the data going in and out of their servers.
Re: Heartbleed Update
#6Maybe Akamai and other large internet companies (Google, Facebook, Cloudflare etc) contribute now financially and/or with engineers towards openssl development or create an alternative.
This whole thing has been one giant clusterfuck, I myself seen one rather larger alexa top 1000 site being exploited by sessions being hijacked.
Re: Heartbleed Update
#7Maybe Akamai and other large internet companies (Google, Facebook, Cloudflare etc) contribute now financially and/or with engineers towards openssl development or create an alternative. This whole thing has been one giant clusterfuck, I myself seen one rather larger alexa top 1000 site being exploited by sessions being hijacked.
Totally agree.
I'm finalizing a tool to scan and visualize the top 1M alexa site URLs to see which are vulnerable - and ~3% (30 000) still are. In the last few days I've observed about ~5% of those getting patched daily (~1500).
Re: Heartbleed Update
#8Maybe Akamai and other large internet companies (Google, Facebook, Cloudflare etc) contribute now financially and/or with engineers towards openssl development or create an alternative. This whole thing has been one giant clusterfuck, I myself seen one rather larger alexa top 1000 site being exploited by sessions being hijacked.
Akamai posted its special heap implementation to openssl-dev yesterday: " rel="nofollow">http://marc.info/?l=openssl-users&m=139723972124003&w=2>. We'll follow that up with help to adapt it to openssl's needs---which are much, much broader than our set of problems. We run 100k machines, sure---but all x86-64, almost all Linux, and all running substantially the same software. We don't use DTLS. We don't use any PAKE systems. We are, in some sense, an easy problem.
The OpenSSL Foundation is trying to help people with those needs and needs varying on every imaginable dimension communicate with secrecy and strong authentication. We should expect them to need several times as many developers full time on that problem as any of the planetary-scale computing companies.
Re: Heartbleed Update
#9It seems interesting that Akamai protected itself from heartbleed by implementing a custom allocator, which was in some respects at least part of what caused heartbleed.
Re: Heartbleed Update
#10It seems interesting that Akamai protected itself from heartbleed by implementing a custom allocator, which was in some respects at least part of what caused heartbleed.
Well OpenSSL didn't implement their own malloc exactly, they used some weird indirection to try and speed it up on some platforms, which may have bypassed protections that some versions of malloc have enabled (guard pages).