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

Comments

Don't do this at home

[moro_666]

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.

Re:Don't do this at home

[Timothy Brownawell]

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

Re:Don't do this at home

[cp.tar]

Oh, dear. So who certifies the certifiers?

Re:Don't do this at home

[jonbryce]

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

Re:Don't do this at home

[Anonymous Coward]

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

Re:Don't do this at home

[betterunixthanunix]

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:Don't do this at home

[Ed Avis]

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

Re:Don't do this at home

[profplump]

Or just make users choose their card type before you present an input box for the number and redirect to the appropriate domain.

Alternatively you could take a PayPal approach, where the retailer directs me to visa.com and I input secret data there, authorizing payment back to the retailer without giving the retailer any secret information or trusting their certificate at all (other than to hide my purchasing/browsing history from snooping).

I know Visa et. al don't want to be in that business, but it's a significantly more secure approach -- I can trust the CA issued by Visa for purchases I make with Visa and I can avoid giving my secret data to anyone that doesn't already have a copy.

Re:Don't do this at home

[u38cg]

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.

Re:Really now.

[daveewart]

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.

Re:Sensationalist - reroute & self signed cert

[bunratty]

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.

Re:OK, which CA must leave the trusted list?

[bunratty]

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.

Re:Sensationalist - reroute & self signed cert

[Anonymous Coward]

actually, simply 'removing' a ca isn't quite sufficient, i think we're better served by remembering the ca with a note that it is NOT trusted.

otherwise a user can just go back and add it again.

Re:OK, which CA must leave the trusted list?

[timeOday]

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.

Re:OK, which CA must leave the trusted list?

[Kent Recal]

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 everywhere will just keep on repeating their mistakes over and over in order to "streamline" the process for "optimized revenues". I would even go as far to suspect that this *might* be a PR stunt to drive more people into the horridly expensive "green addressbar" certs (and wait for it, we'll see more colors in the future, for even more security!).

The only technically correct way out of this would be to abandon this broken and tainted system altogether.
But it's not gonna happen, VeriSign and friends will make sure of that with all their weight.

Re:OK, which CA must leave the trusted list?

[maxume]

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.

Re:OK, which CA must leave the trusted list?

[giorgiofr]

I would never put my money in an unregulated bank, or send premiums to an unregulated insurer, or go to a back-alley doctor.

But you have no problems forcibly preventing me from doing so, should I wish to. That's not even close to not being a libertarian. It's being a dictator.

Re:OK, which CA must leave the trusted list?

[Vellmont]

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

which

[Anonymous Coward]

Which CA is this, and how do I disable it in safari?

Who trusts the trusters?

[Gothmolly]

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

Re:OK, which CA must leave the trusted list?

[Wonko the Sane]

Silly americans and their megalomaniatic view of the world, (mod me flamebait) you guys are not the center of the world, nor the policemen of the nations.

I really don't think that the evidence supports your assertions. There is a difference between "are not" and "shouldn't be".

Put the certificate fingerprint in DNS

[Anonymous Coward]

Put the certificate fingerprint in DNS. I lookup a domain name and get an IP address and fingerprint, allowing me to be certain that I am talking to whom I think I am talking to. No CA needed. (Of course, we need DNSSEC for this to really work.)

How does it help for an organization in Africa to certify that a given certificate is "legitimate"? What does that mean, anyway?

Re:Firefox is right to warn.

[StartCom]

That's because your company distributed their root or server certificate with the active directory or domain controller. Chrome currently relies on the windows cert store so does IE obviously. Not so Mozilla Firefox and hence the error.