Skip to Content.
Sympa Menu

cacert - Comodo compromise

Subject: A better approach to security

List archive

Comodo compromise


Chronological Thread 
  • From: Kurt Albershardt <kurt AT nv.net>
  • To: cacert AT lists.cacert.org
  • Subject: Comodo compromise
  • Date: Sun, 10 Apr 2011 09:35:08 -0600

Just stumbled across this while looking into hardware key storage options for a new server here.  Perhaps we can learn something from this?

From http://wiki.twit.tv/wiki/Security_Now_295

Topic: Comodo SSL Hack

History:

  • Comodo initially quietly sent a command to its certificate revocation servers designed to tell browsers to no longer accept 9 certificates signed using its private key.
  • Major browsers went beyond this normal revocation process and added hard-coded "do not trust".
  • Mozilla forced this in as the last change to their v4 Firefox source code.
  • Jacob Appelbaum, a researcher at the University of Washington's Security and Privacy Research Lab independently uncovered the certificate theft by carefully watching Chromium source code updates notices some oddity....
  • Chromium hard-codes some invalid certificate serial numbers
  • A Mozilla update does the same.
  • issuer=/C=US/ST=UT/L=Salt Lake City/O=The USERTRUST
  • Network/OU=http://www.usertrust.com/CN=UTN-USERFirst-Hardware
  • EFF's SSL Observatory:
    • As of August 2010, 85,440 public HTTPS certificates were signed directly by UTN-USERFirst- Hardware. In the event of a revocation, at least 85,440 websites would have to scramble to obtain new SSL certificates.

Comodo Confesses:

Definitions:

  • Certificate Authorities:
    • Issues "Certificates" attesting to the identity of web sites.
  • Registration Authorities
    • “Partners with certificate issuing autonomy”
  • DCV - Domain Control Verification
  • eMail sent to verify that requestor has control of requested domain

Comodo: (Robin Alden - CTO Comodo)

  • "what we had not done was adequately consider the new (to us) threat model of the RA being the subject of a targeted attack and entirely compromised."
  • "Two other (additional) RA accounts had since been compromised though no other erroneous certs had been issued."
  • "High Value Target Check" -- we have such capability, but it had been disabled on several RA's. We're changing the structure to enforce this universally.
  • EV certificates were never able to be issued by RA's.

Comodo adding:

  • IP-based address restriction
  • Hardware-based two-factor authentication for RA logon

Mozilla:

  • Criticized Comodo for allowing RA's to issue certs directly from the root and has asked that each RA issue from a sub-CA.
  • To exploit the fake credentials?
    • Host File
    • Malicious DNS
    • Anyone in the connection - MITM

CRL and OCSP

  • Revocation
  • Certs last only a few years but what if something bad happens before then?
  • OCSP - Online Certificate Status Protocol (OCSP)
  • CRL - Certificate Revocation List

Conclusions:

  • The FUNDAMENTAL problem:
  • The underlying technical design is fragile. ANY CA can certify to ANY user that ANY server owns ANY domain name. Therefore the consequences of a misplaced trust decision are about as bad as they can be. It's tempting to write this off as bonehead design, but in truth the available design options are all unattractive.
  • Stated another way: The real problem is a structural one: there are 1,500 CA certificates controlled by around 650 organizations, and every time you connect to an HTTPS webserver, or exchange email (POP/IMAP/SMTP) encrypted by TLS, you implicitly trust all of those certificate authorities!
  • Steve Schultze @ Freedom To Tinker
    • * Too many entities have CA powers: As the SSL Observatory project helped demonstrate, there are thousands of entities in the world that have the ability to issue certificates. Some of these are trusted directly by browsers, and others inherit their authority. We don't even know who many of them are, because such delegation of authority -- either via "subordinate certificates" or via "registration authorities" -- is not publicly disclosed. The more of these entities exist, the more vulnerabilities exist.
    • * The current system does not limit damage: Any entity that can issue a certificate can issue a certificate for any domain in the world. That means that a vulnerability at one point is a vulnerability for all.
    • * Governments are a threat: All the major web browsers currently trust many government agencies as Certificate Authorities. This often includes places like Tunisia, Turkey, UAE, and China, which some argue are jurisdictions hostile to free speech. Hardware products exist and are marketed explicitly for government surveillance via a "man in the middle" attack.
    • * Comodo in particular has a bad track record with their RA program: The structure of "Registration Authorities" has led to poor or nonexistant validation in the past, but Mozilla and the other browsers have so far refused to take any action to remove Comodo or put them on probation.
    • * We need to step up efforts on a fix: Obviously the current state of affairs is not ideal. As Appelbaum notes, efforts like DANE, CAA, HASTLS, and Monkeysphere deserve our attention.






Archive powered by MHonArc 2.6.16.

Top of Page