Beta

Slashdot: News for Nerds

×

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!

CCC Create a Rogue CA Certificate

CmdrTaco posted more than 5 years ago | from the they-even-faked-this-dept dept.

Security 300

t3rmin4t0r writes "Just when you were breathing easy about Kaminsky, DNS and the word hijacking, by repeating the word SSL in your head, the hackers at CCC were busy at work making a hash of SSL certificate security. Here's the scoop on how they set up their own rogue CA, by (from what I can figure) reversing the hash and engineering a collision up in MD5 space. Until now, MD5 collisions have been ignored because nobody would put in that much effort to create a useful dummy file, but a CA certificate for phishing seems juicy enough to be fodder for the botnets now."

cancel ×

300 comments

You know what I hate? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26269061)

Crusty panties. For God's sake, ladies, if you're menstruating then couldn't you at least wear black underwear and throw away your other stainers?

I'm a guy but I still don't buy light-colored underwear and I sure-as-hell throw them out if they become stained for any reason.

Re:You know what I hate? (0, Offtopic)

Ractive (679038) | more than 5 years ago | (#26269099)

Dude this has got to be the most offtopic comment ever

Re:You know what I hate? (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#26269147)

Yeah, Goatse and Frosty P1SS aren't nearly as off-topic. We all LOVE that stuff.

Alright this Internet is ruined (5, Funny)

Anonymous Coward | more than 5 years ago | (#26269065)

Let's go make a new one.

Re:Alright this Internet is ruined (3, Interesting)

plover (150551) | more than 5 years ago | (#26269451)

I wonder how broken the intarwebs would be to me if I simply deleted all the MD5-based root certificates from my box? Would I even notice?

Re:Alright this Internet is ruined (-1)

Anonymous Coward | more than 5 years ago | (#26269475)

Vous savez, je sais que ce n'est pas des moutons merde. Je sais quand je le mets dans ma bouche, la Matrice dit que mon cerveau, il est juteux et délicieux. Après neuf ans, vous savez ce que j'ai réalisé? L'ignorance est un bonheur. Mais la partie est drôle, je ne suis même pas dans la matrice! Il est la réalité! Je mange des moutons merde!!

Re:Alright this Internet is ruined (0)

Anonymous Coward | more than 5 years ago | (#26269775)

Pourquoi la mère après la baisse modérée? Il est dommage que la modération est comprise Slashdot vers le peuple français.

Re:Alright this Internet is ruined (0)

Anonymous Coward | more than 5 years ago | (#26269861)

Merda mesmo é ficar ai falando em francês. Já que é pra sacanear, vai ficar curioso e não vai entender porra nenhuma do que eu to escrevendo.

Re:Alright this Internet is ruined (4, Informative)

Alrescha (50745) | more than 5 years ago | (#26269627)

"I wonder how broken the intarwebs would be to me if I simply deleted all the MD5-based root certificates from my box? Would I even notice?"

I think a better idea would be to simply delete all the certificates from your box (CA certs included!). Then start marking individual web certs as trusted after you inspect them yourself.

A.

Re:Alright this Internet is ruined (2, Funny)

neoform (551705) | more than 5 years ago | (#26269839)

Will there be blackjack and hookers?

rogue not (0)

Anonymous Coward | more than 5 years ago | (#26269087)

Re:rogue not (1)

cbiltcliffe (186293) | more than 5 years ago | (#26269373)

No, no, no. The 'rouge' is referring to the face colour and embarrassment of the legit CAs when it turns out that they're issuing SSL certs to www.we-will-hack-you-good.com

Rouge CA? (5, Funny)

realmolo (574068) | more than 5 years ago | (#26269097)

I prefer teal CAs, myself. Or possibly burnt sienna CAs. Sometimes fuschia CAs.

It's ROGUE you dumbass.

Re:Rouge CA? (2, Insightful)

Daimanta (1140543) | more than 5 years ago | (#26269119)

It could be a rogue communist CA. That way, they're both!

Re:Rouge CA? (1)

Dagvl (59065) | more than 5 years ago | (#26269223)

Well, the rogue certificates were red in the diagrams, so using "rouge CA" in the summary has some backing :)

ROGUE not ROUGE (-1, Redundant)

Yvan256 (722131) | more than 5 years ago | (#26269105)

CmdrTaco should go to the Derek Zoolander Center For Kids Who Can't Read Good.

Re:ROGUE not ROUGE (1)

MightyYar (622222) | more than 5 years ago | (#26269157)

There's no way he'd fit in there. It would have to be at least... 3 times as big.

from the ... dept? (3, Funny)

TypoNAM (695420) | more than 5 years ago | (#26269117)

Oh noes! What department of Slashdot did this article come from? Its the end of the world as we know it! ;)

Re:from the ... dept? (4, Funny)

DoofusOfDeath (636671) | more than 5 years ago | (#26269197)

Oh noes! What department of Slashdot did this article come from? ...

Hold on - I'll check the signature.

Re:from the ... dept? (1)

Tei (520358) | more than 5 years ago | (#26269219)

One where you think "OH NOES"... and forgot to add a dept. :-/

Re:from the ... dept? (4, Informative)

TypoNAM (695420) | more than 5 years ago | (#26269233)

I hate replying to myself, but if anybody hasn't noticed that CmdrTaco has been trying to tell us something and by this article he has apparently given up:

Alan Cox Leaves Red Hat
Posted by CmdrTaco on 10:11 AM -- Tuesday December 30 2008
from the bet-wherrever-he's-going-he'll-have-electricity-and-heat dept.

The Fight Over NASA's Future
Posted by CmdrTaco on 08:15 AM -- Tuesday December 30 2008
from the still-no-power-at-my-house dept.

Storm Causes AT&T Outage Across Midwest
Posted by CmdrTaco on 08:55 AM -- Monday December 29 2008
from the guess-who-this-includes dept.

So he's without power and worse no internet at his home, aww poor CmdrTaco. Somebody please think of the slashdot editors! Anybody got a spare generator and fuel? ;)

Re:from the ... dept? (4, Funny)

MBCook (132727) | more than 5 years ago | (#26269391)

Let's put up a poll to see what we can all do!
  • I'll put Taco up at my place
  • I'll donate some food
  • I'll donate some fuel
  • I'll donate some CPU time
  • Taco is a big boy, he can help himself

Missing option (4, Funny)

pjt33 (739471) | more than 5 years ago | (#26269431)

I'll set fire to CowboyNeal. That kills two birds with one stone: fuel and food.

Re:Missing option (2, Funny)

Ethanol-fueled (1125189) | more than 5 years ago | (#26269567)

Why dosen't Taco just open up Neal's corpse with a lightsaber and crawl inside?

Rouge CA? (2, Funny)

Bert64 (520050) | more than 5 years ago | (#26269129)

The commies are creating their own CA!! PANIC!!!

Re:Rouge CA? (0)

Anonymous Coward | more than 5 years ago | (#26269681)

The commies are creating their own CA!! PANIC!!!

Could be worse.... Canadians create their own CA? ;)

Why trust the PKI? (5, Interesting)

characterZer0 (138196) | more than 5 years ago | (#26269131)

Why does your bank not give you a compact disc with their public key on it when you sign up for an account?

Re:Why trust the PKI? (1)

nurb432 (527695) | more than 5 years ago | (#26269171)

Or a usb key :)

Re:Why trust the PKI? (2, Interesting)

Nursie (632944) | more than 5 years ago | (#26269275)

Sounds like a great plan to me. Plus have a "Use only my bank's CA" mode built into your browser so you know damn well it's them and nobody else.

Re:Why trust the PKI? (1)

Nursie (632944) | more than 5 years ago | (#26269305)

Sorry to self reply but.... on top of that we should all switch away from MD5 anyway.

Re:Why trust the PKI? (1)

YouWantFriesWithThat (1123591) | more than 5 years ago | (#26269367)

shit, they could put the browser right on the usb drive and only allow online banking through their locked down browser on the drive.

Re:Why trust the PKI? (0)

Anonymous Coward | more than 5 years ago | (#26269581)

Great idea, then if you don't use Windows or maybe Mac you have to go find a public computer which might have a keylogger installed?

Re:Why trust the PKI? (0)

Anonymous Coward | more than 5 years ago | (#26269597)

Then don't use the keyboard.

Duh. /s

Re:Why trust the PKI? (3, Insightful)

Reece400 (584378) | more than 5 years ago | (#26269813)

I know, what if they just installed secured computers which allow exclusive access to their system, in various locations throughout the country so there was always one near by!

They could even install cash dispensing devices to allow you to withdraw funds from your account, maybe call them Automated Teller Machines or something along those lines. Wow, I should totally patent this idea

Re:Why trust the PKI? (1)

YouWantFriesWithThat (1123591) | more than 5 years ago | (#26269853)

well, i wouldn't care too much if they had a log of my username/pass if that wasn't the only credential needed to clean out my account. if there is a signed usb drive needed that will be pretty hard to clone with a keylogger.

Re:Why trust the PKI? (4, Informative)

fastest fascist (1086001) | more than 5 years ago | (#26269313)

Using that would probably be more hassle than your average user is willing to put up with. A bigger wtf is, in my opinion: Do so many banking services really rely on a single login/pass combo per user for authentication? When banking security comes up here, I see people worry about having their login+pass revealed, which makes me think that's the only verification their banks use.

My bank at least also uses a one-time pad system, namely a numbered list of 100 pre-generated codes. So I log in using a username and pass, and then to actually do something with the on-line banking system I'm asked to provide the code that relates to a randomly chosen number between 0000 and 0099. A code can only be used once. So basically if the phishing site manages to get hold of a few numbers from a user's passcode list, the chances are still pretty slim they'll be able to do anything with them.

Of course, if they scam hundreds of people, they will get a few successes, but not very many.

Re:Why trust the PKI? (2, Interesting)

Mister Whirly (964219) | more than 5 years ago | (#26269481)

All one would have to do after a user's login credentials have been obtained is to get thier phone number, pick up the phone, call them, and say
"This is Mr. Soandso from &BANK NAME&. We have had a recent error in the code cards and would like to verify that you have one of the ones that is not a problem. Could you read line &LINE NUMBER& to me so I can check to see if you have a valid code list?"

Sure it is a little extra effort, but not so much that nobody would attempt it.

Re:Why trust the PKI? (2, Insightful)

characterZer0 (138196) | more than 5 years ago | (#26269557)

People need to be trained. If somebody claiming to be your bank calls you, ask at which extension he can be reached from the number you have for your bank, and call back. Simple.

Re:Why trust the PKI? (1)

characterZer0 (138196) | more than 5 years ago | (#26269587)

And people need to be trained not to give out information. If he asked me to read him line X to see if it is correct, I would tell him to tell me what he thinks line X should be, and I will tell him if he is right.

It is simple: do not give out information that they should already have, except that which you already know is to be used for the purpose of identifying yourself to them.

Organizations need to deal with this though. I had somebody call me from my bank asking me about charges I had made. I asked for the extension to call back. The bank had outsourced the function, and could not tell me anything other than "somebody will call you claiming to be from us, and ask you for information." I hope they have gotten it straightened out, but I refused to play along.

Re:Why trust the PKI? (1)

Mister Whirly (964219) | more than 5 years ago | (#26269655)

I follow the same guidelines, but unfortunately, we are in the minority when it comes to things such as this.

Re:Why trust the PKI? (0)

Anonymous Coward | more than 5 years ago | (#26269889)

do not give out information that they should already have, except that which you already know is to be used for the purpose of identifying yourself to them.

Hello, this is Anony Coward from National Bank, how you doing today?

I'm calling regarding activity on your account. To verify your identity, would you please read ... (looks at screen) ... item 67 on your bank keypad?

Thank you. Mr. Zero, I'm calling about a transfer to a Cayman Island account in the amount of $5000 dollars which just showed up on your account. Did you make that transfer?

Okay, Mr. Zero, I'm going to cancel that transaction and credit your account. Please note that due to some technical difficulties we're having at the moment, the credit may not show up on your account for a week or two. So don't worry if the charge shows up on your next statement. There's no need to call us about it, because I assure you that the credit is pending.

Have a nice day!

Re:Why trust the PKI? (2, Insightful)

Mister Whirly (964219) | more than 5 years ago | (#26269603)

Very true. Studies have shown that people want to be helpful and will give up information they shouldn't. And all good crackers know to attack the weakest link in the security chain - the user. The most complex lock in the world will not help you if someone hands the keys over to the "bad guys".

Re:Why trust the PKI? (1)

fastest fascist (1086001) | more than 5 years ago | (#26269591)

good point - my bank also uses the keycodes for verification over the phone when a customer calls them, so it's not a big stretch that they would call to ask about an "important issue" but say that first they need to verify you are who you say you are...

Re:Why trust the PKI? (1)

MartinSchou (1360093) | more than 5 years ago | (#26269531)

How exactly does that protect against a man in the middle attack, where the MitM has an apparently valid certificate? He'll just post a mirror of their site, change your actions to ones that include moving money out of your account to one of theirs and pass along a request for a validation to you.

Re:Why trust the PKI? (0)

Anonymous Coward | more than 5 years ago | (#26269545)

I know in the UK one bank is handing out a keyfob to business customers. The keyfob has an algorithm that works out a passkey from the current timestamp. When you log into the banks system you have to press a button on the fob that will generate your "key". The banks system will accept all keys generated in the last 30 seconds or something. The keyfobs hold subtly different algorithms in them and the fob is registered to your account number so the bank know which algorithm to use to compare too. Seems a reasonably secure system to me. This is alongside the uname passwrd etc. everything else.

Re:Why trust the PKI? (1)

Amouth (879122) | more than 5 years ago | (#26269623)

some places use them here .. they are normaly RSA keys and are 2-300$ each and are optional.. my bank doesn't use them.. but i know realestate agents that have to have them to open lock boxes on houses.. someone was a good sales man for that one.. and the banks jsut don't give a fuck.. if someone takes money out of my account it isn't their proplem as i'm the one that is short

Re:Why trust the PKI? (1)

c_g_hills (110430) | more than 5 years ago | (#26269921)

I am a normal non-business customer of a bank in the UK and I have a reader supplied by the bank that generates either a one time code for identity, or a code based upon an account number used for securing money transfers (so you can tell that you are not being phished). In both cases, the chip card and pin are required in combination with the reader, making it a rather secure system.

Re:Why trust the PKI? (1)

blhack (921171) | more than 5 years ago | (#26269617)

Our bank (chase) gave us a credit-card-sized device with an LCD on it.

It generates 8 (i think it is 8, I don't work in accounting) digit numbers that we need to put in when we log into their website to view checks and manage our account.

The numbers change every few minutes.
Is this similar to what you've got?

Re:Why trust the PKI? (1)

fastest fascist (1086001) | more than 5 years ago | (#26269683)

My bank just issues printed cards with a hundred keycodes on them.

Reality check for Mozilla (4, Interesting)

Burz (138833) | more than 5 years ago | (#26269643)

First, this issue is about banks (for instance) verifying themselves to the client, not the other way around, so not sure how OTPs and such figure into this.

Overall, between the drama over one of Comodo's trustee CAs handing out certs without verification (for mozilla.com no less) and this MD5 attack, there is a lesson on this for Mozilla:

Trusted CAs aren't the epitome of web safety. In fact, they are LESS safe than one of those "Invalid" (to use Mozilla's ill-chosen words) self-signed certificates under some circumstances.

I put the ranking of https safety as follows:

1. Any self-generated cert (even self-signed) which has been directly copied from the service provider (bank, etc.) and imported into the browser.

Though this is the most secure, it is a shame that the user may receive warnings from other Firefox users who visited the site about the cert being "Invalid", undermining confidence in this most secure method of using certs.

2. Any self-generated cert (even self-signed) verified by SHA1 fingerprint "out of bank" (e.g. letter or phone call or even email) then imported into the browser. Unfortunately the easiest method to initiate this procedure (visit the site, verify then click on a button to import) is now somewhat broken in Firefox and will quite inappropriately undermine the user's confidence in what is otherwise a very secure cert.

3. Relying on the browser-trusted CAs. Unfortunately there now many of them which are obscure even in the tech community, and some are sloppy and incompetent.

Re:Why trust the PKI? (1)

plover (150551) | more than 5 years ago | (#26269369)

Better yet, why don't they give you a smart card containing their certificate, your secret key, and provide your key encryption functions? The U.S. Army does something similar to this today -- their ID cards contain private keys for the personnel. (Unfortunately, adding the CA certificate needed to trust the card is a tedious process.)

Re:Why trust the PKI? (1)

wsanders (114993) | more than 5 years ago | (#26269377)

Actually, if you look in your Firefox built-in CA's, Wells Fargo has a couple of entries in there. I don't know *how* they got in there, of whether they work, but it looks like some kind of experiment in that direction.

Of course I would propose it's probably easier to get a bogus version of Firefox with evil CA's in a lot of PCs, than successfully set up a rogue CA, but when there are billions on dollars at stake, who cares how difficult it is.

Re:Why trust the PKI? (1)

pete-classic (75983) | more than 5 years ago | (#26269397)

That's fine for your one bank that you set up once.

I go to a lot of shows at small venues around town. Should I spend a couple of days driving around to all of them collecting their certs so I can buy tickets? (Maybe. Maybe once, maybe never.)

And where do I pick up my gmail certificate CD? And for my credit card company? (The one that doesn't have an office in my state.) And for my insurance company?

Oh, and I like to pay my cable, power, and cell phone bills on-line, too. So I guess I need to get CDs from them as well.

Oh, I also do my time sheets for work through a secure website. And I get my pay stubs through another. And manage my 401k through yet another.

I'm not so sure about your plan.

-Peter

Free virus with a new account! (1)

oneiros27 (46144) | more than 5 years ago | (#26269871)

I can see this going the way of the digital picture frames [slashdot.org] .

Still using MD5 for this ? (3, Interesting)

Yvanhoe (564877) | more than 5 years ago | (#26269141)

These certificates are at the basis of truth on secure websites. MD5 has been known to have vulnerabilities for a loooong time (2004 according to the link article). Why do not banking services keep up to date with the state of the art crypto ?

Re:Still using MD5 for this ? (1, Informative)

Anonymous Coward | more than 5 years ago | (#26269231)

From what I understood from the talk, banks do not - they use SHA1. However, about a third of all CA-signed certificates that Firefox trusts has MD5 signatures.

The cool thing is that once you have a rogue CA certificate, you can sign your bank phishing site with a SHA1 signature. This was apparently made harder to detect due to CA:s signing their own certificates with MD5 signatures, which means that if you only check for MD5 signatures in the actual certificate, it's trivial to get passed you, and if you check for MD5 signatures in the whole certification chain, you'd mostly get false positives.

Re:Still using MD5 for this ? (2, Informative)

Opportunist (166417) | more than 5 years ago | (#26269437)

Implementing something more secure costs X, cost of fraud is Y, change when Y exceeds X, until then, leave everything untouched.

That's just how banks work. You can yell at them how insecure their online banking is 'til you're blue, but you won't change a thing. I've tried. More than one way.

Telling them won't change a thing. Magazines and newspapers don't report it because they don't want to risk those multi-page bank ads. What's left besides breaking the law and using the exploits to make a point?

Banking is typically slowest to change its crypto (2, Insightful)

StandardCell (589682) | more than 5 years ago | (#26269565)

Of all the industries that are slow to implement change in cryptographic practices, banking is by far the slowest. Part of this is bureaucratic inertia, part of this is lack of trust of newer algorithms until "proven" safe, and still part of this is reliance on legacy HSMs in their server facilities. Even the NSA has mandated a faster transition to better crypto (e.g. Suite B) than banking. Banking is still using 3DES instead of AES128, although for practical purposes brute-forcing 3DES at 112 bits of effective security isn't that much worse than AES' 128 bits. Banking won't move quickly unless someone starts stealing many thousands of high-profile accounts, but it'll be a bit like a buffalo stampede.

Still, it's mind-boggling that MD5 is still in use by anyone at this point given that it is susceptible to collisions. NSA Suite B is very clear that SHA2 256 is the minimum acceptable hash, and so it should be elsewhere regardless of your symmetric or asymmetric crypto. Back in the day when RSA512 was still used for PKI because of limited computing power, there might have been an excuse to stick to MD5. And yet, we all moved on to RSA1024 and RSA2048 because RSA512 was broken too. SHA2 is free, and it works. It really is time to move on from MD5 for all uses.

Funny enough that the entire security of the Internet as most users see it is based on the MD5 hash of the browser binary...

allyourcaarebelongtous (1)

sleekware (1109351) | more than 5 years ago | (#26269145)

All Your CA Are Belong To Us

its only the CA's that use MD5 so the question is. (2, Interesting)

johnjones (14274) | more than 5 years ago | (#26269153)

some CA's use MD5 the question really should be which ones

they point to a rather doomsday scenario of having a problem with all SSL Certificate Authorities

this is not the case

only the ones that use MD5

so the question really is what is the list of SSL Certificate Authorities that do this ?

regards

John Jones

http://www.johnjones.me.uk [johnjones.me.uk]

Re:its only the CA's that use MD5 so the question (4, Informative)

gclef (96311) | more than 5 years ago | (#26269355)

It's in their slides. As of 2008, there were some big names still using MD-5:

RapidSSL
FreeSSL
TrustCenter
RSA Data Security (!)
Thawte (!)
verisign.co.jp

Re:its only the CA's that use MD5 so the question (1)

Tony Hoyle (11698) | more than 5 years ago | (#26269709)

Any CA that still uses MD5 should be removed from the list of trusted CAs in all browsers, with immediate effect.

Re:its only the CA's that use MD5 so the question (0)

Anonymous Coward | more than 5 years ago | (#26269359)

ftfa:

        * RapidSSL

        * FreeSSL (free trial certificates offered by RapidSSL)
        * TC TrustCenter AG

        * RSA Data Security

        * Thawte

        * verisign.co.jp

Re:its only the CA's that use MD5 so the question (4, Informative)

perp (114928) | more than 5 years ago | (#26269441)

If I understand the CCC's paper correctly, as long as *even one* of the CA certs trusted by the browser uses MD5, it is possible (with considerable effort) to create an intermediate CA cert that can be used to sign a cert for any FQDN, say paypal.com. Then with a little DNS poisoning, the user is directed to an https site, with a correct domain name and (if the user looks, not bloody likely) a perfectly good certificate that looks like it was signed by a cert that was signed by a cert trusted by the browser.

You don't have to create many rogue certs, all you have to to is create one rogue intermediate CA cert that can sign as many certs as you like, all of which will be accepted with the default browser config. This is what the CCC has done.

Re:its only the CA's that use MD5 so the question (1)

MonkeyOnATypewriter (1361269) | more than 5 years ago | (#26269519)

From TFA, the CAs that use MD5 are these:

        * RapidSSL
            C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1
        * FreeSSL (free trial certificates offered by RapidSSL)
            C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications
        * TC TrustCenter AG
            C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de
        * RSA Data Security
            C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority
        * Thawte
            C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com
        * verisign.co.jp
            O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign

No weakness (2, Informative)

GigsVT (208848) | more than 5 years ago | (#26269183)

It's important to note that this sort of collision is not taking advantage of any of the known weaknesses in MD5, rather it's brute force.

This is just to head off the inevitable screaming of "MD5 is broken for everything anyway!!!".

Re:No weakness (2, Informative)

Anonymous Coward | more than 5 years ago | (#26269375)

What? It's absolutely a weakness in MD5 that collisions are possible to find. These guys pushed that a little further by finding a controlled collision within a smallish time window. While the attack does require some computation, it is not "brute force" in the sense that it would not work (in a practical amount of time) against an otherwise secure 128-bit hash, but rather exploits MD5s known weaknesses.

Re:No weakness (0)

Anonymous Coward | more than 5 years ago | (#26269609)

Maybe it's my naivety, but wouldn't a hash have to be of infinite length to be able to be used in a way that guarantees no collisions?

Or is your point that hashes shouldn't be used at all? If so, what should be used?

Re:No weakness (1)

JakusMinimus (49854) | more than 5 years ago | (#26269403)

Firstly, from this article [theregister.co.uk] :

The attack is based on known weaknesses in the cryptographic hash function known as MD5. In 2004, researchers from China showed it was possible to generate the same MD5 fingerprint for two different messages using off-the-shelf computer hardware. Three years later, a separate group of researchers - many who participated in Tuesday's presentation in Berlin - built off of those findings by showing how to have almost complete freedom in the choice of both messages.

Maybe I am missing some precision thrust of meaning with your choice of words but my understanding is that the researchers utilized brute force to readily take advantage of a known weakness of MD5. No, it is not broken for everything, but it is most definitively broken for use within the PKI infrastructure (signing certificates).

Re:No weakness (2, Interesting)

plover (150551) | more than 5 years ago | (#26269427)

Brute force? Not according to TFA:

In the interest of protecting the Internet against malicious attacks using our technique, we have omitted the critical details of our sophisticated and highly optimized method for computing MD5 collisions.

It says they compute collisions, which is indeed a weakness in MD5. Even if they use brute force, the fact that it's forceable is still a weakness.

Now, MD5 still probably makes for a pretty good checksum for utilities like Tripwire and such, but for security it's broken, broken, broken.

Re:No weakness (2, Informative)

blueg3 (192743) | more than 5 years ago | (#26269561)

Since MD5 is 128 bits, if computing a collision takes on the order of 2^128 attempts, it is indeed brute force and is not a weakness of MD5 at all. A weakness is a property that allows you to perform some undesirable action -- say, compute a collision -- faster than absolute brute force.

Re:No weakness (1)

Opportunist (166417) | more than 5 years ago | (#26269463)

Brute force isn't so terribly time consuming when you have a botnet of current PCs at your disposal that can start crunching...

Re:No weakness (3, Insightful)

moderatorrater (1095745) | more than 5 years ago | (#26269553)

This is just to head off the inevitable screaming of "MD5 is broken for everything anyway!!!".

Why head that off when it's a perfectly valid criticism? MD5's been out of date for a few years now and it's been broken for nearly that long. Using MD5 eliminates the CA's credibility.

Re:No weakness (0)

Anonymous Coward | more than 5 years ago | (#26269823)

The first part of your post is just not true. This attack is possible because of a weakness in MD5 and has very little to do with an actual bruteforce search.

That doesn't mean MD5 is broken for [b]everything[/b] else, it just means that it's broken for this specific application (and many more that work similarly).

No one should be surprised. (1)

gandhi_2 (1108023) | more than 5 years ago | (#26269249)

The fact has always been that MD5 collisions can be calculated with rainbow tables for all sorts of reasons... Why weren't all CA's using SHA-1? It's trivial enough with the openssl from apt-get.

Re:No one should be surprised. (1)

blueg3 (192743) | more than 5 years ago | (#26269631)

You have no clue what you're talking about. Rainbow tables are only useful for small inputs, and work regardless of the hashing function.

MD5 collisions have been computable, but it's only really reasonable to produce two strings with the same MD5 hash -- not to produce a single string with a given MD5 hash.

THe interwe'bs not broken (0, Troll)

Strep (956749) | more than 5 years ago | (#26269267)

What's the big deal? Just use another hash.

Enough about Kaminsky, seriously. (-1, Troll)

Anonymous Coward | more than 5 years ago | (#26269315)

Is it necessary to link or mention Kaminsky every time a new vulnerability is found? Doesn't think prima donna have enough celebrity status already?

CA's using MD5 (5, Informative)

xaosflux (917784) | more than 5 years ago | (#26269319)

FTA, the following common CA's are still using MD5.

RapidSSL
C=US, O=Equifax Secure Inc., CN=Equifax Secure Global eBusiness CA-1

FreeSSL (free trial certificates offered by RapidSSL)
C=US, ST=UT, L=Salt Lake City, O=The USERTRUST Network, OU=http://www.usertrust.com, CN=UTN-USERFirst-Network Applications

TC TrustCenter AG
C=DE, ST=Hamburg, L=Hamburg, O=TC TrustCenter for Security in Data Networks GmbH, OU=TC TrustCenter Class 3 CA/emailAddress=certificate@trustcenter.de

RSA Data Security
C=US, O=RSA Data Security, Inc., OU=Secure Server Certification Authority

Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com

verisign.co.jp
O=VeriSign Trust Network, OU=VeriSign, Inc., OU=VeriSign International Server CA - Class 3, OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign

Re:CA's using MD5 (1)

McNihil (612243) | more than 5 years ago | (#26269727)

I guess one could do this too

grep -A 1 md5WithRSAEncryption /etc/pki/tls/certs/ca-bundle.crt |grep "CN"|awk -F "CN=" {'print $2'}

which yields the following

GTE CyberTrust Root
GTE CyberTrust Global Root
Thawte Personal Basic CA/emailAddress=personal-basic@thawte.com
Thawte Personal Premium CA/emailAddress=personal-premium@thawte.com
Thawte Personal Freemail CA/emailAddress=personal-freemail@thawte.com
Thawte Server CA/emailAddress=server-certs@thawte.com
Thawte Premium Server CA/emailAddress=premium-server@thawte.com
Entrust.net Client Certification Authority
Equifax Secure Global eBusiness CA-1
Equifax Secure eBusiness CA-1
Thawte Timestamping CA
Entrust.net Secure Server Certification Authority
Entrust.net Client Certification Authority
IPS SERVIDORES/emailAddress=ips@mail.ips.es
NetLock Kozjegyzoi (Class A) Tanusitvanykiado
NetLock Uzleti (Class B) Tanusitvanykiado
NetLock Expressz (Class C) Tanusitvanykiado
Free SSL Certification Authority/emailAddress=admin@startcom.org

Can someone double check?

Re:CA's using MD5 (1)

Tony Hoyle (11698) | more than 5 years ago | (#26269745)

Find these in the browser and delete them.

*No* certificate issued by these providers is secure. If your bank uses them, then tough.. your bank has a problem and they should have bought their certificate from a competent provider.

Possible solution? (2, Insightful)

marcopo (646180) | more than 5 years ago | (#26269357)

I'm not familiar with the details of certificate use, but as far as the cryptologic component there seems to be a reasonable fix, that will not require any change from end-users or invalidate existing certificates (apart from changing the hash).

The attack is based on finding a hash collision between certificates A and B, having the CA signing A, and using the signature for B. If the CA were to make a small change to A before signing it the attack would be foiled, since it requires active participation from the CA.

Suppose the CA started to add a few random bits to each certificate before signing it. The applicant is told what these bits are, so that they can use the signed (modified) certificate to verify themselves to users. With just a few extra bits this would make the attack unfeasible. Does this make sense?

The sky is not falling. (3, Informative)

viega (564643) | more than 5 years ago | (#26269399)

A lot of people in the twitterverse seem to think otherwise, but this is not a major breakage of the Internet. See my commentary at O'Reilly: http://broadcast.oreilly.com/2008/12/the-sky-is-not-falling-on-toda.html [oreilly.com]

Re:The sky is not falling. (0)

Anonymous Coward | more than 5 years ago | (#26269583)

Thawte
C=ZA, ST=Western Cape, L=Cape Town, O=Thawte Consulting cc, OU=Certification Services Division, CN=Thawte Premium Server CA/emailAddress=premium-server@thawte.com

Is using MD5. Want to disable their CA in your browser?

Re:The sky is not falling. (1)

viega (564643) | more than 5 years ago | (#26269843)

Read the article carefully. Just because something is signed by MD5 doesn't make it broken. Signing future things with MD5 without proper randomization is bad, but I don't expect anyone other than the third tier CAs to do that kind of thing after this. I will also say that the attack will leave a pretty distinctive signature in CA logs. Plus, nobody would say "revoke Thawte's cert retroactively", but it should probably not be used anymore, and no CA certs issued with it should be accepted anymore. In fact, those issued over the last year, Thawte should publish which ones it issued separately. If browsers respected that list (a one-time thing), it would close the remaining hole (for Thawte... each CA affected would need to do the same thing).

Re:The sky is not falling. (1)

Tony Hoyle (11698) | more than 5 years ago | (#26269923)

You still seem to think the CA is involved in this. Read how the attack is done. They generate a certificate with the same MD5 as an existing CA certificate. This allows them to issue certificates as if they were signed by the CA *without the CA having any knowledge*.

It is now impossible to trust any certificate signed by CAs using MD5. If that includes thawte then tough - they're going to have to reissue all their certificates.. they should have thought of security instead of trying to cut corners.

Re:The sky is not falling. (1)

Tony Hoyle (11698) | more than 5 years ago | (#26269857)

"Therefore, the only certificates that are problems are ones where someone has already launched this attack. We know it's happened once, but that list is probably pretty small. And, there's a good shot that the bad guys haven't done it at all."

He's wrong, and has completely failed to understand the significance of this. He seems to think that it requires the CA to sign these certificates or something.

As long as there are *any* MD5 CA certificates in the browser then the bad guys can duplicate it and generate valid certificates for *any site on the internet* - including your bank. Man in the middle attacks just got a hell of a lot easier. Phishing attacks just got a hell of a lot easier.

Vulnerable CAs include Thawte and RSA, which means this is pretty damned big.

PS3 power (1)

d3l33t (1106803) | more than 5 years ago | (#26269411)

interestingly enough they used playstations to do so

A nice piece of work (5, Insightful)

Animats (122034) | more than 5 years ago | (#26269417)

That's a nice piece of work. I'm very impressed.

Practical conclusions:

  • The weakest trusted CA in the world compromises the entire public key infrastructure. What they've been able to do is not just create a phony SSL cert. They've been able to create a trusted but phony certificate authority root certificate which can be used to sign other certificates.
  • MD5 has to go. The PKI infrastructure already supports SHA-2, which is considered better; MD5 is only there for legacy certs. So an upgrade doesn't require end-user browser changes; it can all be done by CAs and web sites.
  • It's not that hard to do this attack, but it does take some resources. They used a farm of 200 Playstation 2 machines to attack MD5. This is well within the capabilities of, say, the Russian Business Network.
  • RapidSSL and FreeSSL seem to be the current weakest points in the system. "Out of the 30,000 certificates we collected, about 9,000 were signed using MD5, and 97% of those were issued by RapidSSL." Worse, those two issuers issue certs with ascending non-random serial numbers, so that, with careful timing, they can be induced to issue a cert with a known bit pattern, which is required for this attack. Probably, RapidSSL and FreeSSL's trusted root cert should be pulled from IE and Netscape, and all certs from those sources re-issued using SHA-2 hashes.
  • I don't think the RapidSSL and FreeSSL root certs are EV-enabled, so this specific attack probably can't be used to generate phony Extended Validation certs. Also, the EV standards require SHA-2 or better hashing, not MD5, which is more of a legacy hash algorithm. So the EV cert world is probably still secure.

Re:A nice piece of work (2, Informative)

Anonymous Coward | more than 5 years ago | (#26269605)

EV requires SHA-1, not SHA-2, but you're right that EV is an effective mitigation. Not all devices (e.g. phones) support SHA-2 yet but all support SHA-1.

The number of certs issued isn't very relevent; this isn't a second pre-image attack. So, RapidSSL/FreeSSL simply need to stop issuing MD5-signed certs.

Re:A nice piece of work (1)

gatekeep (122108) | more than 5 years ago | (#26269619)

"The weakest trusted CA in the world compromises the entire public key infrastructure."

That's a slight overstatement. It compromises the entire public key infrastructure for which that CA is the root of trust.

If you removed all MD5-enabled CAs from your trusted roots list, you remove the potential of being fooled by a forged cert. Certs issued by other CAs, unaffected by the brute-force MD5 collisons, remain as trustworthy as they ever were.

Granted, for most people the chain of trust ties back to the default CAs that ship with their browser, and if any of those CAs is vulnerable, your faith in any cert validated as 'trusted' by your browser goes down, and most people don't bother looking at what CA issued the cert so long as their browser deems it trustworthy, but it's a little more nuanced that 'compromises the entire PKI infrastructure.'

I suspect browser patches will be out soon, removing trust for affected CAs entirely, not trusting them past a certain date, or at least giving warnings when MD5 signature verification is found along the chain of trust.

Re:A nice piece of work (1)

gknoy (899301) | more than 5 years ago | (#26269647)

Will blacklisting the CA (locally on my machines) make any difference? (Perhaps a better question is, can I as an end-user do anything to protect myself from certificates issues from CAs that have not upgraded to better hashing?)

Re:A nice piece of work (1)

Rayban (13436) | more than 5 years ago | (#26269831)

If you blacklist all CA's that use MD5 hashes in the root, you are likely safe (unless there's an unsafe intermediate somewhere).

IMHO, this needs a browser fix to mark any certificate with MD5 in its chain as potentially untrusted.

Re:A nice piece of work (1)

ALecs (118703) | more than 5 years ago | (#26269735)

You seem to be able to disable root CAs in firefox. In "preferences" > "advanced" > "view certificates" > "authorities". FreeSSL is in there, listed as "startcom ltd". I guess we might all want to remove that now?

Insecure algorithm test tool (1)

vanbroup (1441589) | more than 5 years ago | (#26269443)

Networking4all created a tool to check if a certificate in the chain has been signed with a insecure algorithm

Example:
http://www.networking4all.com/en/support/tools/site+check/?fqdn=www.verisign.com [networking4all.com]

You can check all sites on:
http://www.networking4all.com/en/support/tools/site+check/ [networking4all.com]

Not the end of the Internet... (0)

Anonymous Coward | more than 5 years ago | (#26269457)

If I understand correctly, it's only a problem for certificates that use only a MD5 fingerprint. For two of the CAs they mention in their paper as doing this, it doesn't seem to be the case: Amazon Germany [amazon.de] (certificate from Thawte) and Commerzbank [commerzbanking.de] (from TrustCenter) have both MD5 and SHA-1 fingerprints. Good luck generating a rogue certificate that generates a collision in both fingerprints...

I would assume all recent certificates have both fingerprints. Anyway, making sure that the certificate you just got from your online banking site has both fingerprints wouldn't be paranoia anymore...

Re:Not the end of the Internet... (1)

Rayban (13436) | more than 5 years ago | (#26269821)

It's a problem for all websites. All you need to do is forge a certificate from Amazon that uses MD5 and redirect someone's browser via Wifi hacking or DNS redirection.

The browser doesn't know that Amazon didn't use Verisign's busted MD5 cert root.

Rouge certificates are bad? (1)

frank_adrian314159 (469671) | more than 5 years ago | (#26269523)

OK, that's it! I'll only accept chartreuse and lavender certificates from now on. Maybe ivory, too.

Maybe a Firefox config setting (2, Interesting)

McNihil (612243) | more than 5 years ago | (#26269851)

Wouldn't setting security.ssl3.rsa_rc4_128_md5 to false prohibit these kind of attacks?

Rouge students and some more insight (3, Informative)

owlstead (636356) | more than 5 years ago | (#26269855)

Strange bunch of hackers. Don't expect some rouge students here, one is Arjen Lenstra, which is a well known figure in the security scene.

Very interesting to see that not only do they issue certificates using MD5 signatures (a very stupid thing to do) but they haven't even bothered to make sure that only leaf certificates can be issued. Or there are probably other CA certificates already issued under these root CA's, making matters even worse.

The article was very well written and thus easy to read. I'm only concerned about the recommendation of the authors to do nothing if you've been issued an MD5 certificate yourself. Doing nothing does not seem to be a very good advice. I would myself go to another shop and get a SHA-1 signed certificate (or even a SHA-2 signed certificate for those not concerned with low level browsers). At least your customers will know that there is no man in the middle due to the MD5 issue, and you show that you care for your clients' security.

Hopefully SHA-1 will hold up a bit longer, because last time I looked (a year ago or somewhere in that order), there were zero (0!) certificates that were self signed using SHA-2, which is not a good indication of the current state at all.

Gosh, that's the second CA I've disabled within Firefox just this week. Interesting times.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

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>
Create a Slashdot Account

Loading...