CA:Comodo Misissuance Response
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.)
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.
- Adam Langley: "revocation doesn't work"
Actions Within the Current Model
The possible things Mozilla could do about this fall into a number of categories:
Changes to Our Root Store
- 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
- 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
- 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.
Several technologies have been proposed to address perceived shortcomings of the current security model.
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.)
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 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.
- Essay from Gervase Markham about self-signed certs; it explains some of the problems of a TOFU model
- Perspectives is an attempt to mitigate the problems of TOFU using crowdsourcing.
Eliminate Revocation Checking
- Adam Langley has suggested that short-lived certificates could replace revocation checking
- Yngve Pettersen has proposed an extension to OCSP stapling which allows the stapling of more than one OCSP response.
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.