SSL Cert Weaknesses Exposed By Comodo Breach

snydeq writes "InfoWorld's Woody Leonhard delves deeper into the Comodo SSL scandal and finds the breach calls into question the integrity of the SSL certification process itself. 'While the press has focused on the sensational fact that Comodo's site was hacked from an Iranian IP address, we really should be asking three questions: How did somebody working with an Iranian IP address get a username and password from Comodo with enough clearance to create SSL certificates? Why did Comodo issue SSL certificates for google.com, live.com, yahoo.com, mozilla.org, and skype.com? Why are browser updates used to revoke SSL certificates?'"

Comments

SSL certs are both over-trusted and under-trusted

[billyswong]

If you went to a site with a cert signed by those big companies, those sites are trusted with no questions. If a site don't want to pay and use a self-signed cert instead? Wow, the end-user are warned as if it is more dangerous than plain HTTP site!

A more rational mechanism should be telling users the truth honestly, i.e. "this site's traffic is encrypted and the authority is promised by xxx.com, or if self-signed, self-proclaimed". Those big companies aren't that trustful, they are just lucky enough to gain an early seat into the root cert trust list in the dawn of internet.

Peter Guttman's take

[kensan]

He makes some interesting points on EFF's SSL Observatory mailinglist: https://mail1.eff.org/pipermail/observatory/2011-March/000138.html

Re:Peter Guttman's take

[Jesus_666]

Let me get this straight.

If I have the ability to obtain a cert for one site (say, mycompany.com), I have the ability to obtain entirely valid certs for any site on Earth? And the only way to counteract this is to have browser vendors blacklist my keys in their next update? And that's the foundation HTTPS stands on? And alternative schemes that may address the problem aren't even considered by the browser vendors?

Wow. If I understand that correctly, web encryption is in a pretty bad shape as far as trustworthiness goes.

Re:Regarding question 1

[flonker]

They didn't buy it. They created it through the reseller process. OpenSRS, for example, requires that all IPs that have access to the domain registration process are registered beforehand. That would have stopped this attack cold. Comodo didn't even have so much as a "wow, that's funny, this /24 has never logged in before, and is registered to a country I don't have any resellers in." Also, a lot of people seem to believe that automated systems should blacklist high profile targets from being automatically granted certificates.

Re:SSL certs are both over-trusted and under-trust

[Rigrig]

I agree it's stupid how browsers show self-signed certificates as more dangerous than plain HTTP.

The difference between paid-for certificates and self-signed certificates means more than just who promises authenticity though: The certificate's signature can be checked against the certificate shipped with the browser, thus preventing MITM attacks.

Basically:

1. HTTP: everybody on the network can read your stuff, including passwords etc. They don't even need to perform a MITM attack. With a simply MITM attack they can also alter content.
2. Self-signed HTTPS: your traffic isn't that easily sniffable anymore, but an attacker can perform a MITM attack to read/alter your data. He'd intercept all your browsers' requests, including the certificate, and replace them with his own.
3. CA-signed HTTPS: an attacker can't perform a MITM attack, because intercepting the certificate request means it's signature won't match with the CA-cert that your browser shipped with.

Thus paid-for certificates mean you won't get MITM'd, the part where the CA also verifies identities is just bonus.

Re:Thanks Comodo

[thue]

The beauty of it is that even if you do not buy your certificate from Comodo, you are still just as vulnerable to false certificates in your name from Comodo (Or any other of the ~650 CAs).

Two more questions

[Lincolnshire Poacher]

1. Why was a key-gen server connected to the Internet? Shouldn't certificates be delivered out-of-band, such as on a CD delivered to the indicated registered address?

2. Why exactly do we still trust Comodo as a CA, when the like of cacert.org cannot meet the "requirements" to be added as a CA in Mozilla products?

Re:Two more questions

[RulerOf]

Why exactly do we still trust Comodo as a CA, when the like of cacert.org [cacert.org] cannot meet the "requirements" to be added as a CA in Mozilla products?

$urely, you can't be $eriou$.

Re:SSL certs are both over-trusted and under-trust

[Confusador]

But it's still better than http, because it's not trying to solve the vulnerability you're complaining about. Plain HTTP is vulnerable to MITM and ANY SORT OF EAVESDROPPING. Self signed certs are vulnerable to MITM, and eavesdropping (I believe) if the 3rd party catches all of the key exchange. CA signed certs are vulnerable to neither.

Claiming that self-signed certs are the same as plain-old-http is as ridiculous as claiming that self-signed certs are secure. They won't protect you against an even mildly determined attacker, but they will stop e.g. the Google van from picking up your email. (Yes, that would have been a problem users could have fixed easily, but do you trust them? More layers of security, when easily implemented, are better.)

Re:Even more important

[TheRaven64]

How? I have an account, and I've clicked on the load all comments button in preferences, but I still only get 250 comments by default. Other complaints:

• It's still a fixed-width layout, so I have scroll bars unless I make my browser window wider (what is this, 1998?)
• In a recent update, some event handler when I reply to a comment in the page that opens when I jump to a specific comment (e.g. in a message) decides to jump me back to the top of the thread and makes the input text field lose focus

Re:SSL certs are both over-trusted and under-trust

[roman_mir]

This gets repeated over and over again, and still all the MITM scaremongering carries on, while sensible approach of not displaying visual cues for HTTPS with self signed certs, that they are 'secure', but simply encrypting the connection and proceeding to the site, the same way it's done for HTTP is drowned out in the flood of FUD.

What browsers should do is display the fingerprint for the certificate near the URL, so it's easy to verify, but rather than that, HTTPS connections should be treated exactly like HTTP connections, unless there is a CA, in which case the browser should provide visual cues that a third party CA believes this is the actual certificate for the site, that the browser connects to.

Re:SSL certs are both over-trusted and under-trust

[sjames]

Not at all. The current state of affairs is that self-signed certs are treated almost as bad as invalid certs. The site's identity with a self-signed cert is just as good as an unencrypted connection would be (but no better) but it is more secure against 3rd party sniffing. I would rather it look the same as an unencrypted connection (no lock icon, no green trust indicator) rather than the OMFG IT'S A SELF-SIGNED CERT!!!!!!!!! click here, here, here, and here, gee, it was nice knowing you! like it does now. Perhaps it should display a 'cone of silence' icon.

However, if the cert has changed since the last time I visited a site, especially if it's now signed by a different authority, I should be concerned MORE than a self signed cert, especially if the previous cert shouldn't be near expiring yet.

The problem is that trust is fine grained and multi-dimensional but is presented as a simple go/no-go threshold.