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."
OK, which CA must leave the trusted list? (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.
Sensationalist - reroute & self signed certs (Score:4, 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 :)
Use your OWN certs... or use CACert.org's (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.
Re:Don't do this at home (Score:5, 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 [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. :)
Re:Don't do this at home (Score:4, Interesting)
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...
So, what's the big deal (Score:3, Interesting)
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)
Re:OK, which CA must leave the trusted list? (Score:5, Interesting)
Re:Don't do this at home (Score:3, Interesting)
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 new file is provided. The domain is randomly checked over that period of three weeks to ensure that all the provided files are being served. After this, the certificate is issued. Renewals would follow a similar process (but with a reminder sent out well in advance so that the checks could take place well before expiry).
It is unlikely that somebody could exercise this level of control for an extended period of time simply via DNS spoofing or advertising bad routes. However, the issued certificate would only include the domain, and would not certify owner details (name/address/phone/etc). To obtain a cert with these credentials I think that a more intensive check would be prudent.
The current system basically amounts to a tax on SSL, and little more. If you pay some money to some auditor you can get into the SSL certificate business.
Also - SSL should allow certificate-less operation. Sure, that is vulnerable to MITM, but at least it is better than unencrypted http. Perhaps we should have more than two tiers of security (completely insecure, and "completely" secure).
Firefox is right to warn. (Score:5, 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.
Re:Don't do this at home (Score:4, Interesting)
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.
Re:Don't do this at home (Score:4, 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.