Slashdot Mirror
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?'"
Before those questions are answered, I'd just like to thank Comodo for making my next SSL certification renewal an even easier decision.
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.
He makes some interesting points on EFF's SSL Observatory mailinglist: https://mail1.eff.org/pipermail/observatory/2011-March/000138.html
Conversely, someone with a North American IP shouldn't be able to get a cert for the National Iranian Oil Co., at least not without triggering a sanity check in the system. I can't see why that would be controversial; clearly someone wasn't doing their job.
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.
If only we weren't beholden to decisions made in the 80's and 90's. IPv4, HTTPS we might as well start over. While we're at it hardware AES extensions on more low power processors, should I really have to choose between a VIA Nano and Core i5 if I want decent SSL encoding speed.
http://www.aaronrogier.net
All we have is Comodo claiming they were from Iran, and an IP address. But why should we trust them? If you ask me, Iran fits in a bit too well as the bad guys.
The problem with that solution, is that it give no protection against "man in the middle" attack.
See: http://en.wikipedia.org/wiki/Export_of_cryptography_in_the_United_States#Current_status and http://en.wikipedia.org/wiki/Rogue_states (Yes, I know wikipedia sources...)
The problem with that solution, is that it give no protection against "man in the middle" attack.
Please elaborate, as I have not suggested any changes in the protocol (yet). I am merely asking browsers to present things more accurately, closer to the truth, not "see the little lock then you are safe" stuff. Also not over-reactive to outdated/self-signed cert.
You would have self-signed certs presented as "semi-secure", which they are not.
Only if the client has the certificate ahead of time. Otherwise it really isn't.
I accepted a self signed cert from a college server when I was physically in the room with it and chances of MITM were stunningly low.
I go home and get a change of cert warning connecting to the server and alarm bells start ringing.
In such a case self signed certs are *more* secure than a cert signed by someone...somewhere who is apparently trusted by someone has signed their cert and which may have been compromised as in TFA.
With unencrypted HTTP, any one who can see the packets can snoop the whole session.
With SSL/TLS, with a self-signed certificate, the attacker has to be in a position to tamper with the packets. The attacker has to impersonate the server to the client, and potentially the client to the server (depending on the attack). This is a much harder problem than simply sniffing the traffic with tcpdump.
Anyone on a public WiFi network can sniff the packets of other users on the WiFi network. It would be very difficult to pull off an attack on a self-signed SSL connection.
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:
Thus paid-for certificates mean you won't get MITM'd, the part where the CA also verifies identities is just bonus.
**TODO** [X] Steal someone elses sig.
This is stupid many time there is a story about hacking and a IP coming from that 'third world country' (insert name here China[ ], Iran [x], Russia [ ], all other[ ]......), someone assume that a person local to that country did all the job. What if that IP in Iran was not secured ? What if that person actually used the internet and connected to that IP in Iran from somewhere else (doh). There is a ton of non-patched OS, vulnerable IP out there. Some peoples shouldn't use the internet (or for that matter shouldn't make conclusions or assumptions on 'too technical stuff')
> Only if the client has the [self] certificate ahead of time. Otherwise it
> really isn't [more secure than plain http]
Actually all you need is the fingerprint of the certificate to verify, not the whole cert.
For example, as hosting provider you may provide PHPMyAdmin logins for your customers, so they can admin their databases from the browser. A self-signed certificate from the hosting provider to secure that login is perfectly reasonable, as is a phone call to the customer providing them with the fingerprint of the self-signed cert to prevent a MITM. And yes, that is most certainly more secure than plain-text HTTP. In fact, it's even more secure than the gazillion-trusted-potentially-MITM-enabling CA certs!
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?
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.)
obfuscated http(https without certificates) is way more secure against wiretapping than not security at all.
And even then the current GUI of browser for invalid https certificates is way less usefule than expected. Due to the harsh error it is not a good strategy to hack out comodo yourself, since you get a lot of error messages that are not important.
https does only garantee there is no man in the middle attack. the CA does not say much more than that. Even a malware ridden site for a company "always trust" might get a certificate. It might even be untrackable after that.
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:
I am TheRaven on Soylent News
It all sucks dog's balls.
Using the old D1 system is the only usable option.
http://slashdot.org/prefs/d1
This post contains benzene, nitrosamines, formaldehyde and hydrogen cyanide.
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.
You can't handle the truth.
Question #4, on the list, perhaps.
Why, if Google's certs come from Thawte, is it that big a problem of Comodo issues a bogus google.com cert?
Browsers should remember that Google's certs last came from Thawte (a particular root cert) and today, all of a sudden, it is being verified by another company. Browsers should warm you about this. I know a lot of people would just click "yes" and be done with it, but I think also given it would happen worldwide (in the case of a worldwide attack) would bring the story, the presence of new and possibly fake certs to the fore.
Also, on another note, companies like Comodo should flat out just cache Alexa or something and require additional verification before issuing a cert for a high-traffic site, especially if they don't have them as a current customer.
http://lkml.org/lkml/2005/8/20/95
There was a time, not that long ago, when someone faxed Verisign a request for the private keys for Microsoft's SSL certificates and Verisign responded by handing the keys to them. No verification that the person was legit. DNS providers were just as vulnerable, with people sending in requests for zone transfers by e-mails with forged headers, faxes, letters on stationary not bearing any corporate logo. It worked often enough for there to be numerous scandals.
As for China managing to trick the top-tier routers to re-route half the world's Internet through their packet sniffers... Well, I never was a fan of BGP, and I've grown to loath it all the more.
Getting back to SSL, first nobody should be using SSL 3.0 any more. TLS 1.2 is the current standard and has signficant improvements. Sadly, none that would install a brain into the heads of PHBs or half-asleep cert techs, but it's better than nothing.
Second, let's look at how other people solve this problem. In the physical world, official documents to do with identity usually require at least one witness to countersign and a recognized notary office to stamp the document to reduce the risk of tampering. In the GnuPG/PGP world, it is not unusual to have keys digitally signed by "witnesses" and GnuPG uses an algorithm to reduce the risk of tampering. So clearly, these kinds of procedures have a digital parallel in use.
How would this work in SSL? Well, you could have it so that if organization A knows that organization B's certificate is genuine and correct, organization A could counter-sign B's SSL/TLS certificate as an extra layer of trust. (If a fake Google certificate had a few dozen counter-signatures, all from Iran, it shouldn't be hard to figure out it's fake.)
Or there could be secure public fingerprint servers, where instead of a simple upload (as per MIT's keyserver), the verification of identity by the keyserver owners was every bit as strict as implied by the certificate grade. The cert fingerprint would then be uploaded by the owners and digitally signed by them. A browser, on seeing a new key, could then ask if you wanted to verify the key against one of the known public fingerprint servers rather than giving a technical analysis most users can't understand.
Or we could dump the SSL/TLS approach and go with a different site authentication mechanism. It's not like there's a shortage of them, it's more that Netscape implemented SSL and so nobody really bothered with trying to adapt the others. (Ok, there was a short-lived SHTTP, in addition to HTTPS, but I can't think of any other real effort for website authentication since then. Site-to-host authentication should be standard for all services, since the connection has nothing to do with the service, it's just a connection between a site and a host.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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.
Erm, you could indeed redirect the user to your own root DNS server, but then none of the DNSSEC replies you sent would have the correct signatures (since you don't have the real private keys used by the actual root server).
Obviously the browser has to already have the public keys for every root zone, but that's no different to SSL certificates. And DNSSEC has to used at every zone.