378138 - Obviate patented CRLDP extensions

Status: RESOLVED INVALID

(Core :: Security: PSM, enhancement)

Description

[Masahiro YAMADA]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; ja; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

When accessing SSL web site that certificate is already listed in CRL,
Firefox does not create warning.


Reproducible: Always

Steps to Reproduce:
1.Access https://www.gootencash-sys.jp/gootencash/mem_register.php
2.

Actual Results:  
Firefox does not create any warning.
But IE7 blocks to access.


Expected Results:  
Firefox should create SSL warning.

Comment 1

[Daniel Veditz [:dveditz]]

Firefox supports CRL's: enter http://crl.verisign.com/Class3SoftwarePublishers.crl in the location bar and go through the CRL importation wizard and then the gootencash site will show up as revoked.

But Firefox does not appear to ship with any CRL's by default (on the options dialog, Advanced icon, Encryption tab, "Revocation lists" button). I don't know why. There must be some reason, otherwise it seems only sensible that we should have a CRL for each CA we support. Unlike OCSP which causes problems when the server is unavailable, a periodically updated CRL seems much better than nothing.

Sounds like I'm asking for bug 161811 which got closed WFM but not by any of the crypto guys.

Of course which CRLs would you include by default? Verisign alone has bunches of 'em: http://crl.verisign.com/

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

When I visit the page cited in comment 0, I get this error message:

> An error occurred during a connection to www.gootencash-sys.jp.
> Could not establish an encrypted connection because the site uses a 
> certificate that has been revoked. (sec_error_revoked_certificate)

CRLDPs are PATENTED.  We've been trying to get a license worked out for 
a long time now.  So, I don't think there will be much progress on this
for a while.  

In the meantime, mozilla clients have a way to manually "prime the pump", 
manually configuring the client to fetch CRLs for any given CA.  

Comment 3

[Daniel Veditz [:dveditz]]

By "Mozilla Clients" you mean software like Firefox, or the users? The users aren't going to do it, they don't even know CRL's exist let alone that they'd have to do something manually. If you mean the client software that's what 161811 seemed to be requesting, and why I put this bug in Core/Security:PSM rather than product NSS.

I guess you mean we could ship with preset security.crl.autoupdate.* prefs. Trying to figure out what needs to go in there would be quite a chore (Hi, Gerv!).

I wonder if doing this would have implications for our EULA and/or privacy policy. If we preinstall CRLs users will eventually hit 3rd-party servers for updates and we might have to disclose that. (Ditto if we turn on OCSP for EV certs.)

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

There is actually a UI by which users can manually download the first 
CRL from a CA, thereby priming the pump for automatic updates.  
I'm not aware that a comparable thing can be done with prefs, but maybe
it can.  I have no objection to that.  :)

I don't think this bug needs to remain "security sensitive".  
This behavior is not previously unknown to us.  It is in fact by design.
It is a consequence of the patent.  

Comment 5

[Masahiro YAMADA]

