Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror
×
Security The Internet IT

SSL Cert Weaknesses Exposed By Comodo Breach 194

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?'"
This discussion has been archived. No new comments can be posted.

SSL Cert Weaknesses Exposed By Comodo Breach

Comments Filter:
  • by billyswong ( 1858858 ) on Friday March 25, 2011 @06:42AM (#35609446)

    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.

  • by Jesus_666 ( 702802 ) on Friday March 25, 2011 @07:28AM (#35609662)
    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.
  • by kangsterizer ( 1698322 ) on Friday March 25, 2011 @07:54AM (#35609762)

    It is more dangerous when self-signed. Because it gives you a false sense of security otherwise. On plain http you _know_ you are not secure.
    On self-signed you _think_ you are secure so you'll put your credit card number and what not more easily, while in fact, maybe you're not secure.

    Note: self-signed is not necessary unsecure, you just need to make sure you know what you trust when you click "ok and save" the first time.. or get the cert separately and make the same checks.

  • Two more questions (Score:5, Insightful)

    by Lincolnshire Poacher ( 1205798 ) on Friday March 25, 2011 @08:03AM (#35609812)

    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 [cacert.org] cannot meet the "requirements" to be added as a CA in Mozilla products?

  • by RulerOf ( 975607 ) on Friday March 25, 2011 @10:06AM (#35610966)

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

  • by roman_mir ( 125474 ) on Friday March 25, 2011 @11:02AM (#35611648) Homepage Journal

    This gets repeated over [slashdot.org] and over again [slashdot.org], 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.

  • by sjames ( 1099 ) on Friday March 25, 2011 @03:05PM (#35615054) Homepage Journal

    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.

An authority is a person who can tell you more about something than you really care to know.

Working...