376853 - Option to warn user when site certificate uses intermediate certificates

Status: RESOLVED WONTFIX

(Core Graveyard :: Security: UI, enhancement)

Description

[David E. Ross]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070222 SeaMonkey/1.1.1 Mnenhy/0.7.5.0
Build Identifier: 

Users should have an option to be warned if a secure Web site uses a site certificate that was signed, not by a root certificate in the browser database, but instead by an intermediate certificate.  This option should allow the user to indicate the number of intermediate certificates allowed before the warning appears.  The warning should include buttons to allow the user to continue or cancel viewing the site.  

Reproducible: Always




I went to check a bank statement on the Web.  The bank's Web site had a site certificate that was signed by a Network Solutions intermediate certificate.  The Network Solutions certificate was signed in turn by a USERTRUST Network intermediate certificate.  The USERTRUST Network certificate was signed by an AllTrust root certificate (not by a USERTRUST Network root certificate).  

Neither the Network Solutions certificate nor the USERTRUST Network certificate are in the Mozilla database.  (The USERTRUST Network intermediate certificate is NOT one of the five root certificates in the database.)  Neither Network Solutions nor USERTRUST Network are listed by WebTrust.  

The AllTrust root certificate is in the Mozilla database.  AllTrust is part of Comodo, which has a WebTrust seal.  

AllTrust and Comodo do not control Network Solutions or USERTRUST Network.  The WebTrust seal for Comodo does not apply to Network Solutions or USERTRUST Network.  Thus, my bank's site certificate is at the end of the chain AllTrust > USERTRUST Network > Network Solutions > bank.  This creates a questionable level of trust in the bank's Web site.  

Since certificate authorities often use intermediate certificates to sign site certificates, there is a need to trust such chains at least three links in length.  However, four or more links in length might raise concerns.  The length of a chain of trust should be something the user can control.

Comment 1

[Nelson Bolyard (seldom reads bugmail)]

David, I think this says that you really don't trust our root CAs after all.

The PKI model really depends on trusting the CAs to control their subordinate 
issuers at all levels.  If a root CA proves unworthy in that regard, we should expunge its cert from our list.
  
In the example you cited, did AllTrust violate their CP or CPS by allowing
this chain to have been created?  Did they not exercise appropriate controls
over the issuing practices of their subordinate CAs?  

Comment 2

[David E. Ross]

Yes, I'm suspicious.  AllTrust (Comodo) might have some control over how USERTRUST Network operates with an AllTrust-signed certificate.  But how much control does AllTrust have over Network Solutions?  After all, there was no direct dealing between AllTrust and Network Solutions.  

If the chain I observed were 8 "links" long instead of 4 (AllTrust > USERTRUST > Network Solutions > my bank), should I not be suspicious?  In the OpenPGP "Web of Trust" model, users are cautioned about relying on too long a chain of trust.  That is why a web is used, in which each key is signed by several partially trusted signers instead of only one signer.  

Comment 3

[Jesse Ruderman]

Is this the same as bug 402846?

Comment 4

[David E. Ross]

No, this is not the same.  This one is about a chain of presumably valid certificates -- root, intermediate, intermediate, ... , server -- all properly configured.  My concern arises when an intermediate certificate is owned by an outside party (not the certificate authority (CA) that owns the root).  That outside party is then issuing and signing the site certificate.  While the root's CA should exert some control over the activities of the intermediate's CA, that might not be as thorough as the root's CA's own internal controls.  

Bug 402846 is about misconfigured servers where required intermediate certificates are missing.  See bug 390835 for an example of what happens in this situation.  

Comment 5

[Johnathan Nightingale [:johnath]]

I understand your concern here, absolutely.  Our current trust model lets CAs delegate to the Nth degree, and while I don't know of any incidents where that trust has overextended and created an issue, it's certainly the case that multiplying issuers multiplies risk, mathematically.

On the other hand, as you know, the PKI trust model for an end-user browser implicitly assumes that the vast majority of our users will not wish to make, or maybe even be capable of making, certificate trust decisions.  That's why we ship with default roots in the first place, of course.  Introducing an alert like this would not help users make better decisions, since they aren't equipped to evaluate the issuing policies of CAs or their subordinates.

I think the added control you describe here would be great extension fodder; like NoScript or Greasemonkey, it would allow expert users to self-identify, and take more control over their browsing experience.  But for the broader deployed PSM/NSS in general, or for, e.g. Firefox in particular, I don't think the functionality it introduced would be something most users would benefit from or even understand.  I think we police that risk, instead, by making sure root CAs know that bad certs issued from a subordinate still chain to them, and that they have an obligation to quality there, with the stick of cert revocation to back that obligation up.  I will say that thus far, the record of the CAs on this front has been pretty positive.

