CA:RevocationPlan: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(Created page with "This page documents Mozilla's future plans for revocation checking of SSL certificates. (It takes much from CA:ImprovingRevocation but hopes to be shorter and more up to d...")
 
No edit summary
Line 1: Line 1:
This page documents Mozilla's future plans for revocation checking of SSL certificates. (It takes much from [[CA:ImprovingRevocation]] but hopes to be shorter and more up to date. When Kathleen returns, the two may well be merged.)
{{draft}}


* Discussion of Policy changes: https://www.mozilla.org/about/forums/#dev-security-policy mozilla.dev.security.policy] forum
This page will document Mozilla's future plans for revocation checking of SSL certificates.
 
* Discussion of Policy changes: [https://www.mozilla.org/about/forums/#dev-security-policy mozilla.dev.security.policy] forum
* Discussion of Code changes: [https://www.mozilla.org/about/forums/#dev-tech-crypto mozilla.dev.tech.crypto] forum  
* Discussion of Code changes: [https://www.mozilla.org/about/forums/#dev-tech-crypto mozilla.dev.tech.crypto] forum  


Line 22: Line 24:
==The Plan==
==The Plan==


The plan has three parts:
To be agreed :-) See [https://etherpad.mozilla.org/Revocation] and [https://etherpad.mozilla.org/RevocationPlan] for discussion and ideas.
 
# Require OCSP stapling in order to get end-entity certificate revocation, and implement must-staple (note: not the same thing as multi-stapling) so an attacker can't just strip off the stapled response.
# Implement a mechanism for pushing important revocations (intermediates, and high-profile misissuances) to Firefox out-of-band and not in real time. This is sometimes referred to as "CRLsets" (Google's name) but our implementation would be different in a couple of key ways.
# Once the above are done, turn off real-time OCSP checking.
These three parts together solve the performance and privacy issues, and allow sites to have proper revocation hard fail.
 
===OCSP Stapling and Must-Staple===
 
We've [https://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/ implemented OCSP stapling].
 
Must-staple comes in 2 flavours: [http://tools.ietf.org/html/draft-hallambaker-tlsfeature-02 an X509v3 extension] and an HSTS-like HTTP header, which is an [http://www.ietf.org/mail-archive/web/tls/current/msg10351.html interim step] proposed by Brian Smith until the extension is more widely supported. It has the first-visit problem, but we can mitigate with a preloaded list.
 
* Implement the X509v3 extension: {bug|901698}} and {{bug|921907}}.
* Implement the header: no bug that I can find.
 
===Revocation Push Mechanism===
 
We would build a mechanism to push revocation information to Firefox from Mozilla servers. This would be used for revoked intermediates, and high-profile end-entity misissuances. It could be automatically fed from a CRL crawler. We would require CAs to notify us of the URLs for their CRLs.
 
Despite it having been discussed and part of the plan for some time, the only write-up of this I can find of this idea is on [[CA:ImprovingRevocation#Preload_Revocations_of_Intermediate_CA_Certificates|CA:ImprovingRevocation]]. I don't think there's a bug.
 
===Disable Real-Time 3rd Party OCSP===
 
Once we have implemented support for must-staple and we have the revocation push mechanism as a backup for emergencies, we would turn off all non-stapled real-time OCSP checking on both desktop and mobile. This would solve the performance and privacy problems that OCSP has.
 
==What We Do Meantime==
 
The bulk of Mozilla's effort should be spent implementing the components of this plan. However, because not many sites currently implement OCSP stapling, and because we don't have the push mechanism yet, do we do anything else meantime?
 
Turning off OCSP checking before we have must-staple and revocation-push is dangerous, because it leaves us without any cover for the next Diginotar, Heartbleed or other certificate-related disaster. For some types of disaster such as Diginotar, we can issue a Firefox update, but for other types such as Heartbleed, that doesn't work because we don't have the necessary information.
 
===Relevant External Constraints===
 
Mozilla does not have explicit contracts with the CAs whose roots it includes in the NSS root store. The CA/Browser Forum Baseline Requirements, in section 18.2, which we require CAs we trust to adhere to and be audited to, require that CAs indemnify application software suppliers such as Mozilla from all liability. However, the indemnity does not apply "if a Certificate that has been revoked (but only in cases where the revocation status is currently available from the CA online, and the application software either failed to check such status or ignored an indication of revoked status)."
 
Therefore, failing to check revocation information entirely may expose Mozilla to legal risk. This issue would have to be analysed.
 
==What Do Others Do?==
==What Do Others Do?==


Revision as of 12:56, 3 July 2014

Draft-template-image.png THIS PAGE IS A WORKING DRAFT Pencil-emoji U270F-gray.png
The page may be difficult to navigate, and some information on its subject might be incomplete and/or evolving rapidly.
If you have any questions or ideas, please add them as a new topic on the discussion page.

This page will document Mozilla's future plans for revocation checking of SSL certificates.

Revocation Is Important

Support for revoking certificates is important, because otherwise stolen certificates can be used to abuse our users until they expire. History, from Diginotar (malicious misissuance) to Heartbleed (private key theft vulnerability) shows us that the ability to revoke certificates is important. Having no revocation story is not an option.

Problems to Solve

However, there are several things very sub-optimal about the current mechanisms for revocation checking.

There are two common revocation-checking mechanisms - CRLs and OCSP. CRLs are lists of revoked certs, and OCSP is a protocol where a browser can enquire about the status of specific certs from the CA in real time. CRLs have bad download size and storage size characteristics, and because they are lists of "known badness", can't protect against misissuance the CA doesn't know about. Firefox no longer checks CRLs at all, although they remain useful for feeding revocation information into other mechanisms. This page will not consider CRLs further. For OCSP:

  • Revocation of intermediate certificates is only checked during EV validation. That is, the intermediates we do check revocation for are the ones that are the least likely to cause our users security problems.
  • Standard OCSP has poor privacy properties; the CA learns the user's IP address, location, and a subset of their browsing history.
  • Standard OCSP is way too slow, especially on mobile.
  • Captive portals with HTTPS login pages work very poorly in Firefox because it stalls for 30+ seconds waiting for the (blocked) OCSP response.
  • The traditional revocation mechanisms treat all possible reasons for revocation uniformly for all websites, so relatively unimportant revocations overwhelm the system and completely drown out obviously critical revocations.

The Plan

To be agreed :-) See [1] and [2] for discussion and ideas.

What Do Others Do?

Chrome on Desktop

Google Chrome only uses CRLsets for non-EV (and some EV?) certs. However, their CRLset implementation covers both end-entity and intermediate certs, and is not designed to be comprehensive. Some CRLs are not included - the list is manually mantained by emailing agl.

agl is of the opinion that the only thing other than CRLsets which is worth considering is must-staple. So Chrome seems to be going in the same direction as us.

IE on Desktop

IE checks OCSP and, if OCSP fails, falls back to CRLs - although they are considering eliminating the fallback.

Chrome on Mobile

???

Android Browser

???

Retrieved from "https://wiki.allizom.org/index.php?title=CA:RevocationPlan&oldid=994433"