Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Private Keys Stolen Within Hours From Heartbleed OpenSSL Site

samzenpus posted about 5 months ago | from the that-didn't-take-long dept.

Security 151

Billly Gates (198444) writes "It was reported when heartbleed was discovered that only passwords would be at risk and private keys were still safe. Not anymore. Cloudfare launched the heartbleed challenge on a new server with the openSSL vulnerability and offered a prize to whoever could gain the private keys. Within hours several researchers and a hacker got in and got the private signing keys. Expect many forged certificates and other login attempts to banks and other popular websites in the coming weeks unless the browser makers and CA's revoke all the old keys and certificates."

cancel ×

151 comments

Sorry! There are no comments related to the filter you selected.

Dupe ! (-1)

Anonymous Coward | about 5 months ago | (#46741131)

Only a few hours ago ... [slashdot.org]

The CA should not revoke the certificates, (0)

Anonymous Coward | about 5 months ago | (#46741133)

the user of the keys should do this. Would you want to pay for new certs even if you were not affected by heartbleed?

Re:The CA should not revoke the certificates, (5, Insightful)

mysidia (191772) | about 5 months ago | (#46741415)

the user of the keys should do this. Would you want to pay for new certs even if you were not affected by heartbleed?

It's within the CA's right, however, to scan the URLS certified by each certificate, test for Heartbleed vulnerability --- and automatically revoke, if they determine that the site is vulnerable.

Re:The CA should not revoke the certificates, (5, Insightful)

mwvdlee (775178) | about 5 months ago | (#46741593)

Which only tells us they're patched now, it doesn't tell them how much time the site was vulnerable.

Re:The CA should not revoke the certificates, (5, Funny)

Anonymous Coward | about 5 months ago | (#46741781)

Pff now you're telling me the CA has the authority to tell me which certificates are bad??

Oh piss on that!

Re:The CA should not revoke the certificates, (5, Insightful)

beelsebob (529313) | about 5 months ago | (#46741845)

Yes... That's the entire point of a CA, to certify that a person really is that person. If the certificate is bad, they can no longer make that certification, so it really really really is their job to do that. It is in fact their only job.

Re:The CA should not revoke the certificates, (1)

radarskiy (2874255) | about 5 months ago | (#46742295)

I choose to read the AC as making a joke.

Re:The CA should not revoke the certificates, (4, Funny)

dcollins117 (1267462) | about 5 months ago | (#46742303)

Pff now you're telling me the CA has the authority to tell me which certificates are bad??

If that is an issue, there is nothing stopping you, or anyone, from becoming their own Certifcate Authority. I've done this for my own sites, since I am at least 97% sure I am who I claim to be.

Re:The CA should not revoke the certificates, (5, Informative)

mellon (7048) | about 5 months ago | (#46742661)

It doesn't matter who revokes the keys. Right now only Firefox and Chrome ever check for revoked certs, and Chrome at least has this disabled by default. If you are running iOS or Android, your browser doesn't check the CRL before trusting the cert. So it's great if web sites revoke certs, but it doesn't actually change anything on the end user side, for the most part. I'm not saying anything about Windows platforms because I don't have access to any; it's possible that they do support CRLs. You can check whether your browser supports CRLs by going to this test URL [grc.com] . If you don't get a warning from your browser, your browser isn't checking CRLs.

Re:The CA should not revoke the certificates, (4, Informative)

mhotchin (791085) | about 5 months ago | (#46742695)

IE 11 (at least) works properly, right out of the box:

There is a problem with this website’s security certificate.

This organization's certificate has been revoked.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.
We recommend that you close this webpage and do not continue to this website.
Click here to close this webpage.

Re:The CA should not revoke the certificates, (1)

Teun (17872) | about 5 months ago | (#46743317)

Android's Dolphin ignores the certificate and Firefox recognises it.

Even root CA certificates may be at risk. (3, Insightful)

Z00L00K (682162) | about 5 months ago | (#46741139)

Be aware that even the root CA certificates can be at risk right now, and that can really cause problems.

Re:Even root CA certificates may be at risk. (4, Informative)

mlts (1038732) | about 5 months ago | (#46741187)

Depends. A website's SSL key may be slurped up. However, a root CA key should be either kept on an offline machine or kept in a hardware security module where the key won't be divulged, ever... the module will sign a key, and that's it.

I'm sure some places will have their root CA on an externally connected machine, then try to place blame, likely saying how insecure UNIX is (when it isn't any particular flavor of UNIX that is at fault.)

Re:Even root CA certificates may be at risk. (1)

mysidia (191772) | about 5 months ago | (#46741435)

I'm sure some places will have their root CA on an externally connected machine, then try to place blame, likely saying how insecure UNIX is (when it isn't any particular flavor of UNIX that is at fault.)

Since this is in violation of the CA/Browser forum rules and Mozilla policies that pertain to trusted CA certificates; they are either lying, grossly negligent, OR both: if they have a root CA's private key ever loaded into an externally connected machine.

In fact.... a CA root certificate itself, is not a trusted certificate for ANY domain name. They'd have to go out of their way to compromise it --- such as by issuing a OCSP responder certificate with the same keypair.

Re:Even root CA certificates may be at risk. (1)

Charliemopps (1157495) | about 5 months ago | (#46742873)

You would not believe what VP's will force you to do to get their $20 million flagship project out the door and then quickly forgotten about after the guy that was forced to do it quits in disgust. There was a time when I'd be surprised by insanely stupid security vulnerabilities but after a few years in the trade I've learned never to be surprised by anything.

Re:Even root CA certificates may be at risk. (2)

mysidia (191772) | about 5 months ago | (#46743253)

You would not believe what VP's will force you to do to get their $20 million flagship project out the door and then quickly forgotten about after the guy that was forced to do it quits in disgust.

Fraud that can get you in jail is not one of those things that some VP can force you to do.

The CA has to be validated by third party auditors, before it can even be trusted. One of the aspects that must be audited is the governance of that CA and the policies and controls of the CA designed to ensure the CA operates only according to the policies, and that would include that no system admin or member of management is capable of bypassing the rules.

Re:Even root CA certificates may be at risk. (2)

Jane Q. Public (1010737) | about 5 months ago | (#46742315)

Also keep in mind that this involves a long, very serious, well-engineered attack.

The developer who first won the challenge made literally millions of requests to the server, in order to gather and piece together the chunks of memory slurped up.

Re:Even root CA certificates may be at risk. (4, Funny)

gweihir (88907) | about 5 months ago | (#46741229)

That is BS. Nobody sane installs a root certificate on productive network-connected hardware, unless they are terminally stupid. Oh, wait...

Re:Even root CA certificates may be at risk. (1)

zacherynuk (2782105) | about 5 months ago | (#46743139)

YES! That's the whole point of this isn't it?

To get everyone to get new certificates so that NSA and GCHQ (etc) has an easy and seamless MITM



Back of the net.

(sadface)

Re:Even root CA certificates may be at risk. (1)

cryptizard (2629853) | about 5 months ago | (#46743341)

How would getting new certificates let them do anything they couldn't do now?

Dupe ! (-1)

Anonymous Coward | about 5 months ago | (#46741141)

Only a few hours ago ... [slashdot.org]

https is dead (5, Funny)

lougarou (34028) | about 5 months ago | (#46741143)

For all practical purposes, https is dead. There is no way browsers will carry around the hundreds of thousands of possibly-stolen-so-unsafe certificates fingerprints (to consider these tainted/revoked). The only way forward is probably to move away to an incompatible protocol. And if possible, cure some of the X509 wrong ways.

Re:https is dead (-1)

Anonymous Coward | about 5 months ago | (#46741169)

lol

Re:https is dead (5, Insightful)

Anonymous Coward | about 5 months ago | (#46741317)

Nah, the browsers will just reset 'zero epoch' for SSL certificates they'll accept to ONLY accept certificates issued after some date post-exploit, and all major SSL vendors will likely reboot their intermediate keychains so there's only a handful of 'revocation' certificates that will actually be needed due to the tree-of-trust model: Anything in the chain gets revoked everything below it goes away.

And yes, this means the folks that were Johnny on the Spot about reissuing their certs might have to re-issue them AGAIN due to fixing their issue so quickly, but that's honestly pretty minor compared to the huge swaths of forever-vulnerable sites that need to effectively have their SSL status revoked regardless of what they do or don't do.

WolfWings, who hasn't logged into SlashDot in YEARS.

Re:https is dead (0, Troll)

Anonymous Coward | about 5 months ago | (#46741507)

Wow, "Insightful", seriously? /. mods really love them some unsubstantiated expert analysis from Anonymous Coward.

Reality check: only 17.5% of SSL sites had heartbeat extension turned on. Most sensitive and popular sites have reissued and revoked certificates.

Implementing Mr. WolfWings's solution would mean punishing 85% of the network because admin of myshittyblog.net has not yet fixed his shit and could have left his users vulnerable to NSA snooping.

Re:https is dead (2, Interesting)

Anonymous Coward | about 5 months ago | (#46741647)

What do you mean, punish? Free certificates for all. The other AC is spot on. This is a make or break moment for the CAs. Unless they ensure that all vulnerable keys can no longer be used, the CA model is terminally damaged. The only way to make sure that all clients reject all vulnerable certificates is to change the root certificates and issue new certificates to everybody. If neither the CA nor the browser makers take this admittedly drastic step, I predict extensions soonish which will reject certificates issued before 2014-04-08. Either way, all certificates will have to be replaced soon.

Re:https is dead (2, Insightful)

Anonymous Coward | about 5 months ago | (#46741913)

It's only free if admin's time is free and CA's time is free. Issuing certificates is not something all CAs can simply do one-sidedly and automatically. I take it you never had to manage certificates, did you?

Only a week passed and already most Internet users won't see a site that didn't take care of that. The wave of reissuing and revoking is still growing, so most of vulnerable certificates will disappear pretty soon.

Meanwhile, you're talking about wasting billions on the off chance a site with a hundred users was interesting enough for someone who could and would effectively MITM it - note that while grabbing the key only takes luck and time, actually using it requires much more.

Re:https is dead (3, Interesting)

jonwil (467024) | about 5 months ago | (#46741959)

The problem with replacing HTTPS is that you will need to maintain regular HTTPS for all those clients that cant upgrade to a newer browser. (which exposes web sites to these threats) And you have to convince browser and web server vendors to support the new HTTPS replacement.

Google would probably do it (on desktop, ChromeOS, Android and its custom web/SSL server software) especially if it made it harder for the kind of man-in-the-middle-using-fake-certificates type attacks the NSA have been using (the ones that let the NSA serve up fake copies of popular web sites as a vector to infect other machines). Opera and others that use the Google rendering engine would probably use the Google support.

Mozilla would probably do it if you could convince them that its not just going to be bloat that never gets used.

Apache would probably support it via a mod_blah and if they dont, someone else would probably write one.

Other FOSS browsers and servers (those that do HTTPS) would probably support it if someone wrote good patches.

But good luck convincing commercial vendors like Microsoft and Apple to support a new protocol. And the Certificate Authorities would fight hard against anything that made them obsolete (which any new protocol really needs to do)

Re:https is dead (1)

AHuxley (892839) | about 5 months ago | (#46743107)

Hi jon,
How safe are Perfect Forward Security (PFS) and other "per-session" encryption keys from this mess? Thanks

Re:https is dead (2, Insightful)

Anonymous Coward | about 5 months ago | (#46742915)

Time for SHTTP. The useless certificate authorities can go and die in a dark hole. Your bank can send you their public key. For most places you wouldn't even need a password.
OpenSSH is developed by competent people and it has virtually no preauthentication attack surface.

Re:https is dead (1)

sjames (1099) | about 5 months ago | (#46743065)

It'll never happen. Look at how hard it was to finally kill IE6. Then add all those embedded web servers in APs, switches, routers, NAS, etc etc and imagine getting their firmware updated (not to mention the devices that are no longer updated by the manufacturer).

Re:https is dead (0)

Anonymous Coward | about 5 months ago | (#46743383)

No it aint - it's called distrust and verify

I don't have a single Root Certificate trusted in Firefox and only add exceptions for those places that I absolutely have to. Does it help? Don't know but seeing as how I've seen compromises such as the Diginotar and not been affected, I have to say that although it can be annoying, it's not as bad for me as anyone who trusts the entire chain.

Oh, man, what a mess (3, Interesting)

93 Escort Wagon (326346) | about 5 months ago | (#46741175)

I do have to wonder if the task was made easier given the purpose of the server. After all, I'd think it wouldn't get traffic at all except for those people responding to the challenge. But, still, this proved it's possible.

So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?

Re:Oh, man, what a mess (4, Interesting)

sphealey (2855) | about 5 months ago | (#46741421)

From the linked site: "He sent at least 2.5 million requests over the course of the day." So, no rate limiters, anti-DDS protection, or other active countermeasures in operation. Reasonable for this challenge but not overly realistic.

sPh

Re:Oh, man, what a mess (5, Insightful)

heypete (60671) | about 5 months ago | (#46741445)

So not only do those of us responsible for web servers need to generate new server certs for all of our servers... pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?

Netcraft actually has an interesting article [netcraft.com] about that very situation.

Obviously, the CAs don't really have a choice in the matter, but I can't imagine they really have capacity issues in regards to the actual revoking/signing as that's all automated. If things get crazy busy, they can always queue things -- for most admins it doesn't really matter if the new cert is issued immediately or after 15 minutes.

Human-verified certs like org-verified and EV certs might have a bit of delays, but domain-validated certs should be quick to reissue.

Of course, revocation checking for browsers is really bad [netcraft.com] . Ideally, all browsers would handle revocation checking in real-time using OCSP and all servers would have OCSP stapling [wikipedia.org] enabled (this way the number of OCSP checks scales as the number of certs issued, not the number of end-users). Stapling would help reduce load on CA OCSP servers and enable certs to be verified even if one is using a network that blocks OCSP queries (e.g. you connect to a WiFi hotspot with an HTTPS-enabled captive portal that blocks internet traffic until you authenticate; without stapling there'd be no way to check the revocation status of the portal).

Also, browsers should treat an OCSP failure as a show-stopper (though with the option for advanced users to continue anyway, similar to what happens with self-signed certificates).

Sadly, that's basically the opposite of how things work now. Hopefully things will change in response to Heartbleed.

Re:Oh, man, what a mess (0)

Anonymous Coward | about 5 months ago | (#46741755)

Who wants to be the vulnerability was planted by the NSA, so after its discovery they could over a period of a couple days collect all the new certs being generated with a single warrant.

Re:Oh, man, what a mess (2, Informative)

Anonymous Coward | about 5 months ago | (#46741895)

That's not how certificate signing requests work. The private key isn't handed over to the CA.

Re:Oh, man, what a mess (5, Informative)

mysidia (191772) | about 5 months ago | (#46741495)

pretty much every current web server cert in existence also needs to be revoked. Are the CAs even willing/able to do something on that scale in a short amount of time?

Calm down. A majority of web servers are not vulnerable and never were. All in all... less than 30% of SSL sites need to revoke any keys.

Some websites are running with SSL crypto operations performed by a FIPS140-2 hardware security module; these are not vulnerable, since OpenSSL doesn't have access to the private key stored in the server's hardware crypto token.

Many web sites are running on Windows IIS. None of these servers are vulnerable.

Plenty of web sites are running under Apache with mod_nss, instead of mod_ssl. None of the websites using the LibNSS implementation of SSL are vulnerable.

Many web sites are running on CentOS5 servers with Redhat's openssl 0.9.x packages. None of these servers were ever vulnerable.

Many web sites are running on CentOS6 servers, that had not updated OpenSSL above 1.0.0. These websites weren't vulnerable.

Many websites are running behind a SSL offload load-balancer; instead of using OpenSSL. Many of these sites were not vulnerable.

Re:Oh, man, what a mess (2)

Vairon (17314) | about 5 months ago | (#46741815)

All websites running under any publicly released version of SUSE Linux Enterprise Server using the distribution's openSSL package were not vulnerable to HeartBleed.

Re:Oh, man, what a mess (0, Funny)

Anonymous Coward | about 5 months ago | (#46741983)

I believe the key point you made there is that anyone running IIS was never vulnerable. In a way, I consider this poetic justice for all those people who were too cheap to invest in a secure commercial product and tried to pinch pennies on OpenSSL. Karma's a bitch.

Re:Oh, man, what a mess (2, Informative)

Anonymous Coward | about 5 months ago | (#46742067)

I believe the key point you made there is that anyone running IIS was never vulnerable except for all the times they were [google.com]

Here, FTFY.

PS: Mister Ballmer, we know you've got plenty of time on your hands now, but be subtler, please.

Re:Oh, man, what a mess (-1)

Anonymous Coward | about 5 months ago | (#46743053)

Listen you linux fucktard. You aren't going to win any security arguments this week.
Shouldn't you be eyeballing some other morons code?

Re:Oh, man, what a mess (2, Informative)

GodWasAnAlien (206300) | about 5 months ago | (#46742155)

"secure commercial product"

I assume you implying that closed source is more secure.

Doe you really believe that? Why?
  - Do you think security by obscurity is real security?
  - Do you believe that closed source has more code audits?
  - Do you believe that there is less change of NSA or other back doors in closed source software.

"IIS was never vulnerable..."

Really? Try a search for "IIS SSL vulnerability".

Re:Oh, man, what a mess (2)

hairyfeet (841228) | about 5 months ago | (#46741995)

Showing yet again that there is a reason why I like Comodo when it comes to security when Comodo found out their certs were vulnerable thanks to heartbleed Comodo got on the ball replacing certs [pcworld.com] ASAP.

No company is perfect, every company will fuck up now and then, but the nice thing about Comodo is when they see a problem they don't try to bury it or play the blame game. Instead they announce "here is the problem and here is what we are doing about it" and then they DO IT, no stalling or bullshitting. In the case of heartbleed as companies patch their sites they can get a fresh key, no muss no fuss.

Re:Oh, man, what a mess (2)

Anonymuous Coward (1185377) | about 5 months ago | (#46742243)

I do have to wonder if the task was made easier given the purpose of the server. After all, I'd think it wouldn't get traffic at all except for those people responding to the challenge.

On the contrary, it may have made things harder.

Reading the private key relies on forcing malloc() to reuse some small block from the free block list with a lower address than the block containing the key, insteading of simply carving a new block out of free memory (with an address higher than the key).

That may be easier to do on a busy server, because you don't have to send millions of queries just to fragment its memory; you may just assume that malloc is already reusing freed blocks, and exploit the algorithm it uses to do that (eg by manipulating the length of payload to let it allocate some unusual size block for which some gap just before the key is the perfect fit).

Re:Oh, man, what a mess (0)

Anonymous Coward | about 5 months ago | (#46742283)

So we can ssafely assume that about 2 years ago, the (3-L-A and any other agencies) had their couple of hours cooking time and it was all downhill from there... privacy, schmivacy.

I can't use cloudflare, connection is insecure (1)

Mirar (264502) | about 5 months ago | (#46741177)

Interestingly enough, my browser (firefox) doesn't let me access https://www.cloudflarechallenge.com/ [cloudflarechallenge.com] , complaining about the security certificate...?

Re:I can't use cloudflare, connection is insecure (2, Informative)

Anonymous Coward | about 5 months ago | (#46741233)

Be glad...

I can see t with my browser, and this is, what I can read (among other things)
:
"Can you see this site? You shouldn't be able to, we have revoked the certificate. If you can still see this message, Certificate Revocation may be broken in your browser. See this post for more details."

Re:I can't use cloudflare, connection is insecure (4, Informative)

_Shad0w_ (127912) | about 5 months ago | (#46741323)

Chrome turns the "check for revocation" option off by default, it seems.

Re:I can't use cloudflare, connection is insecure (1)

Jonas the Bold (701271) | about 5 months ago | (#46742669)

You're right! But why!?!?

Why would it turn off checking revocation by default! Is there any possible reason that this is anything but grossly irresponsible?

Re:I can't use cloudflare, connection is insecure (1)

michelcolman (1208008) | about 5 months ago | (#46741325)

In Safari on my Mac, I got a warning saying the security certificate could not be verified, and I could choose to simply continue. So then I got the text saying I shouldn't be able to see that site. Shouldn't the browser have actually said the security certificate had been revoked?

Re:I can't use cloudflare, connection is insecure (5, Funny)

lgw (121541) | about 5 months ago | (#46741417)

Internet Explorer for the win (my head asploded):

There is a problem with this websiteâ(TM)s security certificate.

This organization's certificate has been revoked.

Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server.

We recommend that you close this webpage and do not continue to this website.

Click here to close this webpage.

I feel like I've fallen into Bizarro world, where IE is the safe browser and IIS the safe server. Maybe I should grow a goatee?

Re:I can't use cloudflare, connection is insecure (1)

K. S. Kyosuke (729550) | about 5 months ago | (#46741947)

Ditto. IE works; Firefox, Chrome didn't even notice. ;/

Firefox noticed for me (2)

Chirs (87576) | about 5 months ago | (#46742657)

Running Firefox 28 on Win7, it said the cert was revoked.

Re:Firefox noticed for me (2)

dbraden (214956) | about 5 months ago | (#46742875)

Same here, but using Firefox 28 on OSX, error message "Peer's Certificate has been revoked. (Error code: sec_error_revoked_certificate)".

Re:I can't use cloudflare, connection is insecure (1)

Kaenneth (82978) | about 5 months ago | (#46742693)

In case no one noticed, MS view on security has changed a LOT since Windows 95 and IE 6.

Re:I can't use cloudflare, connection is insecure (2)

93 Escort Wagon (326346) | about 5 months ago | (#46741455)

On iOS I get no such warning...

And actually, the default OS X settings don't check revocation lists either. To enable that you need to open up "Keychain Access", go to "Preferences -> Certificates", and set both OCSP and CRL to "Best Attempt".

Re:I can't use cloudflare, connection is insecure (0)

Anonymous Coward | about 5 months ago | (#46741239)

That's good. They have since revoked the certificate which is used on that server, so the complaint is a sign that certificate revocation works in your browser, for that particular CA.

Re:I can't use cloudflare, connection is insecure (0)

Anonymous Coward | about 5 months ago | (#46741249)

This is deliberate on their part.

They have now revoked the certificate, and if you access the site, it tells you that you shouldn't be able to.

Re:I can't use cloudflare, connection is insecure (2)

David Hughes (2865305) | about 5 months ago | (#46741261)

Cloudflare said on their wall on Facebook that they were going to leave the site up, as a means of checking how browsers deal with revoked certs: https://www.facebook.com/Cloud... [facebook.com] So Firefox is probably doing the right thing here. Last time I looked, Chrome didn't display any warning. Which is nice.

Re:I can't use cloudflare, connection is insecure (2, Informative)

Anonymous Coward | about 5 months ago | (#46741397)

Chrome has online revocation check turned off by default - you can go to Settings -> Advanced and switch on "Check for server certificate revocation" under HTTPS/SSL section

Re:I can't use cloudflare, connection is insecure (1)

Anonymous Coward | about 5 months ago | (#46741567)

Chrome has online revocation check turned off by default? Why? That does not make any sense at all! I would much rather have a false positive than a fail-open.

Re:I can't use cloudflare, connection is insecure (2, Insightful)

Anonymous Coward | about 5 months ago | (#46741685)

I'd guess "because online checking can be slow - as in literally _seconds_ before site starts loading!!11!" and "there's offline revocation list and Chrome updates often enough".

Or may be "because NSAMI6KGB paid us to weaken the security".

Re:I can't use cloudflare, connection is insecure (1)

DarwinSurvivor (1752106) | about 5 months ago | (#46742787)

Not sure about the branded Chrome, but Chromium on my arch machine shows one hell of a scary message about the browser down-right refusing to connect to it due to the certificate.

The internet is closed for renovations? (1)

Anonymous Coward | about 5 months ago | (#46741179)

Until they revoke all potentially compromised CA's and roll out a brand new set I don't see how they can consider the breach closed even if the vuln itself is fixed.

Re:The internet is closed for renovations? (1)

Joce640k (829181) | about 5 months ago | (#46741553)

Luckily the system is designed to be able to do that.

(And many sites have already done so).

Re:The internet is closed for renovations? (0)

Anonymous Coward | about 5 months ago | (#46741601)

How many HTTPS enabled sites you visit every day? How many of those are not called "Google", "Facebook", "Twitter" (and others from top 10 in traffic rank)?

For purposes of an average web surfer, breach _is_ closed. No need to shout "Sky is falling!" If you want to go offline for awhile to stay safe - good for you, pretty healthy and all.

If anything, the problem lies in the past - we don't know and we can't know what could have been siphoned and by whom.

Re:The internet is closed for renovations? (0)

Anonymous Coward | about 5 months ago | (#46741637)

" the problem lies in the past - we don't know and we can't know what could have been siphoned and by whom. " It was my point essentially. If the root certs are taken and that's not known at this time due to the nature of this exploit, org's would potentially NOT change them thinking they were secure, but are in fact compromised.

Re:The internet is closed for renovations? (0)

Anonymous Coward | about 5 months ago | (#46741993)

Why would root certs be anywhere _near_ an Internet-facing computer? I'm not even talking "used in a SSL server on Internet-facing computer" (where it could be retrieved by this exploit) or even "be anywhere in the memory of an Internet-facing computer" (where there would be a chance to extract them by some other exploit).

Time to reboot! (0)

Anonymous Coward | about 5 months ago | (#46741195)

Time to reboot the internets!

Oh, and BTW, slightly off topic, but can I have a checkbox on my tax return so I can select where I want my tax money to go?
Thank you.

Nothing is proved or verified in this story and co (0)

Anonymous Coward | about 5 months ago | (#46741197)

Like the comment title said.

Don't keep vulnerable servers running! (2, Insightful)

Anonymous Coward | about 5 months ago | (#46741203)

Most sites don't have PFS enabled, and that means anyone who has recorded a site's traffic prior to the publication of the bug only needs a short time to get the key and can then decrypt all recorded sessions. The Heartbleed exploit doesn't just jeopardize the data that is currently flowing through OpenSSL while the attacker is reading server memory through malicious heartbeat requests. If you used a vulnerable server via a public Wifi hotspot in the past two years and someone else recorded your session, then your data is potentially readable. No certificate revocation can fix that. The longer vulnerable servers have been kept online after the disclosure, the more attackers had a chance to get private server keys. These private keys compromise recorded traffic and they enable attackers to pose as the server in the future, because certificate revocation is utterly broken. Keeping vulnerable servers running for any amount of time was reckless.

IMHO browsers should treat all existing certificates as untrusted. All certificate authorities should renew their root CA certificates and have old certificates removed from client software. The system is broken, but without making sure that all potentially compromised certificates are made unusable, many server admins will just keep using old certificates, and then there's no reason to trust SSL at all.

And enable PFS, FFS!

Re:Don't keep vulnerable servers running! (2)

ledow (319597) | about 5 months ago | (#46741373)

When I looked into my server, I found out:

The OpenSSL library I'm using wasn't vulnerable.
Thus, my keys are as "safe" as they were before.

Also, to enable PFS, I would have to upgrade - to one of those OpenSSL versions that is vulnerable (but obviously there are "fixed" ones now).

I would also only be able to use EC cryptography with PFS with OpenSSL. I don't trust EC personally, yet. It's just not been around long enough for me. And I find it suspicious that every time something happens, the answer is "Let's go to EC!". If anything, I suspect it might well be something that people we don't want deciding algorithms are driving us towards.

Sorry, but until I trust EC, I can't trust PFS. And I can't use either until I upgrade to a version of OpenSSL that was vulnerable to this attack for a long time without anyone noticing (whereas my current version wasn't).

Ironically I "score" more on certain SSL test sites with old OpenSSL than with the newer one... and I get artificially capped because I don't support EC.

Until someone shows me that PKE is broken, then EC is not necessary for my usage. PFS is something I'd like but, as OpenSSL only supported it when using EC algorithms last I looked, I don't see it as any more secure.

Re:Don't keep vulnerable servers running! (1)

jonwil (467024) | about 5 months ago | (#46742023)

https://www.openssl.org/docs/a... [openssl.org] suggests that OpenSSL (the official upstream version at least) does in fact support DHE and PFS without EC.

There are people that tust SSL-certificates??? (2)

gweihir (88907) | about 5 months ago | (#46741213)

Seriously, how out-of-touch can you get? That the X.509 global certificate system has been fundamentally compromised has been well-known for quire a few years to everybody that follows the news at least in a cursory fashion.

Re:There are people that tust SSL-certificates??? (3, Informative)

fuzzyfuzzyfungus (1223518) | about 5 months ago | (#46741303)

The bigger issue is that even people who don't trust the (braindead; but too convenient to die) "Hey! Let's just trust about 150 zillion different 'secure' Certificate Authorities and if they signed the cert and it matches the domain everything must be OK!" are still pretty screwed if whatever specific certificate or certificates they are using are now also in the hands of some unknown and probably malicious 3rd party...

There's a pretty big difference between 'because the system is pretty stupid, you can generate a valid certificate for any domain by knocking over any one of an alarming number of shoddy and/or institutionally captured CAs' and 'your private key, yours specifically, can be remotely slurped out of your system and used to impersonate it exactly'.

Re:There are people that tust SSL-certificates??? (3, Insightful)

gweihir (88907) | about 5 months ago | (#46741941)

I am not sure it is a bigger issue, since many of these sites will not be publicly reachable. But it definitely is an issue foe example for large corporations that use SSL in their Intranet with self-signed certificates. They now have to wonder whether some of their staff has attacked their servers this way.

Oh please... (1)

Anonymous Coward | about 5 months ago | (#46741273)

Like this would come as a surprise?
Like heartbleed in itself is a surprise? For every major zero day like this out from the dark there is ten more in the forest.
General people just have no clue. Most organizations have no clue. Media have no clue. Just people in the dark know.
Anyone working in the industry would know better than to trust anything online or supposedly safe.
Secret stuff fares far better offline or in general "snail-mail", than online.
No software is safe, ever has been or ever will be.
The chain of trust for your program scope (hw, em-radiation, firmware, os etc) is just too big to consider safe at large.

And the cry goes up from ten thousand admins, (4, Funny)

SuricouRaven (1897204) | about 5 months ago | (#46741343)

Fuck.

(Except here in the UK, we are more creative with our profanity.)

Re:And the cry goes up from ten thousand admins, (3, Funny)

John Bokma (834313) | about 5 months ago | (#46741889)

By Jove!

Bully! (0)

Anonymous Coward | about 5 months ago | (#46742659)

Bully!

Re:And the cry goes up from ten thousand admins, (3, Funny)

Virtucon (127420) | about 5 months ago | (#46742125)

Bollocks!

Re:And the cry goes up from ten thousand admins, (1)

Anonymous Coward | about 5 months ago | (#46743109)

Bloody hell.

Re:And the cry goes up from ten thousand admins, (4, Funny)

Teun (17872) | about 5 months ago | (#46743425)

I say!

Re:And the cry goes up from ten thousand admins, (2)

Nimey (114278) | about 5 months ago | (#46743441)

Perkele!

The Little People (0)

Anonymous Coward | about 5 months ago | (#46741351)

The vast majority of the world won't know about certificates, won't know what OSSL is, and even if it was explained to them in the most funniest, interesting and captivating of methods they would switch off and still not be curious while they fill out their lottery forms and moan about the weather, taxes, government and many other things that they prioritize.

They won't know or care no matter the effort to make them.

Obvious hack is obvious? (2)

bjoswald (2837207) | about 5 months ago | (#46741355)

Well yeah, considering the severity and size of attack vector. I'm sure the NSA are having a field day over at HQ, too (Hi, BTW).

I'm Smelling Something (0)

Anonymous Coward | about 5 months ago | (#46741451)

Until people start saying 'This is all lies, prove it! Right now! In front of me! Oh look it didn't happen and OpenSSL is fixed now anyway." they will believe all the spoon-feeding of crap that Microsoft and its allies are dishing out to turn XP owners away from Linux, Chromebook's, Mac's, etc and only buy Microsoft. This is going to go on for weeks and weeks with newer and more unbelievable stories. And the gullible will believe. Pity.

I'm telling you, as long as you believe all of this hot air, this is what is going to happen. Disbelieve now, do yourselves a favor and cut the rot out before it can grow any more. Keep this stuff at arms length where it can do no unverifiable harm.

Tools for checking (3, Informative)

bobstreo (1320787) | about 5 months ago | (#46741531)

There are a couple tools available at:

https://github.com/Lekensteyn/... [github.com]

It's python based so YMMV

They will tell you if you are vulnerable (See the README.md file)

NSA has the keys to the kingdom (0)

Anonymous Coward | about 5 months ago | (#46741721)

NSA has the keys to the kingdom

They have access to the CA's
They have access to RSA's keys.

This was in the news years ago. Why the sudden panic now?

There is more where that came from (5, Interesting)

Anonymous Coward | about 5 months ago | (#46741753)

Coverity is a static analysis tool. It was tested on the source code with the Heartbleed vulnerability and did not find it. The developers of Coverity made a proof-of-concept modification to treat variables as tainted if they're subjected to endianess conversion, based on the assumption that such variables contain external and thus potentially hostile data. With this modification, Coverity finds the Heartbleed bug, as described in this blog post [regehr.org] . Note the comment below the screenshot: "As you might guess, additional locations in OpenSSL are also flagged by this analysis, but it isn’t my place to share those here." This may just be a consequence of not detecting all ways in which a tainted variable is sanitized, or it may point to more problems.

Re:There is more where that came from (1)

TapeCutter (624760) | about 5 months ago | (#46742927)

OpenSSL has is own memory manager that sits on top of malloc(), why I'm not sure?

Trolls (0)

Anonymous Coward | about 5 months ago | (#46742719)

samzenpus and Billly Gates this article is nothing more than a troll by a pair of assholes.

And its assholes like these who caused me to change my /. password and throw it away 2 years ago.

And slashdot's relation to think geek is why I stopped shopping there.

6 days (1)

Anonymous Coward | about 5 months ago | (#46742735)

The announcement and fix have been "out" for 6 days. Last Monday it hit the fan, and the world went crazy. I recovered some data from when two hard disk platters went from 32 bad blocks to 57 bad blocks to 269 bad blocks to 643 bad blocks in two days. Then I checked and I was running OpenSSL1.0.1e, and being vulnerable, grabbed 1.0.1f and updated about 10 more software packages. With all the md5 checksums, downloading extras that some of the newer packages needed, rebuilding my build scripts and testing....took another day. So mine has been fixed since Wednesday. Now its Sunday, and I'm still hearing about this. Its true that OpenSSL has over 433000 lines of source of which about 70% is C, and because its non-trivial, auditing it is hard. The guy who added the heartbeat extension also added it in RFC6520 for the Internet Engineering Task Force. He missed counting the incoming packet size and returning a packet of the same size. So did the guy (also with PhD in CS) who reviewed it. And the yelping goes on. Why oh why after this many days, are people not downloading and fixing already? Its been 6 days. Yes the two made a mistake. Those that have not applied the fix by late Tuesday, have made an even bigger one.

Slashdot is slow (0)

Anonymous Coward | about 5 months ago | (#46742923)

What the heck, Slashdot? I read about this yesterday somewhere else. Has Slashdot become irrelevant? /don't answer that

stolen? (0)

Anonymous Coward | about 5 months ago | (#46743015)

"private-keys-stolen-within-hours-from-heartbleed-openssl-site"

"Stolen" is a word that has a meaning.
If someone says look here and try to get my keys, "stolen" is the wrong word.

A simple question - Can you provide simple answer? (2)

zacherynuk (2782105) | about 5 months ago | (#46743189)

How do I become a trusted root certificate authority ?

Re:A simple question - Can you provide simple answ (0)

Anonymous Coward | about 5 months ago | (#46743359)

You wave a large amount of money under the noses of browser vendors to get your root certificate added.

Preferably you should also look like you know what you are doing and probably have some ISO numbers after your company name.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>