This isn't my component, but even understanding your concern, I'd recommend WONTFIX here for the core codebase, though like I say, it sounds like good fodder for an extension, unless NSS makes that functionality hard to access.  If it does, maybe the right move is to morph this bug into one that tracks the request for good APIs here, to allow extension authors to do things like you describe.

Comment 6

[David E. Ross]

I requested this as an option.  It would be quite acceptable if the default option were to disable the capability, allowing the user to enable it.  

Since the use of intermediate certificates is becoming the convention instead of the exception, I would use this capability by (1) enabling it (of course) and (2) setting the length of chain at which warnings are issued at 4.  The latter would allow (root > intermediate > site) without any warning but warn with (root > intermediate-1 > intermediate-2 > site).  If I get an abundance of warnings, I would then re-evaluate my settings and possibly use 5 instead of 4.  At the same time, I would communicate with the site owners to question why they are not dealing directly with the root CA.  

Comment 7

[Eddy Nigg (StartCom)]

David, at this stage I'd suggest to read all CP/CPSs of each CAs mentioned above, in order to find out how they deal with subordinate CAs, starting from the root up to the EE issuance policy. If you find a problem in one of these, than you should report it to the dev-security mailing list.

Maybe you'd also suggest an addition/change to the Mozilla CA policy if this practice will grow into an uncontrollable problem. The fact that the PKI model supports it doesn't makes it automatically right for the user base and Mozilla as relying parties. The same way as self-signed certificates aren't accepted as "trusted" certificates, even so they do exist in PKI very much.

Basically this could outgrow the possibilities of the team governing and reviewing the CA root certificates in NSS, hence a limitation could make sense. A review of this situation might be perhaps the best way to get started...

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

The problem I have with this bug is that it says, in effect "MAYBE there is 
a problem here, and Mozilla should do something about it."

Now, either there is a problem here, or there isn't.  Either the contractual
relationships exist between the relevant CAs in that cited cert chain, which
effectively carry the necessary obligations on all the relevant CAs, or they
do not.  But we don't know which.  Right now, we just have worry.

David, I suggest that you investigate this by contacting all the relevant 
CAs.  If their responses clearly indicate that the expected contractual 
relationships are not in place, then this bug is valid, and action should be
taken.  Else it isnt.  

I think this bug should be resolved as "incomplete" until such time as we 
KNOW there is a problem there.

Comment 9

[David E. Ross]

My bank changed its site certificate again.  Now, I cannot identify the specific certificates involved in the situation that prompted this bug report.  

From a security standpoint, that's fortunate.  From a bug analysis standpoint, that's unfortunate.  

I believe the RFE remains valid given the recent concerns about "sub CAs" as debated in <news://news.mozilla.org:119/mozilla.dev.tech.crypto> regarding bug #371362.  However, this RFE might better address the concerns about "sub CAs" if it included disabling the feature when the issuer of all intermediate certificates is also the issuer of the root certificate.  

Comment 10

[Eddy Nigg (StartCom)]

To reproduce what your bank had in place previously, you can go to https://www.networksolutions.com/

Comment 11

[David E. Ross]

Reopening.  If this is to be marked "Wontfix", justification should be provided in a comment.  

In the meantime, this RFE addresses an issue about which concern appears to be growing.  See the various discussions in <news://news.mozilla.org:119/mozilla.dev.tech.crypto> and in several of the bug reports under mozilla.org:CA Certificates.  

Comment 12

[Johnathan Nightingale [:johnath]]

(In reply to comment #11)
> Reopening.  If this is to be marked "Wontfix", justification should be provided
> in a comment.  
> 
> In the meantime, this RFE addresses an issue about which concern appears to be
> growing.  See the various discussions in
> <news://news.mozilla.org:119/mozilla.dev.tech.crypto> and in several of the bug
> reports under mozilla.org:CA Certificates.  

Comment 5 provides the the thinking behind the WONTFIX.  Your response that this can be an option which is turned off by default isn't a very attractive approach, since it means adding significant code to a sensitive area which will then need to be maintained, for what I consider to be an interesting, and legitimate, but decidedly boundary use case.

Doing this kind of thing as an add-on creates an avenue for sophisticated users to take more direct control of their experience, but we should not be in the habit of landing new functionality which is disabled, and which we don't expect the vast majority of users to ever encounter.

I appreciate the thoughtfulness in your request, and your attention to detail, but it's a niche that is better served by interested parties maintaining a contained piece of code than by adding it to the mozilla tree, deactivated.