|
|
| Line 1: |
Line 1: |
| = Plan for Improving Revocation Checking in Firefox = | | = Plan for Improving Revocation Checking in Firefox = |
|
| |
|
| This page is dedicated to improving how Firefox does revocation checking of SSL certificates. | | See [[CA:RevocationPlan | CA:RevocationPlan]] for Mozilla's plans regarding how we will support revocation checking of SSL certificates. |
| | |
| | This page is dedicated to changes that are happening to move towards our [[CA:RevocationPlan#Long-range_Vision | long-term revocation goals]]. |
|
| |
|
| * Discussion of Policy changes: '''mozilla.dev.security.policy''' forum | | * Discussion of Policy changes: '''mozilla.dev.security.policy''' forum |
| Line 8: |
Line 10: |
| Results of a research project commissioned by Mozilla to investigate the state of SSL Certificate Revocation: | | Results of a research project commissioned by Mozilla to investigate the state of SSL Certificate Revocation: |
| [[File:SSLcertRevocation.pdf]] | | [[File:SSLcertRevocation.pdf]] |
|
| |
| The traditional X.509 CRL and OCSP mechanisms treat all possible reasons for revocation uniformly for all websites. This uniformity leads directly to the scalability problem of revocation checking: relatively unimportant revocations overwhelm the system and completely drown out obviously critical revocations. The key to efficient, scalable processing of revocations in the short term is to realize that there are multiple possible ways for revocation information to be retrieved and that the choice of retrieval method can be made on the basis of the reason for revocation.
| |
|
| |
| == Problems to Solve ==
| |
|
| |
| Here are some of the issues that we hope to address very soon.
| |
| * Currently revocation of intermediate certificates is only checked during EV validation. Sadly, the intermediates we do check revocation for (EV) are the ones that are the least likely to cause our users security problems.
| |
| * The CA learns the IP address, location, a subset of the user's browsing history, and other sensitive information about the user through the OCSP to its servers.
| |
| * Revocation checking through OCSP and CRL requests is way too slow.
| |
| * Many captive portals with HTTPS login pages work very poorly in Firefox because it stalls for 30+ seconds waiting for the OCSP response for the captive portal that is being blocked by the captive portal until the user logs in.
| |
| * If revocation checking via OCSP/CRL fetching for an EV certificate fails, then EV treatment is not given, which may cause confusion. This is particularly problematic for cases when a web app is designed to be used offline (e.g. using AppCache), but even normal websites are affected by this. This inconsistency in the security indicators devalues the security indicators.
| |
|
| |
| These problems can be solved, but they cannot be solved overnight, and they cannot be solved without cooperation from our partners on the internet: certificate authories and websites. We need to quickly provide our partners with useful and working tools, so they can adapt to improve the security of the internet. The most achievable way to do this is to stretch existing, already-standardized and easily-deployable (if not already widely-deployed) mechanisms so that they actually address our users' needs in a reasonable way.
| |
|
| |
|
| == Changes '''Completed/Released''' == | | == Changes '''Completed/Released''' == |