(In reply to comment #4)
> I don't think this bug needs to remain "security sensitive".  

I agree. At first, I thought it may be security sensitive.

But, this behavior seems to be same as using IE with unchecking
"Check for server certificate revocation (requires restart)".
And in Japan, It is already well-known because some very famous websites about security information have already written about this behavioir.

Comment 6

[Nelson Bolyard (seldom reads bugmail)]

Dan, if you visit a URL to download a CRL, such as 
http://www.trisk.com/Ordania_MUD_CA_expired.crl
you should see a dialog box that says:

> CRL Import Status
>   The Certificate Revocation List (CRL) was successfully imported.
> 
>   CRL Issued By:
>   Organization: Ordania MUD
>   Unit: Certificate Authority Root
> 
>   Next Update On:  2007-03-22
> 
>   Automatic Update is not enabled for this CRL.
>   Would would like to enable automatic update?
> 
>            [Yes]       [No]       [Help]

Clicking the Yes button will bring up a second dialog box, which says:

> Automatic CRL Update Preferences
>   [ ]   Enable Automatic Update for this CRL
>
>   (.)   Update [  1 ]  Day(s) before Next Update date
>   ( )   Update every  [  1 ]  Day(s)
> 
>   CRL would be imported From:
>     [                                               ]
> 
>   Previous Consecutive Update Failures: None
>            [OK]        [Cancel]        [Help]

(I'm surprised it doesn't fill in the URL into the box for the
update URL.)  

This is the manual alternative that we provide for CRLDPs.

This bug may be a duplicate of bug 133191.

Comment 7

[Daniel Veditz [:dveditz]]

Yes, I've seen that UI (see my comment 1). It might be useful for adding the crl that goes along with a manually installed root cert. It doesn't do anything to solve the problem for the vast majority of users who

 - don't know what CRL's are
 - don't know they need to add them manually
 - have no way of finding which CRL urls they need
 - even if they did, aren't going to have the patience to walk through
   that UI 50 times to install CRLs for all the roots we ship with

Comment 8

[Daniel Veditz [:dveditz]]

If you think you want to close this bug as a duplicate of bug 133191 why not instead morph this bug into "Ship Mozilla clients with pre-installed CRLs", which could be done with alternate mechanisms to supporting CRLDP.

Tedious as it would be, it looks like we could ship with the prefs at http://lxr.mozilla.org/mozilla/source/security/manager/ssl/src/nsCRLInfo.h#45
(that entire set for each CRL -- those are prefixes). Is that right, Kai?

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

Sorry, the proper duplicate would be bug 321755.  

I agree that manually importing a CRL isn't satisfactory for Joe User.
I don't think we want to preload mozilla clients with actual copies of
the CRLs, but it might make sense to preload them with the URLs with 
which to download and auto-update those CRLs.

I'll morph this bug as Dan suggested in comment 8.

Comment 10

[Julien Pierre]

Dan,

Having the CRLs for the roots doesn't really matter much. There are usually some intermediate certs involved in certs chains. Most server or user certs are not directly issued by a root. Without CRL DPs, for client applications, CRLs are really useless. And actually, CRLs are meant for servers who need to cache the information anyway. They are large and not scalable. Clients are usually better off using OCSP, especially now that there is a cache. Fortunately, there is no patent on the AIA extension, which points to the URL of the OCSP server to use.

Comment 11

[Kai Engert [:KaiE:]]

I think we should convince CAs to support OCSP as soon as possible.

I tend to agree with Julien, the approach to pre install CRL URLs would be incomplete and add unnecessary overhead.

Comment 12

[Nelson Bolyard (seldom reads bugmail)]

Removed suggestion of pre-installing CRL URLs from the summary.

Comment 13

[Jakob Bohm]

(In reply to comment #10)
> Dan,
> 
> Having the CRLs for the roots doesn't really matter much. There are usually
> some intermediate certs involved in certs chains. Most server or user certs are
> not directly issued by a root. Without CRL DPs, for client applications, CRLs
> are really useless. And actually, CRLs are meant for servers who need to cache
> the information anyway. They are large and not scalable. Clients are usually
> better off using OCSP, especially now that there is a cache. Fortunately, there
> is no patent on the AIA extension, which points to the URL of the OCSP server
> to use.
> 

OCSP is a giant privacy violation (The 3rd party OCSP server sees every end user access to any site that purchased its SSL cert from that issuer), and as such is a non-starter and something to ALWAYS disable by default.

Caching of received OCSP status of certificates does almost nothing to help this.  It only prevents the OCSP spyserver from seeing how many visits each user makes to the SSL site within the short lifespan of its own response.  The OCSP server still sees who accesses which SSL sites in each OCSP-server defined time slot, plus the exact starting time of the first access by each user in each time slot.

Using the existence of OCSP as an excuse for not handling CRL properly is thus a false and invalid argument, and will remain so forever.

Comment 14

[Julien Pierre]

Jakob,

We are not using OCSP as an excuse for anything. We have plans to handle CRLs properly with CRL DP. Your alternate proposal is simply impractical.

Comment 15

[:Cykesiopka]

Bug 867465 removed the CRL UI from Firefox, and in general, Firefox no longer supports CRL.
=> INVALID