Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

Perfect MITM Attacks With No-Check SSL Certs 300

StartCom writes "In a previous article I reported about Man-In-The-Middle attacks and spotlighted an example showing that they really happen. MITM attacks just got easier. In the attack described previously, untrusted certificates from an unknown issuer were used. Want to make the attack perfect with no error and a fully trusted certificate? No problem, just head over to one of Comodo's resellers. Screenshots and disclosure provided at the link."
This discussion has been archived. No new comments can be posted.

Perfect MITM Attacks With No-Check SSL Certs

Comments Filter:
  • by moro_666 ( 414422 ) <kulminaator@ g m a i l.com> on Tuesday December 23, 2008 @08:12AM (#26210627) Homepage

    While the link is already being slashdotted ...

    I hope the article author understands that unless he's really lucky, he is in deep legal trouble already. It's not the first time that the messenger was slaughtered, although the message was honorable.

    Gotta think over the SSL certs one more. I never really liked the mechanism behind it, i like it even less now.

    • by Anonymous Coward on Tuesday December 23, 2008 @08:25AM (#26210697)

      source of the slashdotted page :

      ----
      In a previous article I reported about Man-In-The-Middle (MITM) attacks and if they really happen. Unfortunately it does happen as some testimonials confirm. Now itâ(TM)s even easier because in the attack described previously, untrusted certificates from an unknown issuer were used. Want to make the attack perfect with no error and fully trusted certificate? No problem, just head over to one of Comodoâ(TM)s resellers.

      In an unrelated event which was briefly mentioned at the dev.tech.crypto mailing list of Mozilla, something strange happened. During my attempt to verify and understand who stands behind the sending of fraudulent âoereminderâ email messages tricking our customers, I created a certificate from the source I was following. And my certificate was issued without any further questions.

      This prompted me to create another certificate through them, but this time by using a domain name which should never be issued to me. For the purpose of testing, I selected the domain mozilla.com (Iâ(TM)m certain they will forgive me). Five minutes later I was in the possession of a legitimate certificate issued to mozilla.com - no questions asked - no verification checks done - no control validation - no subscriber agreement presented, nothing.

      With the understanding about MITM attacks, the severity of this practice is obvious. No encryption is worth anything if an attacker can implant himself between the client and the server. With a completely legitimate and trusted certificate, the attack is perfect. No warning and no error.

      --
      there you go, have a nice xmas and slashdot less

      • by cp.tar ( 871488 ) <cp.tar.bz2@gmail.com> on Tuesday December 23, 2008 @08:37AM (#26210795) Journal

        Oh, dear. So who certifies the certifiers?

        • Re: (Score:3, Insightful)

          by jonbryce ( 703250 )

          The suppliers of web browsers - Microsoft, Mozilla, Opera, Apple (Safari), KDE (Konqueror), Google (Chrome).

          • by TheLink ( 130905 ) on Tuesday December 23, 2008 @09:42AM (#26211327) Journal

            And they don't care about security (nor do the users).

            That's why self-signed certs aren't really more risky than CA signed certs in practice.

            http://it.slashdot.org/comments.pl?sid=1041927&cid=25890305 [slashdot.org]

            http://ask.slashdot.org/comments.pl?sid=534356&cid=23199022 [slashdot.org]

            I've probably posted others, but I bet "everyone" is still going to leave the dozens of CA certs in their browsers, and Mozilla and friends aren't going to do the SSH style thing - warn user if the cert changes for whatever reason- even if it's a valid cert.

            I'd like to know if my bank's cert suddenly changed from the old cert to some cert signed by some CA in Elbonia. :)

            • by mpe ( 36238 ) on Tuesday December 23, 2008 @10:09AM (#26211583)
              I've probably posted others, but I bet "everyone" is still going to leave the dozens of CA certs in their browsers, and Mozilla and friends aren't going to do the SSH style thing - warn user if the cert changes for whatever reason

              Which would be the most sensible thing. Especially if the old certificate was nowhere near due to expire and the details on the new one are very different.

              even if it's a valid cert.

              "Valid" in this context meaning somehow connected to a CA trusted by the browser. Which in this kind of case may be less trustworthy than a self signed certificate. But guess which one Firefox 3 is going to make a song and dance about...
              • Re: (Score:3, Insightful)

                by u38cg ( 607297 )
                The problem is the economic incentives. Do the roots have an economic incentive to verify all the parties it certifies? No, they have an incentive to sell as many certificates as possible. Browsers should not include certificates and users should pay for a subscription to a certificate authority *they* choose to trust. That would put the incentive boot on the other foot.
            • by tjstork ( 137384 ) <todd.bandrowskyNO@SPAMgmail.com> on Tuesday December 23, 2008 @01:16PM (#26213879) Homepage Journal

              The company that I worked at used a MITM attack with self signed certificates to read everyone's HTTPS stuff during the financial crisis. I was quite surprised to find that my bank and my broker's certificates were rejected by my Firefox, and that, upon inspection, the issuer was actually my company. IE, company issued, didn't warn me, and neither did Chrome, and I have to confess that when Firefox complained, I would often switch to Chrome, because it didn't. Then, one day I looked at the certificate in Firefox, and I discovered just what that warning meant. My company was spying on me.

            • by starfishsystems ( 834319 ) on Tuesday December 23, 2008 @01:50PM (#26214357) Homepage
              That's why self-signed certs aren't really more risky than CA signed certs in practice.

              I made a variation of this point to management where I worked a couple of years ago. My purpose was to promote the idea of building a corporate PKI rooted in our own Certificate Authority. You can think of this as a self-signed cert with structure.

              The initiative had particular value for us because we deploy and remotely manage a large population of network appliances at customer sites. It's far more efficient for a web client to install a single CA cert than to request trust for each of the hundreds of server certs individually. Moreover, if a rogue cert ever does pop up, the chain will not silently resolve to our CA cert. (It might, as the article points out, resolve to some careless CA, whose reputation, I hope, will diminish accordingly. But I wasn't trying to improve certificate practices worldwide.)

              Anyway, management was fine with the part about server authentication for our internal operations. Management was much more hesitant about giving out our CA cert to customers and partners in order to connect to our portals.

              Why? The answer, as best I could understand, was the risk of a perception by customers that installing our CA cert would somehow weaken the security of their browsers. And so, because of this perception, we instead sent cert requests to a commercial CA, which as far as I can tell performed no verification whatever on the requests, apart from billing for whatever that may be worth. This was for the "industrial grade" certs, no less, the ones which were supposed to trigger identity checks on the requestor.

              So it seems that perception trumps reality just as commercial CAs would wish in their wildest dreams. A CA cert explicitly given to you out of band by a known entity is perceived as less strong than a preinstalled CA cert from a completely unknown entity with questionable practices. Hmm. We have a way to go.
          • no, they only trust the root certificate authorities, who in turn trust their partners, who in turn trust their resellers, who in turn trust their friends, who in turn trusts Vladimir 'the violator' Ilvymich.

            So, how long before someone buys a Microsoft.com certificate and supplies some critical 'updates'?

          • Re: (Score:3, Interesting)

            by Rich0 ( 548339 )

            I've been following the mozilla cacert bug for years. They've held off on including them as a trusted root because they haven't passed an expensive audit. However, their automated checks at least ensure that you have control of the domain that you're requesting a certificate for.

            I've always thought that this would be a good approach for issuing free or dirt cheap certificates: When somebody applies for a certificate they are given some file to serve up from their webroot. Every week for three weeks a ne

        • Re: (Score:3, Funny)

          by Anonymous Coward

          I have a much bigger concern. Who certifies those who certify the certifiers?

        • by iammani ( 1392285 ) on Tuesday December 23, 2008 @09:34AM (#26211253)

          Folks who are surprised should definitely check out the list of Certificate Authorities. In Firefox Prefences -> Advanced -> Encryption -> View Certificates -> Authorities Tab

          The first one is TÃoeRKTRUST Elektronik Sertifika HizmetSaÄYlayıcısı.

          And its much worse in IE -- Internet Option-> Certificates -> Trusted Root Cert. Autho. I have not heard of 25% of the Authorities.

          As the wise put it, security is only as strong as the weakest link.

          • by Kadin2048 ( 468275 ) <slashdot...kadin@@@xoxy...net> on Tuesday December 23, 2008 @03:35PM (#26215779) Homepage Journal

            Well, I have to admit I was surprised. I hadn't looked at the list of CAs in a while; it seems like the last time I went in there, it only had a handful of entries in it. (Verisign, Thawte, maybe a couple of others.)

            I'm giving some very serious thought right now to just deleting every company on that list that I haven't heard of, or that I don't think has enough of a profile to be seriously harmed by allegations of sloppy issuing. Although from some other comments in the thread it sounds like even the big-name CAs have been lazy for years and haven't gotten called on it.

            Having a bunch of Turkish CAs in my trusted root doesn't seem like it adds much in the way of security; the chances of me accessing a site that's legitimately using a cert from them -- near zero -- seems significantly lower than someone taking advantage of them to create a fake cert for my bank. (Not necessarily because their security is worse than a US-based CA, but just because while there's a chance someone at the US CA might have heard of my bank and think that it's funny someone's requesting a CA from their domain, I doubt anyone at the Turkish CA would have heard of it. If I were going to get a forged cert, I'd definitely go to a CA where they'd be unfamiliar with the target, just to stack the odds that much more in my favor. So it would seem that only having "local" CAs, ones you're likely to encounter legitimate certs from, in your trust chain is probably a good idea. Someone in Turkey might want to get rid of the minor US certifiers if they don't use them, too.)

            Perhaps at some point during the browser-installation process, users should be prompted to select what countries, regions, or jurisdictions they're interested in installing CA certs for. The question could be phrased as "in what countries do you regularly do e-business or use secure web sites?" or something similar. Sure, this would eliminate much of the international market for CAs -- US-based ebusiness sites couldn't shop around for certificates quite as much as they perhaps do now, and vice versa -- but I think that would be significantly better than allowing the whole idea of certificates to be undermined into uselessness.

            Of course, maybe that's just rearranging the deck chairs on the Titanic, and the safest thing to do is just throw away the whole paid Certificate Authority concept, blow away all the preinstalled CAs, and then have users build up trust on a per-site basis. This assumes users won't be stupid about what they accept, though, so it's probably doomed from the start.

        • Actually, the certifiers should be setup to police themselves. Make it public that any verify that screws up gets dropped from your browser. Giving incentive for verisign or comodo to try to compromise their competitors.

    • by Timothy Brownawell ( 627747 ) <tbrownaw@prjek.net> on Tuesday December 23, 2008 @08:35AM (#26210779) Homepage Journal

      Gotta think over the SSL certs one more. I never really liked the mechanism behind it, i like it even less now.

      The current mechanism is that the site owner pays a particular CA to identify them, and end-users/browsers trust any CA to identify any site (they can't know which CA the site owner actually paid). Site owners (the ones paying the bills) have no incentive to demand that the CA be competent.

      A better system would have the end-user pay someone they trust to identify the site; they are directly paying for the identification service and can take their business elsewhere if they get crap service. This would also mean that the site owners don't have to pay someone who, really, can't actually provide any assurances to the end-users (because all CA-signed certs are treated the same). Better to just have everyone go self-signed, and then let someone (paid by the end-users) keep records of who used what cert when as seen by what network routes.

      Mapping to real-world identities is a separate issue (only provided by "extended validation" or whatever certs due to browser UI issues), and is (1) rather expensive because you need people involved to look at paperwork and such and (2) mostly isn't needed, because you'll generally find IRL groups' sites by communication from those groups (eg, my electric bill has the electric company's URL printed on it, I don't need to look them up in google and then verify that I got pointed to the right place).

      • (they can't know which CA the site owner actually paid)

        Isn't that what the 'issued by' field is for in a certificate?

        • (they can't know which CA the site owner actually paid)

          Isn't that what the 'issued by' field is for in a certificate?

          No, that says which CA issues that particular cert. Which may not be the same CA that the site owner paid, for example if I pay Verisign for a cert for my site and when you visit you get a cert from "one of Comodo's resellers", you really have no way to know that I didn't buy a cert from them and you shouldn't trust it.

          • Re: (Score:3, Informative)

            by Nursie ( 632944 )

            Unless you've already decided that you don't trust Comodo, for this reason, and have struck them from your list of trusted authorities.

        • Most people just look for the padlock. Do they even know how to inspect a certificate?

      • by Anonymous Coward on Tuesday December 23, 2008 @08:59AM (#26210955)

        Pesronally I'd like VISA and Mastercard to give me Root CA certs to use for purchasing on line - then if they foul up and someone gets a dodgy cert then they pick up the bill.

        As it is, I don't think anyone would be liable (except yourself) to pick up the cost of shenanigans

        • Pesronally I'd like VISA and Mastercard to give me Root CA certs to use for purchasing on line - then if they foul up and someone gets a dodgy cert then they pick up the bill.

          Hey, I like that idea. But it would need a way for the site to have multiple certificates where the user chooses which one they want (does SSL/TLS permit this?), and support for this in the browser UI... I suppose the root cert would probably come on a mini-CD or USB stick when they mail your card.

        • Re: (Score:3, Informative)

          As it is, I don't think anyone would be liable (except yourself) to pick up the cost of shenanigans

          It depends on the country. Two friends of mine were mugged, and their wallets stolen. The one with a US credit card made a call, got the charges reversed, and a new card in the mail. No pain. My other friend from South America was on the hook for the thousands of USD that the crooks rang up, and couldn't even cancel it until the next morning.

      • by betterunixthanunix ( 980855 ) on Tuesday December 23, 2008 @09:01AM (#26210985)
        The problem with the system you described is that it relies on end users to understand what is happening. Most FF or IE users have no understanding of what a certificate even is, how it works, or how a MITM attack works. If you told end users that they would pay for identification services, every scam artist on earth would be setting up their own CA and charging users for the root signing certificate, which would then be used for MITM attacks. Worse, the idea that end users could try and verify self-signed certificates is preposterous also, and again, scam artists would be all over it.

        From a security standpoint, the current system is pretty much the best you can hope for. People who presumably know what they are doing select your CA roots for you; a mistake there is equivalent to a buffer overflow that allows an attacker to install a key logger. The CAs, wishing to remain in business, have an incentive to do some level of checking on who they issue certificates to: if it became known that a CA was just signing any CSR, with no checks whatsoever, software makers would stop shipping their public key, and legitimate users would not pay for a signature. This, by the way, is the incentive for site owners to buy signatures from competent CAs: an incompetent CA is likely to not have their public key shipped with popular software, so their signatures are worthless.

        It's not common for a CA public key to be removed from a software package, because of the ruckus it would create (potentially thousands of websites suddenly having untrusted certificates), but if a CA has truly incompetent practices, then yes, their public key will be removed. In general, software makers try to hold CAs to high standards to get their public key shipped with the software in the first place, so unless the CA itself allows its practices to worsen, it is unlikely that they would find themselves in that position.

        Trusting a third party for security is tough, but if you are smart enough to be aware of that, then you should also be aware that you can personally add or remove CA public keys from any software that you use. If you feel that Comodo is untrustworthy, remove their public key, and every time you get a warning, report it to the owner of the website you were trying to visit.
        • Re: (Score:3, Insightful)

          by Ed Avis ( 5917 )

          if a CA has truly incompetent practices, then yes, their public key will be removed.

          Clearly not the case, since Comodo is still trusted.

          The browser maker (or someone else - the government security agency?) would need a team of people constantly testing the certificate issuers, trying every ruse possible to get bogus certificates issued. If any issuer fell for it then they would be struck off the list of trusted issuers (and the updated list would be pushed out as a security update). I don't see this happe

      • by Bert64 ( 520050 )

        They really should use self signed certs for things like banks, and provide you a copy of the root cert in the branch so you can be certain the two match up... No third party involved.


      • Site owners (the ones paying the bills) have no incentive to demand that the CA be competent.

        What do you mean they have no incentive for competent CA's? They have every incentive, since without competent CAs the security of the system will collapse. The site owner presumably cares about the security of the communication. If they didn't, why use SSL at all?

        The real problem with the current system is that ALL the common CA's have to be trusted, not just some or one. A better system would involve only the

        • by Kjella ( 173770 )

          What do you mean they have no incentive for competent CA's? They have every incentive, since without competent CAs the security of the system will collapse. The site owner presumably cares about the security of the communication. If they didn't, why use SSL at all?

          As a system, yes. Individually, no way. They want the cheapest CA = the one cutting the most corners that doesn't throw a nasty warning when visited by their customers. If people lose faith in the padlock, all the site owners are equally screwed no matter who they bought their cert from.

        • What do you mean they have no incentive for competent CA's?

          The security of my site's users doesn't depend on the competence of whichever CA I choose, it depends on the competence of the least competent CA trusted by their browser. So there's no incentive for me to pay extra for a more competent CA, because their competence (or lack thereof) doesn't really affect anything.

          A better system would involve only the CA who the site owner contracted with has to be trusted for that sites security.

          I don't think that's possible, how do you know which CA that is?


          • So there's no incentive for me to pay extra for a more competent CA, because their competence (or lack thereof) doesn't really affect anything.

            This is true. My point is really that shifting the burden of proof from one entity to the other doesn't really address the real problem. The problem isn't that one party has more interest in security than the other (sometimes true, sometimes not), it's that the weakest CA ruins it for everyone else.


            I don't think that's possible, how do you know which CA that is?

            Wit

            • My point is really that shifting the burden of proof from one entity to the other doesn't really address the real problem. The problem isn't that one party has more interest in security than the other (sometimes true, sometimes not), it's that the weakest CA ruins it for everyone else.

              So make it so that you don't need multiple authorities, or can use multiple authorities with AND instead of OR for combining individual results. The way to do this is to make there be only one business relationship, end-user <-> verifier. The verifier can check that a site consistenly presents the same cert across time and network paths, and does not need a relationship with the site owner to do this. If a verifier proves to be incompetent, there's no collateral damage from dropping them. I can use mu


              • be only one business relationship, end-user verifier.

                So how does the end-user know they're talking to the verifier, and not a MITM?

      • by mpe ( 36238 )
        The current mechanism is that the site owner pays a particular CA to identify them,

        There are plenty of situations where the CA couldn't do much in the way of verification in the first place. e.g. they are separated by several thousand miles.

        and end-users/browsers trust any CA to identify any site (they can't know which CA the site owner actually paid).

        Which is another weakness in the scheme as it now stands.

        Mapping to real-world identities is a separate issue (only provided by "extended validation"
    • by Anonymous Coward on Tuesday December 23, 2008 @08:37AM (#26210793)

      There's only one way the CA system can work: Responsibility and repercussions. If a certificate authority signs forged certificates, then it can no longer be trusted and must be removed from the list of trusted CAs. To trust an untrustworthy CA is a security bug and should trigger updates from all browser developers which remove the offending CA. Make the CAs work for their money.

      • The problem with that is IE.

        Suppose Mozilla, Google, Apple, Gnome, The KDE Team, and Opera all remove untrustworthy CAs from their browsers.

        Microsoft can leave the untrustworthy CAs in IE, and there are automatically a bunch of sites that are, for most users, IE only.

        • by glop ( 181086 )

          Maybe they could display a warning for that CA.
          Or just go to the CA, tell them they need to do a better job or 20% of the web users will see a message saying : "this website has obtained a certificate from CA XXX which has very poor security checks".
          Of course, such an update would make good headlines for the New York Times and others, so the CA could not take the risk of ignoring the threat. They would need to address the issue to avoid the bad press.

          • Re: (Score:3, Insightful)

            by bunratty ( 545641 )
            Telling them to do a better job now does no good if they've been issuing valid certificates to bad guys already. If they were not doing the proper validation of individuals who were requesting certificates, we need to consider all certificates issued by that CA to be untrusted.
            • by Nursie ( 632944 )

              Perhaps.

              Or perhaps they need to get their CRL in order, which is the mechanism for dealing with certificates that have been revoked or compromised.

            • Re: (Score:3, Insightful)

              by Kent Recal ( 714863 )

              So, who will step forward and remove such authorities from the CA list? Mozilla? Opera? Microsoft even?

              Something tells me that no one will and nothing will happen. The dust will settle, the offending CA will, at best, adjust their practices slightly but not effectively - and within 6 months we'll see more CAs pop up left and right using the same broken procedures.

              There's just too much money involved in this game. Owning a CA authority is effectively a license to print money and the beancounters everywher

        • Re: (Score:2, Insightful)

          by maxume ( 22995 )

          As a user of Firefox, that's fine with me (the entire point of the certificate system is to provide security; in that context, features and convenience are lower priorities than actually providing security).

          Basically, my neighbor's paper house is not a good reason for me to leave my doors unlocked.

      • If a certificate authority signs forged certificates, then it can no longer be trusted and must be removed from the list of trusted CAs.

        That just moves the problem one rung up the ladder. How can we trust that the list of trusted CAs is valid and up to date? Who maintains this list? Me? You? The Scam Artists? A central trust agency? The Government?
        • Re: (Score:3, Informative)

          by bunratty ( 545641 )
          Microsoft maintains the list for IE. Mozilla maintains the list for Firefox. And so on. Use a browser from a company you can trust, or you may just regret it one day.
        • Plus, decertifying a CA would nuke thousands of websites that did nothing wrong; even for this lax CA I'm sure most of the companies registered there are legit.
        • by timeOday ( 582209 ) on Tuesday December 23, 2008 @09:40AM (#26211311)

          How can we trust that the list of trusted CAs is valid and up to date? Who maintains this list? Me? You? The Scam Artists? A central trust agency? The Government?

          Go ahead and accuse me of not being libertarian, but yes, I think making and enforcing standards for CAs is a good role for the government. I would never put my money in an unregulated bank, or send premiums to an unregulated insurer, or go to a back-alley doctor.

          • by Vellmont ( 569020 ) on Tuesday December 23, 2008 @09:55AM (#26211457) Homepage


            but yes, I think making and enforcing standards for CAs is a good role for the government.

            Which "the government" are you talking about here? You might have noticed the internet is worldwide, and there's no single authority to control it. Browser makers are also free to put whatever CA's root certificates in their browsers that they wish (along with all anyone else who distributes software that uses an x509 certificate).

            • Actually I don't think that's such a huge problem. For me, anyways, my bank web access and (almost?) all my online purchases are still from here in the US. Sending my credit card number overseas is not something I do very casually, regardless of anything to do with ssl.
            • Re: (Score:3, Funny)

              by dubbreak ( 623656 )

              but yes, I think making and enforcing standards for CAs is a good role for the government.

              Which "the government" are you talking about here? ...

              I nominate Canada. They seem to be a respected world power. Everyone will be willing to listen to them.

    • by Nursie ( 632944 )

      What's wrong with the mechanism?

      The problem (IMHO) is that the implementation is sucky and too many roots are put into browsers by default.

      The actual mechanism works really really well, but you have to make sure you restrict your circle of trusted roots to orgs you *really* trust, for anything that's at all important.


    • I hope the article author understands that unless he's really lucky, he is in deep legal trouble already.

      How? Was someone defrauded? Was their money lost? Was someone unjustly damaged? I just don't see the law broken here.

      From what I can tell, what happened is the author found a way to get a signed SSL cert from a CA for mozilla.org. He doesn't mention that he tried to pass it to anyone, or even released the cert to anyone. The only party that might claim injury is the CA, and if they're smart they'll

  • Really now. (Score:5, Funny)

    by cp.tar ( 871488 ) <cp.tar.bz2@gmail.com> on Tuesday December 23, 2008 @08:21AM (#26210667) Journal

    The example cited is "RESOLVED INVALID". The link to the "perfect attack" seems to be slashdotted. And at the time I started writing this comment, there have been no comments whatsoever.

    Does this mean that Slashdotters have all swarmed the link trying to find out how to execute the perfect attack? Are we seeing a new trend here, with people actually reading TFAs?

    Or is it that too many people have Greasemonkey scripts filtering out kdawson's posts?

    • by ghmh ( 73679 ) on Tuesday December 23, 2008 @08:26AM (#26210711)
      Apparently the perfect attack is actually 'Slashdot in the Middle'
    • Re:Really now. (Score:5, Insightful)

      by daveewart ( 66895 ) on Tuesday December 23, 2008 @08:27AM (#26210719)

      The example cited is "RESOLVED INVALID"

      That's because the behaviour reported in the bug (the actual MITM attack) is *not* a problem with Firefox as suspected by the reporter: Firefox was behaving correctly by identifying the SSL certificates as invalid. It is however an interesting report of a MITM attack.

    • Being among the first to read all about the "perfect attack" is by definition "stuff that matters". The slashdot effect is proportional to the headline and proportional to the amount of damage that potentially can be done [sorry, no citations available]. Therefore, reading TFA is merely a function of headline and potential damage.

      BTW, I decoded your .sig, will you please sue me now?

      • by cp.tar ( 871488 )

        BTW, I decoded your .sig, will you please sue me now?

        Absolutely. My lawyers will call your lawyers and arrange everything.

    • The reason for the "RESOLVED INVALID" is that the bug reporter thought they were reporting a bug in Firefox causing all those annoying SSL popups. What was actually happening was that the user was being attacked with a man-in-the-middle attack. Therefore, this shows how Firefox protects you from the attack. As annoying as those dialogs may be, they are necessary to warn the user of a potential attack.
  • by 00_NOP ( 559413 ) on Tuesday December 23, 2008 @08:22AM (#26210673) Homepage
    It had "0" comments when I started and I still could not RTFA
    • by cp.tar ( 871488 )

      That's called "slashdotting".

      • by Briareos ( 21163 ) *

        More like "/. subscribers seeing articles 30 minutes early" (but with comments disabled)...

        np: Tocotronic - Gegen Den Strich (Pure Vernunft Darf Niemals Siegen)

  • I never liked the notion of "trusted" certs. I have always built my own certs. While I can't read the article, I would say it is an obvious vulnerability in host naming.

    SSL/TLS is mathematically secure. I mean, yes, it really is. You can trust that aspect of it. It breaks down in practice where secrets need to be kept secret or in areas where strict adherence to good practices are vital but not done.

    • SSL/TLS is secure for encrypting data between two known, trusted entities. It's using these as a form of identification that is an issue. Even that may not be so much an issue as the policies that cert issuers use to identify domain holders isn't very thorough and is a pretty poor foundation on which to base a global internet trust system.
  • Another reference (Score:4, Informative)

    by Slite01 ( 1020539 ) on Tuesday December 23, 2008 @08:50AM (#26210869)
    While the original blog is slashdotted, please enjoy this link to Google Groups: http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/9c0cc829204487bf?pli=1 [google.com]
  • by owlstead ( 636356 ) on Tuesday December 23, 2008 @08:54AM (#26210923)

    What's so perfect about the attack listed? It clearly shows up that the certificate is not trusted. With the new and improved, (and for me, irritating) screens of Firefox, where you are clearly warned, this should not be such a big problem.

    What I don't get is that they do not try and locate the idiot trying to do this. Because that is one of the problems with these kind of man in the middle attacks - a single person that does actively goes after you can do some damage. This makes such attacks harder to perform, even if they are technically feasible.

    Maybe they should make it even clearer that you should not use self signed certificates for banks and such, but this is far away from the IE bug that let leaf certificates (with some missing key usages) sign other certificates with any URL.

    I've created one of those attacks on a corporate LAN (just for show, using a proxy) ages ago. Guess that made me a script kiddie :)

    • This is a very old, already solved IE bug, sorry if that's confused anyone.

    • by bunratty ( 545641 ) on Tuesday December 23, 2008 @09:01AM (#26210979)
      In the perfect attack, the certificate is issued by a trusted certificate authority, so no warning is shown. It truly is a perfect MITM attack. We do know exactly who is issuing certificates without verifying the identify of the individuals requesting them. It's time for browser makers to remove some trusted CAs from their lists so users can be secure.
    • To make it a perfect attack you need to either compromise DNS / BGP or sit in the middle of the data stream. I'm guessing the authors example does not do these things, so firefox and any other browser should complain. But if you were to setup a server with the fake mozilla.org cert and then redirect mozilla.org to this server via your hosts file, your browser would not complain at all.
  • by fibrewire ( 1132953 ) on Tuesday December 23, 2008 @09:08AM (#26211019) Homepage

    CAcert certificates are pretty nice because they are FREE!!! even if they need to become a little more responsible in the near future. The cool thing about "Free" is the value is in innovation, because it's the only way to survive being free in the first place. Maybe tie CAcerts to an OpenID??? Honestly, you get what you pay for... friends... hookers... etc.

  • by Gothmolly ( 148874 ) on Tuesday December 23, 2008 @10:10AM (#26211589)

    If a CA doesn't properly validate who you are and cuts you a cert for anyone else, its a problem with CA, not the underlying codebase(s).

  • by guruevi ( 827432 ) on Tuesday December 23, 2008 @10:30AM (#26211769)

    The dude found out that you can have self-signed certificates or certificates signed with whatever CA you want. Here's another MITM angle: you can set up your own root CA (http://www.onlamp.com/pub/a/onlamp/2003/02/06/linuxhacks.html) and you can even become an intermediary (Secondary) CA authority by paying Verisign, Equifax or Thawte. Heck, if you pay enough money to Microsoft, Mozilla or Opera and adhere to certain standards they will include your servers in their set of root certificates.

    SSL is not supposed to be preventing MITM nor is it supposed to be for identifying purposes. We have other technologies for that like PGP but the internet relies on anonymity so you're never 100% sure that you're going to talk to the correct persons. Even with PGP, your initial communications will have to be trusted (eg. you personally hand over or get a key) or any subsequent communications will be compromised. SSL doesn't even go that far because every communication is viewed as an initial communication. If the certificate is re-signed or changed to another CA the next day, your browser will not complain as long as that CA is in it's trusted root certificates.

    I personally think it's the government's fault that PGP didn't break through as a good authentication scheme because of their export limitations on firearms and it took a while before it was circumvented by opening up the standard. It's the browsers fault and the CA's as well (with VeriSign the biggest) by asserting that SSL certificates can be used to authenticate an entity rather than a communications. Lately there came to be the SSL-extensions but it's a) too little too late b) bolted on c) not a solution since that information can also be falsified using the exact same methods as described in the article since all it takes is a 'rogue' SSL signer that doesn't do it's job (or somebody impersonating the entity)

  • by Animats ( 122034 ) on Tuesday December 23, 2008 @12:11PM (#26213001) Homepage

    The article is confusing, and the author declines to name the certificate issuer that's the problem. But the screenshot [startcom.org] gives the details. It's PositiveSSL [positivessl.com]. He really did get PositiveSSL to issue him a Comodo-authorized cert in the name of "www.mozilla.com". Try this link [192.116.242.23] and look at the certificate details.

    It looks like certificates with this issuer information need to be rejected:

    • CN = PositiveSSL CA
    • O = Comodo CA Limited
    • L = Salford
    • ST = Greater Manchester
    • C = GB

    I loaded all current Comodo certificate revocation lists, and this bogus certificate has not been revoked.

    Some Comodo CA root certificate needs to be removed from the approved list.

    • by Animats ( 122034 ) on Tuesday December 23, 2008 @12:46PM (#26213495) Homepage

      Looking at this cert further, it's a very wierd certificate. "Issuer" of ""www.mozilla.com" has "O=Comodo CA Limited". That's descended from "Positive SSL CA", for which "Issuer" has "O = The USERTRUST Network". That's descended from "UTN-USERFirst-Hardware", for which Issuer has "O = AddTrust AB". That's descended from "AddTrust External CA Root". Why is a Comodo cert being issued under AddTrust? Comodo is a root CA itself, with its own root certs in major browsers. Something is not right here.

      So who's AddTrust [addtrust.com]? Their web site says "Under Reconstruction". This does not look good. Checking the Internet Archive, we find "JOIN THE ADDTRUST FAMILY Gain an edge over your competitors by providing co-branded PKI services" [archive.org]

      AddTrust went beyond using resellers. They apparently allowed subordinate CAs to issue certs in AddTrust's name: AddTrust's rapid Trust Service Provider (Licensee) start-up package allows you to deliver cutting-edge public key infrastructure (PKI) services cost-effectively and in a way that best complements your business model. Literally within months you can start selling pre-packaged outsourced PKI services allowing your customers ... AddTrust's globally recognized PKI brand is designed for co-branding with companies recognized for high-quality IT services and products. ... Rather than relying on external certification authorities, you can easily provide high-end certificates yourself by becoming an AddTrust-licensed Trust Service Provider. This allows you to decide how much of the underlying secure infrastructure you want to run and invest in yourself.

      The relationship between Comodo and AddTrust is mentioned in this email. [markmail.org] Robin Aldin of Comodo wrote: There is no ongoing relationship with AddTrust AB, Sweden. I'm not even sure if AddTrust AB still exists as a company. I think AddTrust may exist now only as a brand of ScandTrust AB. Sweden - although Comodo does have the right to continue using the root CA certificates which we purchased from them and which bear the AddTrust name.

      So the party ultimately responsible for this certificate is out of business?

  • by Animats ( 122034 ) on Tuesday December 23, 2008 @01:10PM (#26213821) Homepage

    This subject is being discussed by Firefox developers, Comodo CA people, the person who reported the problem, and somebody named "Patricia" from CertStar, the issuer, here. [markmail.org]

    Robert Alden of Comodo says they "have suspended Certstar's reseller activities until our investigation has been completed." [markmail.org] The CertStar site [certstar.com] now says "Due to technical issues we are unable to process orders at this time. We are working hard to resolve the issue and apologize for any convenience caused. Please check back later."

    The Mozilla team is discussing revoking some root CA keys. [mozilla.org]

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Working...