469533 - FireFox 3.0.6 only processes 'Last' CN in x509 certificate when multiple CNs are present - ssl_error_bad_cert_domain

Status: RESOLVED INVALID

(NSS :: Libraries, defect)

Description

[JP Senior]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

Only the last CommonName in a certificate with multiple CNs is processed.  
x509 snapshot:
Certificate:
    Data:
        Version: 1 (0x0)
        Serial Number:
            88:6c:24:e5:0f:8b:37:1e
        Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=CA, ST=Alberta, L=Calgary, O=Mistrust, CN=mistrust.ca, CN=*.mistrust.ca, CN=172.16.60.5
        Validity
            Not Before: Dec 14 07:12:17 2008 GMT
            Not After : Dec 14 07:12:17 2009 GMT
        Subject: C=CA, ST=Alberta, L=Calgary, O=Mistrust, CN=mistrust.ca, CN=*.mistrust.ca, CN=172.16.50.5
<snip>

Reproducible: Always

Steps to Reproduce:
1. Create CA certificate file for import
2. Import certificate into Firefox 3 for "Web" usage - no other options selected
3. Visit http://mistrust.ca
Actual Results:  
Upon browsing: 
mistrust.ca uses an invalid security certificate.

The certificate is only valid for 172.16.60.5

(Error code: ssl_error_bad_cert_domain)


Expected Results:  
Expected to have a valid HTTPS Session.  The certificate should also process the other CNs in the domain, IE "mistrust.ca" and "www.mistrust.ca".

I am not sure if this done by RFC or design.  The closest report I found of anything similar to this is found on bug #469263.
I was attempting to create a single cert to work for 'mistrust.ca' and '*.mistrust.ca', since a wildcard certificate does not work for the TLD.  (Is this another bug?)

Comment 1

[JP Senior]

A bit of more info - I found a post from dev-tech-crypto http://groups.google.com/group/mozilla.dev.tech.crypto/browse_thread/thread/6c42f4d254674391/158fac07bc1326a1?lnk=gst&q=Multiple+CN#158fac07bc1326a1 that discusses potential vulnerabilities when addressing multiple CNs in a certificate.  RFC 5280 does specify the SubjectAltName that I think I will be most appropriate assuming Firefox supports it, however, the "bug" is still here.

The archives list a very good security point; A phisher could intentionally create a certificate authorative for multiple domains, ie, site.intranet.com and bank.com - so it makes sense that only one CN is imported, but what doesn't make sense is that only the last one is imported.  That should make the entire certificate unreliable, not just the last FQDN.  The "administrator fix" is to release the proper certificates for the proper host names, or make use of SubjectAltName but the vulnerability still appears to be possible - A user could be tricked into accepting a certificate as authorative for site.com as per the CN chain, but only the last CN is processed when visiting a site.

I could recommend that the entire certificate be marked invalid.

Comment 2

[Johnathan Nightingale [:johnath]]

I'm not sure what mechanism would permit the attack you describe - tricking a user into, for instance, adding a security exception to trust a given cert in Firefox would not trust that cert for other domains, regardless of the claims made in the certificate.  If it did, as you mention, subjectAltName would be just as viable a vector.

As to whether the cert should be treated as invalid - I'll defer to the PSM/NSS folks who know the relevant specs much better than I, but given that the use of CN for domain information is already a hack, I would not be surprised to learn that there isn't any formal guidance anyhow.

Kai - it isn't clear to me if the choice of whether to "accept" a given CN for a given cert and domain is a PSM-level policy decision or an NSS-level parsing decision, so I'm bouncing to PSM, to be rebounced to NSS if that's more appropriate.

Comment 3

[timeless]

it would have helped had you attached the .crt ....

afaict the current CA cert from mistrust.ca is not broken.

Comment 4

[JP Senior]

Example certificate is still at http://mistrust.ca/ca/FireFox3Example.crt

The certificate on the real site isn't relevant to this conversation, as I've repaired a broken configuration.  I'm reporting a potential bug with firefox based on multiple CNs.  The certificate at mistrust.ca/ca/cacert.crt is fine with the SubjectAltName attribute.
Issuer details:

CN = 172.16.60.5
CN = *.mistrust.ca
CN = mistrust.ca
O = Mistrust
L = Calgary
ST = Alberta
C = CA

(In order, CNs are mistrust.ca, *.mistrust.ca, 172.16.60.5).

To Johnathans point, subjectaltname is also just as viable as an attack vector (IE, certificate reports to be valid for site.intranet.com, since the browser looks at the CN first when importing a valid certificate, but SubjectAltName instead says bank.com).

If this is a nonissue we may as well close this bug.

Comment 5

[timeless]

Attachment: http://mistrust.ca/ca/FireFox3Example.crt

Comment 6

[timeless]

Nelson's comments are approximately this:

