For those interested in verifying if Fedor Indutny (the first to solve CloudFlare's challenge) really did it, here's a little how-to:

1. Get CloudFlare's public key
   
   Code:

   ---

   $ openssl s_client -connect www.cloudflarechallenge.com:443 </dev/null 2>/dev/null | openssl x509 -pubkey -noout > cloud.pub

   ---

2. Get Fedor's content signature (signed with the CloudFlare private key he was able to steal(??))
   
   Code:

   ---

   $ curl -s https://gist.githubusercontent.com/indutny/a11c2568533abcf8b9a1/raw/1d35c1670cb74262ee1cc0c1ae46285a91959b3f/1.bash | tail -n +2 | openssl enc -d -base64 > fedor.sig

   ---

3. Construct the message Fedor signed
   
   Code:

   ---

   $ echo "Proof I have your key. fedor@indutny.com" > fedor.txt

   ---

4. Verify
   
   Code:

   ---

   $ openssl dgst -verify cloud.pub -signature fedor.sig fedor.txt

   ---

Woops! Time for new SSL certificates.

--mancha

Just for the sake of argument: The fact that this bug has been exploited long before it became public knowledge is relevant to the security response. We know how early a related compromise could have begun. I still suspect that SSL users have more to consider, such as clients that accept revoked certificates. It almost seems like security theater. It reminds me of an old quote that security is a process, not a technology. While we are responding with due diligence, we can also verify the situation rather than taking it at face value. Anything less would be irresponsible. The report was easy to test, and in hindsight it was shown to be factually wrong. Did it cause anyone to die a fiery death? Did it serve some nefarious political purpose? If not, then it was a relatively inexpensive to quote the report, to consider it, and to rescind it.

@Ben: I agree with the client part.. I think browsers that don't check for revoked certificates are now a the biggest security risk for an end-user.. However, I'm not sure what do you mean by the fact that the report was shown to be factually wrong..

@Smokey: Robert Graham initially reported that private keys could not be stolen. mancha gave a little how-to, showing that private keys can be stolen.

Yes, I know..
I thought that you meant the report linked by mancha in which they already say it's possible to steal private keys (and was available from the very first day).. That was my confusion since that one was actually proven right..
That was my confusion :)

"However, revocation checking is a complex topic and there's a fair amount of misinformation around. In short, it doesn't work and you are no more secure by switching it on. ... You can tell when something is security theater because you need some absurdly specific situation in order for it to be useful. ... We compile daily lists of some high-value revocations"

https://www.imperialviolet.org/2014/...vchecking.html

In other words, Google's revocations are valuable, but not yours. Because soft fail. Lots of browser discussion. The Internet is more than the web. Hard fail might be good for an MTA, OpenVPN, etc. The paranoid might even wish to enable it in a browser.

-Ben