Slashdot Mirror


Perfect MITM Attacks With No-Check SSL Certs

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

9 of 300 comments (clear)

  1. OK, which CA must leave the trusted list? by Anonymous Coward · · Score: 5, Interesting

    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.

    1. Re:OK, which CA must leave the trusted list? by timeOday · · Score: 5, Interesting

      I guess this is my fault for mentioning libertariansm in the first place. For the record, I think it's a great idea in an imaginary perfect world where everybody has complete access to all information, dishonesty is abolished, natural resources are infinite (so each of us can breathe our own air, etc), and everybody starts life on equal footing (access to education, proclivity to illness, etc). Which is to say, it's exactly as practical as Communism and every other idealization that never seems to get fully proven or disproven because it can never actually exist.

  2. Sensationalist - reroute & self signed certs by owlstead · · Score: 3, Interesting

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

  3. Use your OWN certs... or use CACert.org's by fibrewire · · Score: 3, Interesting

    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.

  4. Re:Don't do this at home by TheLink · · Score: 4, Interesting

    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

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

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

    --
  5. Re:Don't do this at home by mpe · · Score: 3, Interesting

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

  6. Firefox is right to warn. by tjstork · · Score: 4, Interesting

    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.

    --
    This is my sig.
  7. Re:Don't do this at home by starfishsystems · · Score: 3, Interesting

    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.

    --
    Parity: What to do when the weekend comes.
  8. Re:Don't do this at home by Kadin2048 · · Score: 3, Interesting

    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.

    --
    "Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."