Forgot your password?
typodupeerror
Security The Internet

CCC Create a Rogue CA Certificate 300

Posted by CmdrTaco
from the they-even-faked-this-dept dept.
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."
This discussion has been archived. No new comments can be posted.

CCC Create a Rogue CA Certificate

Comments Filter:
  • by Anonymous Coward on Tuesday December 30, 2008 @01:17PM (#26269065)

    Let's go make a new one.

    • by plover (150551) * on Tuesday December 30, 2008 @01:54PM (#26269451) Homepage Journal
      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?
      • by Alrescha (50745) on Tuesday December 30, 2008 @02:16PM (#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: (Score:3, Insightful)

        by PAjamian (679137)

        If you RTFA you'll note that there is only one known CA that is really vulnerable to this attack, RapidSSL (and also FreeSSL which is part of RapidSSL). This is due to the necessary timing of the validity period and the sequential serial numbers used by the CA.

        Also of note is that it doesn't matter what encryption was used to sign the root cert, what matters is the type of encryption that the vulnerable CA uses to sign *your* cert. The CA's certificate could be signed with MD5, SHA1 or anything, really.

    • Re: (Score:3, Funny)

      by neoform (551705)

      Will there be blackjack and hookers?

  • Rouge CA? (Score:5, Funny)

    by realmolo (574068) on Tuesday December 30, 2008 @01:19PM (#26269097)

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

    It's ROGUE you dumbass.

  • by TypoNAM (695420) on Tuesday December 30, 2008 @01:22PM (#26269117)

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

    • by DoofusOfDeath (636671) on Tuesday December 30, 2008 @01:30PM (#26269197)

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

      Hold on - I'll check the signature.

    • by TypoNAM (695420) on Tuesday December 30, 2008 @01:34PM (#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? ;)
  • Rouge CA? (Score:3, Funny)

    by Bert64 (520050) <bert AT slashdot DOT firenzee DOT com> on Tuesday December 30, 2008 @01:23PM (#26269129) Homepage

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

  • Why trust the PKI? (Score:5, Interesting)

    by characterZer0 (138196) on Tuesday December 30, 2008 @01:23PM (#26269131)

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

    • by nurb432 (527695)

      Or a usb key :)

    • Re: (Score:3, Interesting)

      by Nursie (632944)

      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.

      • by Nursie (632944)

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

        • by conspirator57 (1123519) on Tuesday December 30, 2008 @03:44PM (#26270611)

          note that the collision attack requires a bit of junk in the cert to make the hash be the same as for the original... this means the junk will not look like the rest of the cert. the rest of the cert is formatted and the collision noise will look mostly random. a simple test for unexpected randomness in the cert data (including Netscape comments) would reveal this sort of mischief. it just takes a bit of code on the browser to look for it. shouldn't even degrade browsing performance too much.

    • by fastest fascist (1086001) on Tuesday December 30, 2008 @01:40PM (#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: (Score:3, Interesting)

        by Mister Whirly (964219)
        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: (Score:3, Insightful)

          by characterZer0 (138196)

          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.

          • 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

            • I follow the same guidelines, but unfortunately, we are in the minority when it comes to things such as this.
          • Re: (Score:3, Insightful)

            by Mister Whirly (964219)
            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: (Score:3, Insightful)

            by horatio (127595)

            This is exactly what I do. When a bank or CC issuer calls (usually to verify a purchase) I call the number listed on the back of the card, not the number left in the message.

        • 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...
      • by blhack (921171)

        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?

      • by Burz (138833) on Tuesday December 30, 2008 @02:18PM (#26269643) Journal

        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: (Score:3, Insightful)

          by aj50 (789101)

          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.

          If the certificate is imported into the browser as a trusted certificate you don't get the warning, that's the point.

          The invalid warnings ar

          • Re: (Score:3, Insightful)

            by Burz (138833)

            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.

            If the certificate is imported into the browser as a trusted certificate you don't get the warning, that's the point.

            The invalid warnings are for when the certificate has been sent over an untrusted connection and you have no assurance that the certificate is the correct one for the site. In this case, flashing a huge warning in the user's face is absolutely the right thing to do since at the moment, all legitimate online shops have a certificate verified by a third party.

            Huge warning Yes; Incorrectly-worded warning that passes judgment on the cert before the user even wonders if it can be verified... NO.

            The old behavior used a big warning without condemning the cert. Unfortunately it gave the used an option to just accept the cert and make a connect without even viewing it.

            The correct change to make IMO would be to remove the "Continue" button and instead force the user to import the cert before continuing with a connection. Then the certs would be handled more like SSH key

    • by plover (150551) *

      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.)

    • by wsanders (114993)

      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.

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

  • by Yvanhoe (564877) on Tuesday December 30, 2008 @01:24PM (#26269141) Journal
    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: (Score:3, Informative)

      by Opportunist (166417)

      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?

    • 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 ef
  • by johnjones (14274) on Tuesday December 30, 2008 @01:25PM (#26269153) Homepage Journal

    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]

    • by gclef (96311) on Tuesday December 30, 2008 @01:44PM (#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

      • by Tony Hoyle (11698) *

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

    • by perp (114928) on Tuesday December 30, 2008 @01:54PM (#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.
      • Ouch.

      • Re: (Score:3, Informative)

        by SpaceLifeForm (228190)

        And that is what was done.

        Link [wired.com]

        A powerful digital certificate that can be used to forge the identity of any website on the internet is in the hands of in international band of security researchers, thanks to a sophisticated attack on the ailing MD5 hash algorithm, a slip-up by Verisign, and about 200 PlayStation 3s.

        "We can impersonate Amazon.com and you won't notice," says David Molnar, a computer science PhD candidate at UC Berkeley. "The padlock will be there and everything will look like it's a perfe

  • No weakness (Score:2, Informative)

    by GigsVT (208848)

    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: (Score:2, Informative)

      by Anonymous Coward

      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.

    • 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

    • Re: (Score:3, Interesting)

      by plover (150551) *

      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: (Score:3, Informative)

        by blueg3 (192743)

        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: (Score:3, Informative)

          by amorsen (7485)

          If computing a collision takes on the order of 2^128 attempts, it won't happen. Anyway, you can make a collision of a 128-bit hash in 2^64 attempts, but even that is out of the reach for most people. Unfortunately you can generate collisions for MD5 much much faster than 2^64 operations.

    • 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 (Score:4, Informative)

        by SanityInAnarchy (655584) <ninja@slaphack.com> on Tuesday December 30, 2008 @04:00PM (#26270813) Journal

        Actually, yes it is. You just need a strong enough cipher.

        The way I understand it, for example, 4096-bit RSA either requires a dramatically new approach (quantum computing), or, with current technologies, requires every atom in the Universe to be assembled into a massive compute cluster, and that cluster needs to run for longer than the heat death of the Universe.

        Botnets do change some things, but they don't change basic mathematics.

    • Re:No weakness (Score:4, Insightful)

      by moderatorrater (1095745) on Tuesday December 30, 2008 @02:06PM (#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.

  • 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.
    • by blueg3 (192743)

      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.

  • CA's using MD5 (Score:5, Informative)

    by xaosflux (917784) on Tuesday December 30, 2008 @01:40PM (#26269319) Homepage

    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

    • by Tony Hoyle (11698) *

      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? (Score:2, Insightful)

    by marcopo (646180)

    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 f

  • by viega (564643) <viega.list@org> on Tuesday December 30, 2008 @01:50PM (#26269399) Homepage
    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]
    • by Tony Hoyle (11698) *

      "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 genera

      • by viega (564643)
        You're wrong. Read the attack author's write-up here: http://www.win.tue.nl/hashclash/rogue-ca/ [win.tue.nl] You will see that they absolutely need to get the CA to endorse the data they produce. They come up with two certificates in advance that, under the right conditions, will both validate when one of them is signed via MD5. That means, you cannot take an arbitrary cert on the internet and feasibly come up with an identical cert that is malicious, where the same signature applies.
    • I think in your article you got this wrong. "That kind of attack doesn't seem like it's going to be practical in the next few years, though we should expect it will be possible sooner than later (developers: stop using MD5. Switch to something in the SHA family)."
      The CCC guys already created a CA cert with which they can sign any cert for any host they want. That cert, signed by that forged CA cert, will look legitimate to the client browser, because it looks like it is signed by a trusted CA. So, yes: the

  • by Animats (122034) on Tuesday December 30, 2008 @01:52PM (#26269417) Homepage

    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: (Score:2, Informative)

      by Anonymous Coward

      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.

      • by Tony Hoyle (11698) *

        No, RapidSSL/FreeSSL need to remove their MD5 CA from the trusted list. Merely stopping issuing new certs is not going to do anything - the entire trust chain is compromised until *all* MD5 CAs are removed from the trusted list. In practical terms that means they need to reissue all certs based on the old CA.

    • by gatekeep (122108)

      "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 defa

    • by gknoy (899301)

      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?)

      • by Rayban (13436) *

        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.

        • by blueg3 (192743)

          What matters is not what hash is used in the root, but what algorithm newly-issued certificates can be hashed with. If the CA can be convinced to issue a certificate hashed with MD5, then it is susceptible to this attack. If newly-issued certs must use SHA1 or better, than it is not susceptible, even if the root certificate is hashed with MD5.

          (Moreover, one could imagine that there is a root cert signed with SHA1, but the CA issues MD5-signed certs. This would also be vulnerable.)

          Fortunately -- and not at a

    • by ALecs (118703)

      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?

    • Good conclusions. You write that RapidSSL and FreeSSL should be pulled from IE and Netscape.

      Interesting point about this is, that there is only approx 30 Trusted CA:s in Windows Vista. Compared to how many in XP? 80-100 or so?

      Seems that some have already been pulled?

    • by owlstead (636356)

      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.

      Almost correct, it is in fact an intermediate CA certificate. This can be used for certificate trees of 3 certificates in depth (or more). Of course, creating a "root CA" has very little effect, since you will have to include it into the secure store of the browser if you do.

      Otherwise you are right on the money. It certainly won't matter to the end user what kind of certificate it is, root or intermediate.

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

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

  • by owlstead (636356) on Tuesday December 30, 2008 @02:39PM (#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.

    • 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.

      You can't really do anything about it. A man in the middle attack will always be possible. They generated a CA certificate, and with that cert they can sign self generated certs for every host they want, and the client browser will trust it. You, as a site owner, can't do anything about it. The attacker can spoof the dns response for www.bank.com, redirect the client to his own box with his own web server and valid certificate for www.bank.com and get all data the client sends him. As I sad, www.bank.com is

    • Re: (Score:3, Insightful)

      by gclef (96311)

      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.

      Unfortunately, no, they won't. An MD-5 signed intermediate cert can quite happily issue certs signed with SHA-1. (They did just this as part of their testing.) There's no requirement for the signing chain to be signed with the same algorithm.

      The fact that your end certificate is SHA-1 signed really doesn't mean anything to the end user. If your cert is MD-5 signed, all that could possibly mean is that your CA at one time did something stupid. Whether it is still doing that stupid thing (or already did

  • what's a rouge certificate - why does the colour matter? ah, I see, maybe the OP mean a rogue certificate!
  • To the hell with backward compatibility. Browsers should already have stoped accepting MD5 signatures by 2004. It was broken by that time, the fact that there was no known exploit did not make it any less bad. By that time people aready used alternatives and tought it would be broken soon, so why did CAs wait?

    I hope that, now, the main browsers stop accepting it, and with all that noise about the way Firefox handles certificates, I hope it moves soon. Too bad we have IE6 that probably won't receive any kind

Help stamp out Mickey-Mouse computer interfaces -- Menus are for Restaurants!

Working...