I would do a full reboot of the system to make absolutely sure, that the vulnerable code is gone.

yes, thanks. find out., that site, where i check, looks like keep my first check in cache. another site after shows actual - 1.0.1g - version.

---------- Post added 04-11-14 at 07:32 PM ----------

i do that. especially, my server uptime was only about 14 days, as so i do not lost any mega-uptime

Robert Graham later recanted and upgraded his severity assessment slightly from <never> to <very unlikely> in terms of the risk of
having private keys stolen. In fact, his blog as late as 5AM UTC (20140412) still has the note "Thus, while your SSL certificates are
likely safe, your passwords aren't."

It's unfortunate there are people who claim to understand security whose knee-jerk reaction is to irresponsibly downplay vulnerabilities.

As it turns out, Graham was not just slightly wrong, he was entirely off-the-mark. So far two people have solved CloudFlare's
challenge and successfully stole their private key. One can only imagine what groups with significant resources might have been
able to do in the span of the two years and change the vulnerability has existed.

As I mentioned in my post the very day the vulnerability went public, the intelligent thing to do is assume all credentials (including
primary key material) that have been used in the context of [D]TLS transmissions involving affected client/servers are potentially
compromised.

--mancha

1 members found this post helpful.

Those who do understand security missed this bug for 2 years. It merits attention and critical thought. I agree with you that the intelligent thing to do is to re-key and change passwords. It is interesting to consider applications like Chrome that apparently don't check for revoked certificates (no CRL nor OSCP).

http://arstechnica.com/business/2012...tion-checking/

You're confusing two issues: 1) the environment/processes that allowed for the flaw to get introduced and go unnoticed for 2+ years,
and 2) how we manage the vulnerability once it's known.

Regarding #2, the day heartbleed was made public a semi-detailed report, that explicitly says private keys are vulnerable, was
published.

In light of this, reporting that private keys can't be stolen (or that their theft is infinitely difficult) is as irresponsible as standing in the
hallway of a building, with fire alarms going off everywhere, and telling people to not worry about evacuating.

--mancha

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

1 members found this post helpful.

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