645683 - Remove "Do you want to enable auto-update" prompt for CRL import

Status: RESOLVED INVALID

(Core :: Security: PSM, defect)

Description

[Gervase Markham [:gerv]]

If you visit a CRL URL, such as:
http://crl.comodoca.com/UTN-USERFirst-Hardware.crl
then Firefox automatically imports the CRL, then says "do you want to enable auto-update?".

This is bad for a few reasons:

- It turns the idea "improve your safety by importing this CRL" into a "click this URL and say Yes in the resulting dialog" - which is something people are supposed to _not_ do

- The user has no way of making the decision - most won't know what it means, and those who do have no evidence to make the decision (e.g. the size or update frequency of the CRL).

We should default to auto-updating. CRLs are pretty useless otherwise anyway. Once we have download-on-demand, we could consider defaulting to not auto-updating.

Gerv

Comment 1

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I believe that any time we would say "improve your safety by importing this CRL," we should instead automatically push the CRL to the user during update checking.

Auto-updating means telling the CRL signer the user's location on a regular basis, and silently downloading and storing files of unbounded (?) size on the user's device.

That said, I agree that the current UI is not comprehensible for most people.

Comment 2

[Daniel Veditz [:dveditz]]

Push all possible CRLs for every root in our trust store? That's crazy, I hope you meant just the ones the user encounters. So the mechanism would have to include the client telling us which CRLs it wants (easy enough: https://crl.mozilla.org/fetch?url=<crl-url-from-cert>

(In reply to comment #1)
> Auto-updating means telling the CRL signer the user's location on a regular
> basis,

Better than OCSP, at least most of the time you're not also telling the CA which site you're visiting (unless CAs start using unique CRL URLs per cert).

> and silently downloading and storing files of unbounded (?) size on the
> user's device.

I don't see how getting it from us instead of the CA helps any on that score. I guess we could hack up some diff mechanism (maybe using the date of last download?) to at least help shrink the transfer size. Won't help the storage problem. We probably have to use different defaults for Desktop and Mobile.

If we had such a mechanism we could prefer CRLs to OCSP for many site visits to increase privacy. When we encounter a new cert/site see if we already have the CRL downloaded and use that if "fresh enough". If not, use OCSP and simultaneously fetch the CRL so we have it for next time.

Comment 3

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

(In reply to comment #2)
> Push all possible CRLs for every root in our trust store?

No, I mean in every case that we would recommend that a user download/install a CRL, we should instead just push that CRL during update checking. 

> That's crazy, I hope you meant just the ones the user
> encounters.

It might not be so crazy to have the user download all the CRLs for (nearly) every root during update checking. We might be able to package the (nearly) full set of CRLs with each Firefox release, and then have the update check return a diff/delta of each CRL plus the signatures. It looks like it would require some special casing for some degenerate (huge) CRLs, some pruning of old roots, and/or some cooperation on the part of some CAs with multiple roots to provide combined CRLs, but right now it doesn't look totally infeasible.

> https://crl.mozilla.org/fetch?url=<crl-url-from-cert>

I would like to avoid doing that, if possible, because it would leak to Mozilla some (coarse-grained) information about what websites the user is visiting.

> (In reply to comment #1)
> > Auto-updating means telling the CRL signer the user's location on a regular
> > basis,
> 
> Better than OCSP, at least most of the time you're not also telling the CA
> which site you're visiting (unless CAs start using unique CRL URLs per cert).

(Whole-chain) OCSP stapling seems like the best as far as privacy, followed by Mozilla-proxied CRL updates, followed by CRL auto-updating, followed by on-demand OCSP. 

> > and silently downloading and storing files of unbounded (?) size on the
> > user's device.
> 
> I don't see how getting it from us instead of the CA helps any on that score. 

If we are proxying the CRLs, we can implement a maximum CRL size at which we may decide to take other measures (e.g. killing the trust of the root and/or of a specific intermediary associated with the revoked certs.) and/or require Firefox to use OCSP instead of CRLs for that CA. We would also be able to throttle the downloading of the CRL updates up or down depending on our knowledge of a critical mis-issuance and/or performance issues.

> We probably have to use different defaults for Desktop and Mobile.

I would like to avoid that, if at all possible, but that is definitely an option. 

> If we had such a mechanism we could prefer CRLs to OCSP for many site
> visits to increase privacy.

I think we will be able to do this, at least for the majority of CAs in our program (and thus, the vast majority of websites).

> When we encounter a new cert/site see if we already have the CRL
> downloaded and use that if "fresh enough".  If not, use OCSP and
> simultaneously fetch the CRL so we have it for next time.

I am hopeful that we will be able to avoid the client contacting the CA's website at all in the vast majority of cases.

Comment 4

[Gervase Markham [:gerv]]

(In reply to comment #1)
> Auto-updating means telling the CRL signer the user's location on a regular
> basis, and silently downloading and storing files of unbounded (?) size on the
> user's device.

Yes, CRLs suck.

(In reply to comment #2)
> Better than OCSP, at least most of the time you're not also telling the CA
> which site you're visiting (unless CAs start using unique CRL URLs per cert).

Yes, OCSP sucks.

> guess we could hack up some diff mechanism (maybe using the date of last
> download?) to at least help shrink the transfer size. Won't help the storage
> problem. We probably have to use different defaults for Desktop and Mobile.

The relevant spec for CRLs does have a diff mechanism (I believe it's called "delta CRLs") but I don't know much about it.

Gerv