Firefox is trying to match the host name portion of the URL (which may 
have been an IP address) with the appropriate portion of the cert, 
according to RFC 2818. 

If the host name portion of the URL was a DNS name, then Firefox is trying 
to match that DNS name with the cert.  If the host name portion of the URL 
was an IP address, then Firefox is trying to match that IP address from 
the URL with the cert.  In NO case does Firefox ever do a forward or 
reverse DNS lookup and then try to match the result of that lookup with 
the cert.  If it did that, Firefox would be vulnerable to DNS attacks. 

If a Subject Alternative Names (SAN, note: plural) extension is present then the CN stuff must be ignored per RFC 5280.

RFC 2818 defines how https clients use the names in certs.  It says that 
the client uses the DNS names and IP addresses in the SAN if the SAN 
extension is present, and otherwise (only if the SAN is not present, or 
contains no usable names) it can use ONE host name from the single 
most-specific CN field in the subject name.  (A subject name can have 
multiple CNs, but one one of them is the most specific one, and that is 
the only one that RFC 2818 allows to be used for a host name.)  The latter 
provision recognizes that this use of CN was never conformant to the X.50x 
standards, and that the SAN extension is *the* standards conformant place 
for such names.  It allows backwards compatibility (use of CN) only when SAN 
is absent (or contains no DNS names and no IP addresses). 

Wildcards are allowed, as specified in RFC 2818.

IP address matches are exact.  No subnet masks apply.  IPv4 and IPv6 
addresses are allowed.  Note that, to match, the IP address in the SAN 
must be encoded in binary, as specified in RFC 5280.  Some CAs make the 
mistake of thinking that an IP address is simply encoded as a DNS host 
name string in the SAN.  That doesn't match.  If the host name in the URL 
is an IP address, then we only check it against binary IP addresses in 
the SAN, and if it's not an IP address, then we only check it against 
the DNS name strings in the SAN. 

... Some cert issuers forget that RFC 2818 
allows the cert's subject CN to be used ONLY when the SAN is absent or 
when it contains no DNS names, so they put most (all but one) of the DNS 
host names into the SAN, and put one DNS name into the CN.  But FF does 
what the standard says, and ignores the CN when the SAN has DNS names. 
So, if you have multiple names, put them ALL into the SAN. 
Some admins worry that there might still exist some browsers that don't 
know about SANs, and that always use CNs, and so those admins desire to 
put a host name in the CN, as well as in the SAN.  You can put ONE host 
name into the CN.  If you do that, it should be in BOTH the CN and in the 
SAN.  Doesn't hurt to appear twice. 

-----
assuming I've snipped things correctly. this bug is invalid, we use the "most specific" CN, not the "Last one", and this is per spec.

I suppose that the certificate viewer could try to highlight which parts of the certificate it's going to ignore. We might accept a patch to do that. Personally, having spent some time working on psm bugs of late, even I won't do that. If you have an interest, feel free to ask for help and try it.

PSM exposes enough information, so if someone wanted to do this, they could. nsIX509Cert.commonName appears to show 172.16.60.5 which matches the requirements described above. It should therefore be possible to modify the code that fills in the Subject and Issuer fields. However, currently the certificate viewer uses a xul:textbox which means the code would require significant retooling to provide something richer.

In theory we could construct:
CN = 172.16.60.5
CN = *.mistrust.ca (ignored)
CN = mistrust.ca (ignored)
O = Mistrust
L = Calgary
ST = Alberta
C = CA

or:
CN = 172.16.60.5
CN(ignored) = *.mistrust.ca
CN(ignored) = mistrust.ca
O = Mistrust
L = Calgary
ST = Alberta
C = CA

anything like this would require significant work w/ l10n and is really overkill IMO.

Comment 7

[Daniel Veditz [:dveditz]]

I believe timeless meant to CC a different nelsonb

Comment 8

[Nelson Bolyard (seldom reads bugmail)]

Thanks for your great explanation, Timeless.

Here's a comment about "last" vs. "most specific".  Timeless is right 
that NSS picks the most specific CN, due to RFC 2818.

Inside the DER encoded certificate, the RDNs (sets of X=Y values) are 
stored from most general first to most specific last, so indeed, NSS 
does select the last CN from the RDNs as they appear in the DER encoded 
certificate, because of the requirement you mentioned in RFC 2818.

But, when the DER encoded names are converted into printable ASCII or UTF8
strings for printing, by convention and by RFC, the order is reversed and
the most specific is generally listed first in that form.  So, when seen 
in string (not DER) form, NSS effectively picks the first CN.  That's why
we avoid the use of the terms "first" and "last" and instead refer to 
"most specific" and "most general".  The terms "first and "last" are 
ambiguous, referring to different things depending on how the data is 
encoded, but the terms "most specific" and "most general" are unambiguous.

Since the relevant code is in NSS, I'm changing this bug into an NSS bug,
but the resolution still stands.