4 ms·

Here was our initial conclusion from the CloudFlare post you referenced: ============ We think the stealing private keys on most NGINX servers is at least ext

Here was our initial conclusion from the CloudFlare post you referenced: ============ We think the stealing private keys on most NGINX servers is at least extremely hard and, likely, impossible. Even with Apache, which we think may be slightly more vulnerable, and we do not use at CloudFlare, we believe the likelihood of private SSL keys being revealed with the Heartbleed vulnerability is very low. That’s about the only good news of the last week. We want others to test our results so we created the Heartbleed Challenge. Aristotle struggled with the problem of disproving the existence of something that doesn’t exist. You can’t prove the negative, so through experimental results we will never be absolutely sure there’s not a condition we haven’t tested. However, the more eyes we get on the problem, the more confident we will be that, in spite of a number of other ways the Heartbleed vulnerability was extremely bad, we may have gotten lucky and been spared the worst of the potential consequences. That said, we’re proceeding assuming the worst. With respect to private keys held by CloudFlare, we patched the vulnerability before the public had knowledge of the vulnerability, making it unlikely that attackers were able to obtain private keys. Still, to be safe, as outlined at the beginning of this post, we are executing on a plan to reissue and revoke potentially affected certificates, including the cloudflare.com certificate. Vulnerabilities like this one are challenging because people have imperfect information about the risks they pose. It is important that the community works together to identify the real risks and work towards a safer Internet. We’ll monitor the results on the Heartbleed Challenge and immediately publicize results that challenge any of the above. ============ Which is exactly what we did. To be clear, we were wrong. Our mistaken assumption was focusing on the private key itself and not focusing enough on the exponents that are used to generate the key -- which is what the researchers who solved the challenge were able to obtain. As the wishy-washy conclusion above hopefully makes clear, even when we said it was hard to get the private keys, we were very uncertain and uncomfortable with that conclusion. That's why we posted the challenge. What the challenge did was answer the question definitively: you can get private SSL keys. Knowing that has been valuable for us in deciding to accelerate reissue/revocation process for all the certs we manage on behalf of our customers. Remember: at our scale, revoking hundreds of thousands of certs risked breaking our CA partners' infrastructure, so it wasn't without a cost. Knowing the risk is higher than we originally thought accelerated our efforts which will be complete in the next 48 hours. And, beyond CloudFlare, our hope is knowing the risk is real and proven has benefited other organizations as well.

tptacek 13y ago
Look, I'm arguing this because I'm a nerd and because I know you're wrong, not because I think this is a moral crusade or anything. But, once again: Your "Cloudflare Challenge" (that's what you called it) was not a particularly useful way to answer the question posed by Heartbleed. What you want to know is, "is there private key material in heap memory?", or, to make things even simpler, "are our assumptions about how key material hits heap memory accurate?". The correct way to answer this question is to instrument and analyze an OpenSSL/nginx runtime, not to create and market a treasure hunt for an undisclosed private key on a single site. You employ smart people. You could have done better than this challenge. Instead, what seems to have happened is that your company got inserted into the middle of a story it had little to do with (correct me if I'm mistaken and unaware of something your team did to research Heartbleed), and, with that spotlight shining, actively marketed a harmful false conclusion about the bug while also bidding for the spare cycles of other people who might have been more effective doing something other than poking at your server. (For what it's worth, I don't think for a moment that you did either of those things intentionally). I think if you did either of those two things differently --- either didn't publicly go out on a limb suggesting that you thought keys would be hard (or, as Bruce Schneier seems to have read from your blog post, "next to impossible") to recover keys, or didn't set up the game site while doing it --- I wouldn't be moved to comment. Like I said, not after pelts. Just, if we're putting the Cloudflare response up for questioning, I have some issues to point out.
- eastdakota 13y ago
  We spent 5+ days trying to get the private key. We, along with a lot of other smart folks, concluded it was unlikely. Within 11 hours of crowd sourcing the problem we were proven wrong. You may not have found that useful, for us having definitive proof definitely was.
  - tptacek 13y ago
    It's interesting you put it that way, because it hadn't occurred to me that your team had an early heads-up on the bug before writing that blog post. So what you're saying is that for 5+ days, the team was working on the assumption that the only time OpenSSL RSA private keys touched heap memory was when they were first loaded. It seems like you can just look at the code and see how that's not the case. But I might be wrong, too. It is a tricky thing, being in the center of a critical vulnerability disclosure story.

tptacek 13y ago

Look, I'm arguing this because I'm a nerd and because I know you're wrong, not because I think this is a moral crusade or anything. But, once again: Your "Cloudflare Challenge" (that's what you called it) was not a particularly useful way to answer the question posed by Heartbleed. What you want to know is, "is there private key material in heap memory?", or, to make things even simpler, "are our assumptions about how key material hits heap memory accurate?". The correct way to answer this question is to instrument and analyze an OpenSSL/nginx runtime, not to create and market a treasure hunt for an undisclosed private key on a single site. You employ smart people. You could have done better than this challenge. Instead, what seems to have happened is that your company got inserted into the middle of a story it had little to do with (correct me if I'm mistaken and unaware of something your team did to research Heartbleed), and, with that spotlight shining, actively marketed a harmful false conclusion about the bug while also bidding for the spare cycles of other people who might have been more effective doing something other than poking at your server. (For what it's worth, I don't think for a moment that you did either of those things intentionally). I think if you did either of those two things differently --- either didn't publicly go out on a limb suggesting that you thought keys would be hard (or, as Bruce Schneier seems to have read from your blog post, "next to impossible") to recover keys, or didn't set up the game site while doing it --- I wouldn't be moved to comment. Like I said, not after pelts. Just, if we're putting the Cloudflare response up for questioning, I have some issues to point out.

eastdakota 13y ago
We spent 5+ days trying to get the private key. We, along with a lot of other smart folks, concluded it was unlikely. Within 11 hours of crowd sourcing the problem we were proven wrong. You may not have found that useful, for us having definitive proof definitely was.
- tptacek 13y ago
  It's interesting you put it that way, because it hadn't occurred to me that your team had an early heads-up on the bug before writing that blog post. So what you're saying is that for 5+ days, the team was working on the assumption that the only time OpenSSL RSA private keys touched heap memory was when they were first loaded. It seems like you can just look at the code and see how that's not the case. But I might be wrong, too. It is a tricky thing, being in the center of a critical vulnerability disclosure story.