LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 04-11-2014, 11:31 AM   #46
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 800

Rep: Reputation: 354Reputation: 354Reputation: 354Reputation: 354

I would do a full reboot of the system to make absolutely sure, that the vulnerable code is gone.
 
Old 04-11-2014, 11:31 AM   #47
WiseDraco
Member
 
Registered: Nov 2006
Location: Europe,Latvia,Riga
Distribution: slackware,slax, exMandriva
Posts: 365

Rep: Reputation: 28
Quote:
Originally Posted by NeoMetal View Post
Did you restart httpd? The process has to restart to link in the updated lib
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 ----------

Quote:
Originally Posted by jtsn View Post
I would do a full reboot of the system to make absolutely sure, that the vulnerable code is gone.
i do that. especially, my server uptime was only about 14 days, as so i do not lost any mega-uptime
 
Old 04-12-2014, 12:11 AM   #48
mancha
Member
 
Registered: Aug 2012
Posts: 279

Rep: Reputation: Disabled
Quote:
Originally Posted by BenCollver View Post
"The upshot is this. What you can eavesdrop on with heartbleed hacks is dynamic stuff...It's a great way to steal passwords from recent logins, but it's unlikely to give private keys."

http://blog.erratasec.com/2014/04/wh...ivate-key.html
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

Last edited by mancha; 04-12-2014 at 12:25 AM.
 
1 members found this post helpful.
Old 04-12-2014, 10:58 AM   #49
BenCollver
Rogue Class
 
Registered: Sep 2006
Location: OR, USA
Distribution: Slackware 14.1
Posts: 156

Rep: Reputation: 50
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/
 
Old 04-12-2014, 12:23 PM   #50
mancha
Member
 
Registered: Aug 2012
Posts: 279

Rep: Reputation: Disabled
Quote:
Originally Posted by BenCollver View Post
Those who do understand security missed this bug for 2 years
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
 
Old 04-12-2014, 01:39 PM   #51
mancha
Member
 
Registered: Aug 2012
Posts: 279

Rep: Reputation: Disabled
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.
Old 04-12-2014, 06:27 PM   #52
BenCollver
Rogue Class
 
Registered: Sep 2006
Location: OR, USA
Distribution: Slackware 14.1
Posts: 156

Rep: Reputation: 50
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.
 
Old 04-13-2014, 03:03 AM   #53
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 276

Rep: Reputation: 83
@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..
 
Old 04-13-2014, 07:05 AM   #54
BenCollver
Rogue Class
 
Registered: Sep 2006
Location: OR, USA
Distribution: Slackware 14.1
Posts: 156

Rep: Reputation: 50
@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.
 
Old 04-13-2014, 09:53 AM   #55
Smokey_justme
Member
 
Registered: Oct 2009
Distribution: Slackware
Posts: 276

Rep: Reputation: 83
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
 
Old 04-20-2014, 07:14 AM   #56
BenCollver
Rogue Class
 
Registered: Sep 2006
Location: OR, USA
Distribution: Slackware 14.1
Posts: 156

Rep: Reputation: 50
"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
 
  


Reply

Tags
heartbleed


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 03:45 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration