CA/Comodo Misissuance Response

From MozillaWiki
Jump to: navigation, search

On 25th March 2011, in the wake of the Comodo misissuance incident, Mozilla began a wide-ranging discussion about the future of web security. This page links to resources related to that discussion. If you have a researched and carefully written paper on the subject, please feel free to add a link in the Position Papers section. (Note that this page is not the venue for the debate - that is here.)

Overall Aims

When discussing how we want the web security landscape to look in 3-5 years, we need to keep in mind the following aims:

  • Performance - large sites will not adopt solutions which bulk up the amount of data required to be exchanged to establish an secure connection.
  • Independence - large sites will not accept tying the uptime of their site to the uptime of infrastructure over which they have no control (e.g. an OCSP responder)
  • Accessibility - solutions should not put the cost of security, either in terms of single sites or large deployments, out of the reach of ordinary people
  • Simplicity - solutions should be simple to deploy, or capable of being made simple.
  • Privacy - ideally, web users should not have to reveal their browsing habits to a third party.

Position Papers

Actions Within the Current Model

The possible things Mozilla could do about this fall into a number of categories:

Changes to Our Root Store

We could:

  • Un-trust the root concerned, UTN-UserFirst-Hardware. A preliminary analysis suggests this would affect 205,000 sites, or 13% of the SSL web. However, this figure could be revised (downwards) by cross-signing.
  • Un-trust all Comodo's roots.
  • Un-trust one or more of their roots, but only for all certificates issued after a particular date. This would require code changes in Firefox or NSS.

Mozilla would be interested in more detailed impact assessments of the above suggestions.

  • Remove all roots which are unused, or used below a certain level, on the public internet.
  • Keep an official Hall of Shame listing instances of certificate misissuance

Changes to CA Policy

We could:

  • Require that all CAs arrange things so that each RA issues from a different subordinate cert.
  • Require that RAs are audited to the same standards as CAs.
  • Require that the identity of all RAs and SubCAs be publicly disclosed.
  • Require that all RA functions are protected by two-factor authentication and/or IP address restrictions.
  • Require that the domain control checks are always done by the CA, never the RA.
  • Require DNS Name Constraints to a specified number of Public Suffixes to be put on any non-leaf certificate the CA issues which it does not control (e.g. subordinate CAs).
  • Require a current-cert-is-not-EV check for all non-EV issuances (open a connection to port 443 on the target domain(s), or www. for wildcard certs, and flag for manual review if the current cert is EV)
  • Require the use of high-value target domain lists to flag requests, pre-issuance, for manual review.

Changes to NSS

  • Fix NSS to allow us to add certs to the store which are specifically untrusted (bug)

Other potential changes:

  • Switch to the new PKIX library; this gives us CRL download-on-demand.
  • Add a capability to disable roots for all certificates dated after a certain date.
  • Implement OCSP stapling.

Changes to Firefox

We could:

  • Turn on OCSP "hard fail" by default for everything.
  • Turn on OCSP "hard fail" just for EV (currently, we have a soft-fail - EV is downgraded to DV if OCSP fails).
  • Change it so that an OCSP failure is a hard failure if the site is using HSTS. Note that Chrome is moving in the opposite direction for site uptime reasons.

OCSP improvement solutions would need to deal with protocol problems such as the current ability to return "try again later", as well as the uptime objections raised by large sites. They would also need to deal with issues like captive portals on WiFi hotspots where the login page is SSL-protected, and scenarios around proxy auth.

Future Technologies

Several technologies have been proposed to address perceived shortcomings of the current security model.

HSTS

HTTP Strict Transport Security is a way of forcing a browser visiting a particular site to use HTTPS and never HTTP.

  • It has been proposed to extend HSTS to allow the header to specify the CA concerned, thereby segmenting the CA space and reducing the attack surface. (To impersonate the site, you need to compromise the particular CA involved, not just one of those trusted by the browser.)

DNS-based

Several people have proposed validating domain control by placing the certificate, or a hash of it, or other certificate-related information in DNS records. For any of these schemes to be secure, the record would have to be protected by DNSSEC.

  • DANE is an RFC draft for certificates-in-DNS; this would allow proof of domain control without the need for a CA (bug)
  • Do Not Issue allows site owners to say which CAs are permitted to issue certificates for that domain
  • HASTLS is an RFC draft to allow a server to advertise secure connection support

TOFU

TOFU stands for "Trust On First Use", also known as the "SSH model" - trust in a certificate is established on first use. Ideally, this would be by confirming the key fingerprint out-of-band; in practice, it's often done by crossing one's fingers and hoping.

Eliminate Revocation Checking

  • Adam Langley has suggested that short-lived certificates could replace revocation checking

OCSP

Google are on record as saying that stapling multiple OCSP responses would unacceptably increase the amount of data that had to be exchanged for SSL setup beyond the initial TCP window size, thereby slowing down sites.

  • Rob Stradling has suggested that browsers should make sure to try every IP address that the OCSP server hostname resolves to before giving up, and even try multiple ones in parallel.
Retrieved from "https://wiki.mozilla.org/index.php?title=CA/Comodo_Misissuance_Response&oldid=1239737"