412277 - Are there additional SSL errors we should allow to override?

Status: RESOLVED WONTFIX

(Core :: Security: PSM, enhancement)

Description

[Kai Engert [:KaiE:]]

from bug 407523 comment 13:


    are there additional SEC_ERRORs/SSL_ERRORs where PSM should allow to add 
    an override? Currently, nsNSSBadCertHandler in nsNSSIOLayer.cpp deals 
    with these seven:
    
     SEC_ERROR_UNKNOWN_ISSUER
     SEC_ERROR_CA_CERT_INVALID
     SEC_ERROR_UNTRUSTED_ISSUER
     SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE
     SEC_ERROR_UNTRUSTED_CERT
     SSL_ERROR_BAD_CERT_DOMAIN
     SEC_ERROR_EXPIRED_CERTIFICATE
    
    I'm not sure if SEC_ERROR_INADEQUATE_KEY_USAGE is really "worse" than these
    (and would therefore justify to reject the cert completely vs. allowing 
    to add an override).


This bug shall be used to collect error codes we might allow to override in addition to the ones listed above, such as SEC_ERROR_INADEQUATE_KEY_USAGE.

In particular, for each new override scenario we must make sure we assign the error code to one of the existing 3 categories:
- missing trust of some kind
- not valid at this time
- mismatch
and ensure the generic wording for these categories are appropriate for new added error codes.

New error codes that don't fit in any of these categories would require the introduction of new categories, which would require additional UI work...

Comment 1

[Kai Engert [:KaiE:]]

It appears that testers run into the SEC_ERROR_INADEQUATE_KEY_USAGE very often.

Can we add that error code to our "missing trust of some kind" category, using the same UI strings etc.?

I propose we do.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Kai, please elaborate on your proposal to "we add that error code to our 
"missing trust of some kind" category, using the same UI strings etc.".
(I'm not aware of such categories of error codes.)

What would be the effect of the proposed change?
What UI strings are used with that category?

Comment 3

[Kai Engert [:KaiE:]]

(In reply to comment #2)
> Kai, please elaborate on your proposal to "we add that error code to our 
> "missing trust of some kind" category, using the same UI strings etc.".
> (I'm not aware of such categories of error codes.)

Nelson, let me remind you:

PSM uses 3 groups of error codes it allows to override, where each group matches on of the dialogs that were used in Firefox 2 and older.
The groups are:

- validity time mismatches
  SEC_ERROR_EXPIRED_CERTIFICATE

- domain mismatches
  SSL_ERROR_BAD_CERT_DOMAIN

- trust issues, inability to verify of any kind
  SEC_ERROR_UNKNOWN_ISSUER:
  SEC_ERROR_CA_CERT_INVALID:
  SEC_ERROR_UNTRUSTED_ISSUER:
  SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE:
  SEC_ERROR_UNTRUSTED_CERT:

The proposal is to add SEC_ERROR_INADEQUATE_KEY_USAGE to 3rd of these categories.


> What would be the effect of the proposed change?

???

The effect is that you will be able to override SEC_ERROR_INADEQUATE_KEY_USAGE.
I propose this discussion gets continued in bug 427081, but I hope there isn't a lot of need for discussion.

> What UI strings are used with that category?

We have individual strings for each of the above errors, and some more.

certErrorTrust_SelfSigned=The certificate is not trusted because it is self signed.
certErrorTrust_UnknownIssuer=The certificate is not trusted because the issuer certificate is unknown.
certErrorTrust_CaInvalid=The certificate is not trusted because it was issued by an invalid CA certificate.
certErrorTrust_Issuer=The certificate is not trusted because the issuer certificate is not trusted.
certErrorTrust_ExpiredIssuer=The certificate is not trusted because the issuer certificate has expired.
certErrorTrust_Untrusted=The certificate does not come from a trusted source.

The error message chosen from the set of above alternatives depends on the error code returned by NSS. PSM might decide to use the self-signed error message when it detects such a cert.

Lacking better options, the proposal in bug 427081 is to fall back to error string with ID certErrorTrust_Untrusted.

While this might not be 100% descriptive, IMHO it's acceptable.

Also note, in addition to the string, the error page will still list the (first) error code reported by NSS (as usual)...

Comment 4

[Nelson Bolyard (seldom reads bugmail)]

Thanks for that explanation, Kai.  
I didn't realize that FF3 was still using the old error categorization 
of FF2. 

I would say that the error string certErrorTrust_CaInvalid is the most apt
of the above strings for SEC_ERROR_INADEQUATE_KEY_USAGE

Comment 5

[Kai Engert [:KaiE:]]

(In reply to comment #4)
> I would say that the error string certErrorTrust_CaInvalid is the most apt
> of the above strings for SEC_ERROR_INADEQUATE_KEY_USAGE

Thanks Nelson, I'll attach an updated patch to bug 427081 in a moment.

Comment 6

[t35t0r t35t0r]

Being able to add an exception for sites that return the sec_error_inadequate_key_usage SSL error would be nice. At the moment with the following browser:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

For example, I can't connect to the CUPS (common unix printing system, v1.2.4, as used in RedHat 5) admin page because it uses a self signed SSL cert. I can't add an exception either.

Comment 7

[Kai Engert [:KaiE:]]

t35t0r: that will be fixed in Firefox 3 RC 1, see comment 5 in this bug and bug 427081.

Comment 8

[t35t0r t35t0r]

indeed, it is fixed in rc1

Comment 9

[Kai Engert [:KaiE:]]

reassign bug owner.
mass-update-kaie-20120918

Comment 10

[:Cykesiopka]

As of the time of this comment, there doesn't seem to be a need to make more errors overridable.

If it becomes necessary, a new bug can/will be filed instead.