What is Digg?Sponsored by Dragon Age: Origins
Join the Dragon Age: Origins development team on Facebook view!
facebook.com/DragonAgeOrigins - EA presents BioWare's new dark fantasy epic Dragon Age: Origins. '9/10' from Game Informer.
60 Comments
- netneutrality, on 01/04/2009, -2/+47That's a lot of Diggs for 5 seconds: http://i44.tinypic.com/hts878.jpg
- awhiteflame, on 01/04/2009, -0/+14Related: Free SSL Certificates!
- Morac, on 01/04/2009, -2/+11The headline is misleading. 14% of the SSL certificates may be using MD5, but that doesn't necessarily make them unsafe.
The collision attacks worked because a Certificate Authority (specifically RapidSSL) was still issuing MD5 certificates. They are no longer doing so. So the attack won't work any more.
See Tim Callan's SSL Blog at http://blogs.verisign.com/ssl-blog/
More specifically this Q&A question:
Q: What happens to customers who have certificates in place using the MD5 hashing algorithm?
A: Today's research revealed a potential attack that required the issuance of new certificates. Existing end entity certificates are not at risk from this attack. Nonetheless, any customer who would like to do so can replace any MD5-hashed certificate free of charge. Until further notice VeriSign is suspending its normal replacement fees for these certificates. Because this replacement is not necessary to ensure the continued security of sites, we are not requiring the replacement of such certificates, as we have previously with the likes of weak Debian keys. - austang, on 01/04/2009, -5/+13I'm sure that those aren't on any of the mainstream sites most people buy on.
- blackjack75, on 01/04/2009, -0/+7That's called server-side cache.. still says 5 seconds after several hours.
- absentmindedjwc, on 01/04/2009, -0/+6this may be true, but what was demonstrated is the actual creation of an SSL certificate, not the cracking of it. The exploit that was discovered and shown at CCC last week was talking about actually creating an SSL certificate that browsers will accept as legit. In this case, going to bank1.com (instead of bankone.com, or something like that) and getting a page that has a valid SSL cert without actually having to be legit.
you can find the information about the vulnerability here - http://events.ccc.de/congress/2008/Fahrplan/events ... - tightscrummy, on 01/04/2009, -0/+5Except when they gave a Microsoft cert to somebody unaffliated with Micorsoft. http://www.microsoft.com/technet/security/bulletin ...
Back then most browsers had revocation disabled too. - boldfire, on 01/04/2009, -0/+5I think you'll find only 74.242% of Western Civisation hold that ability.
- HesNikke, on 01/04/2009, -0/+5The other day I went through all my root certificates and revoked the ones that used MD5 hashing as the certificate signing algorithm. After doing this, Google became untrusted. Why? They use one of Thawte's broken, untrustable root certificates to verify the validity of Google's certificates. The chain of trust to Google is broken for the time being. :\
- fluidfoundation, on 01/04/2009, -2/+6Anyone can make up statistics.
- inactive, on 01/04/2009, -0/+3Smelly?
What are you, 6? - kgool, on 01/04/2009, -0/+3Not exactly. They just check your Dunn&Bradstreet # or Tax ID number and then do a phone verification. It is true that a Verisign SSL and it can take up to a week instead of hours to verify.
- etx313, on 01/04/2009, -0/+3Just noticed that as well. Just get rid of that stupid thing already Digg, it sucks.
- boldfire, on 01/04/2009, -0/+3Hopefully the certificate providers allow a swift and organised way for websites to change to a secure algorithm. If the providers take responsibility and are quick they could relatively easily reduce any potential problems.
- RiverBelow, on 01/04/2009, -0/+3Except for... you can't target an SSL certificate?
- inactive, on 01/04/2009, -0/+3zomg
- gabbagabbahey, on 01/05/2009, -0/+2The better way would be to remove the flawed MD5 CA root certificates via a browser update.
- etx313, on 01/04/2009, -0/+2Ugh....
- r3zonance, on 01/05/2009, -0/+2@Morac
Give up your argument. You are completely wrong in this instance and I'm 100% behind unluckier for two reasons:
a) that is exactly how I understand HTTPS/SSL and the CA role to work.
b) it is what Steve Gibson said on Security Now!
If you have created a fake, yet valid CA certificate (for the likes of Verisign/Equifax/GoDaddy etc.) you have free reign to generate certificates that a browser will unequivocally accept as valid. And when combined with the DNS attack you are in a world of pain. - gabbagabbahey, on 01/05/2009, -0/+2Does anyone really think that anyone is going to check the hashing algorithm used for every SSL-enabled site they visit?
- voidentry, on 01/04/2009, -0/+2Unfortunately, there are a lot of web masters out there who put sites online/manage sites without being aware of the latest security issues (sometimes being unaware of exploits from years ago). Go figure.
- unluckier, on 01/05/2009, -0/+2Yes, the headline is misleading. But you went the wrong way with it, actually. You are very wrong in your post. Possibly because of reading the Verisign blog entry, because well, they are in the business of selling certificates and they would like to give the impression that they doing the right thing and that you should continue to use their services.
If every single CA stopped issuing MD5 certificates, the attack will still work. In fact, if every of the 14% of certificates that use MD5 were revoked right now, the attack will still work. Why? You need to understand how SSL/HTTPS works with respect to your browser.
When you visit a web site using HTTPS, the browser checks that the certificate provided by the web site is signed by one of the root CAs that is already installed in your OS/browser. There is an implicit trust here, in that every certificate issued by *every* CA that your browser uses is OK to trust as valid. i.e., the CA has done the appropriate footwork to verify that the organization requesting the certificate is indeed who they claim to be. Well, that's the theory... it doesn't always work that way in practice. e.g., the 2001 incident with Verisign issuing a Microsoft certificate to somebody who wasn't really Microsoft.
http://www.verisign.com/support/advisories/authent ...
But back to the browser... If you visit a site via HTTPS and the certificate is signed by a root CA trusted by the browser, then your browser happily will communicate with that site and not display any warnings. Different browsers display this situation differently, but typically it's indicated by a closed padlock somewhere in the browser's UI. The user interprets this as two things:
1) The site I'm viewing is really who they claim to be
2) The traffic between my computer and the site is encrypted
Now the attack:
By leveraging a weakness in MD5, somebody has created a rogue CA that is trusted by web browsers. By using this CA, a certificate can be generated for any web site, and the browser will trust the certificate. paypal.com, bankofamerica.com, ebay.com, you name it! Combined with a DNS subversion, somebody can for example make a phishing site that looks real *and* has a valid certificate, which could be enough to fool even the most technically savvy users.
So given the above, how is it that the attack "won't work any more" ? Individual sites or certificates that use MD5 are not "unsafe". It's any browser that trusts a root CA that has issued MD5 certificates at any point in the past. (pretty much all browsers) - Tek12, on 01/04/2009, -1/+3That's right... the 'machines' have begun their plan...
- unluckier, on 01/05/2009, -0/+2Perhaps you are not fully understanding what a CA certificate is. A CA (Certification Authority) certificate is used in the generation of certificates (e.g. for use in HTTPS web sites). The fact that a CA certificate was forged, this means that the attacker now has the ability to generate their own certificates for any site that they choose. The real CA (RapidSSL) is no longer needed at this point. If I have a fake CA certificate for an existing CA that is trusted by web browsers, then that means that *I* can generate certificates that will be trusted by web browsers.
http://www.win.tue.nl/hashclash/rogue-ca/ - culley, on 01/05/2009, -0/+2You never know, on Security Now with Steve Gibson and Leo, Steve mentioned loads of sites that were still using MD5 and you would be surprised to hear there are as there technology companies.
- morcheeba, on 01/04/2009, -1/+3Just because a successful exploit hasn't been published isn't a need to worry. Operators of bot-nets have access to far more computing power than these researchers did.
- SleepParalysis, on 01/04/2009, -0/+2Haha, watch out when you're browsing the web on a public access point or one that you share with a lot of people. It only takes one machine performing a man in the middle attack with something like Cain or Ettercap to steal your SSL secured passwords.
You can see this happening when you go to log into a site via HTTPS/SSL and it says the certificate is untrusted when normally you can log right in. Software like Cain when performing the mitm will capture those certificates. - vat0r, on 01/04/2009, -0/+2This would also make it possible for some to sell fakes as legit with the right knowledge. I don't understand why it is so expensive to buy an SSL certificate for a domain. Shared SSL is ok but it doesn't look very professional to the end user when they get a prompt. I'm just ranting, wish it were cheaper.
- todamax, on 01/04/2009, -0/+2so thats what those ps3s are used for...
- jesusJones128, on 01/05/2009, -0/+2Alot of people seem to be missing the bigger picture. It's not a website specific thing, it's more of a browser issue if anything. The attackers could sign certificates as if they were one of the bigger CAs(Such as Thawte or Verisign), and there will be no complaints from the browser since most automatically accept those as being trusted. It's an easy fix really, just patch the browsers to warn on any hashed certs. The real problem would occur if someone ran a phishing site, it could look very legitimate with signed certs, couple that with DNS poisoning and it would be almost indistinguishable.
- wadd, on 01/04/2009, -0/+2That could be a good sign suggesting reputable sites are taking this seriously. Or it could just be coincidence :-(
- WibWobble, on 02/02/2009, -0/+2The problem was actually a bit funny/stupid.
I have to turn my system clock back 3 years to get a cracked license for a torrent'ed software to work. I forgot to turn the clock forward again this time. Now I'm back in 2008, the certificates are working fine :)
Lesson: Don't torrent software. Or do, just remember to keep your clock updated. - ultrafez, on 01/05/2009, -0/+2Which is useful to no-one except you. Generally SSL certificates are supposed to be useful to other people, so your setup is completely and utterly useless.
- webvicious, on 01/04/2009, -0/+2I'm not surprised at all...
- Meesher, on 01/04/2009, -0/+1I don't know. I just checked the certificates on two sites I use (my local bank and the other a major investment site). Both certificates use both SHA-1 and MD5. Why use both? To support outdated browsers? No green in the address bar either. I'm guessing that Firefox is checking the more secure one, but if one was using a browser that only supported MD5, I wonder if the sites would be viewable without any warnings.
- ibell63, on 03/09/2009, -0/+1I'm pretty sure the login uses SSL, why wouldn't it?
- WibWobble, on 02/02/2009, -2/+3Not exactly related, but my university mail, google mail, blogger, and google reader's secure sites have all suddenly stopped working for me...
- PeterNorton, on 01/04/2009, -2/+3I thought 135,000 is pretty substantial. Frightening that so many are still out there. Goes against all common sense.
- greeniemeani, on 01/04/2009, -1/+2Is the internet safe???????
- loafer, on 01/04/2009, -0/+1^^^Whilst that is a somewhat extreme view about verislime IMHO ^^^
Plenty of SSL providers will give away 30-45 day fully signed certs for goodness sake! thats about 10 times longer than the scams run for!
... and if a service is free and useful the bottom-feeders will abuse it! - nabiy, on 01/05/2009, -0/+1no, you shouldn't check the hashing algorithm of every SSL-enabled site you visit. that wouldn't make sense. Just the ones you trust and rely on (like your bank).
- Eugenitor, on 01/05/2009, -0/+1What the hell are you babbling about? I don't need SSL to access Digg.
- r3zonance, on 01/05/2009, -0/+1"It's an easy fix really, just patch the browsers to warn on any hashed certs."
All certificates are hashed, it's just the hashing algorithm that differs. - culley, on 01/05/2009, -0/+1Yeah but they don't have the software the would distribute the algorithm to be crunched by all those infected. there just used to send out spam email.
They dont have some sort of folding@home installed on there computer do they. - morcheeba, on 01/05/2009, -0/+1Why wouldn't they have a folding@home capability? There's no reason to limit the botnet to spam only - why not try anything that is profitable? Chances are that they've already got a self-updating feature that will upload new code, because this is useful for evading anti-virus programs and adding new infection vectors.
- voidentry, on 01/04/2009, -1/+1It was bound to happen at some point. Also, if anyone is concerned, it's highly unlikely that any of your banks or other sites you submit sensitive information to have those vulnerabilities. One would hope large financial institutions would be aware anyway... Still though, it's probably not a good idea to go buy something from superawesomesitewithamazingdealseventhoughnoonehasheardofus.com
- nabiy, on 01/05/2009, -1/+1most browsers already have a mechanism to protect you. You should have your browser check for server certificate revocation and you may also want to verify that your trusted certificate is not using md5 (md5RSA). If you use chromium or google chrome you can see how to do this here: http://free-chrome.net/blog/?p=97
if you use internet explorer you can see how to do this here: http://blogs.technet.com/swi/archive/2008/12/30/in ... - stevehanler, on 01/04/2009, -1/+183% of all statistics are made up.
-
Show 51 - 66 of 66 discussions
© Digg Inc. 2009
— Content created and posted by Digg users is 