307234 - regression: TLS Domain Name Mismatch w/SSL certificate with multiple CN's

Status: VERIFIED INVALID

(Thunderbird :: Security, defect)

Description

[Paul Traina]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Thunderbird v1.6a1 (20050901)

This works just fine in 1.0.6.

When connecting to a mail server that has multiple names, and therefore has an
X.509 certificate with multiple valid CN entries in it, Thunderbird appears to
not check all of the CN entries before emitting a domain mismatch dialog box.


Reproducible: Always

Steps to Reproduce:
1. create a sever with multiple names, and a cert with multiple CN entries, like
the following:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 12 (0xc)
        Signature Algorithm: md5WithRSAEncryption
        Issuer: C=US, ST=California, L=San Francisco, O=Traina & Associates, LLC
, OU=shockwave.org, CN=Shockwave Engineering CA/emailAddress=[e-mail]
        Validity
            Not Before: Apr 21 17:57:07 2005 GMT
            Not After : Apr 21 17:57:07 2015 GMT
        Subject: C=US, ST=California, O=Traina & Associates, LLC, OU=shockwave.o
rg, CN=protempore.shockwave.org, CN=www.shockwave.org, CN=shockwave.org/emailAdd
ress=[e-mail]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
            RSA Public Key: (1024 bit)
                Modulus (1024 bit):
                    00:c2:22:e3:ff:48:d1:94:e0:f7:fa:c1:1c:c3:22:
                    31:4b:78:80:49:8c:82:5a:3d:1e:8f:a5:69:32:b3:
                    bc:31:05:d9:97:4b:cd:37:63:67:96:91:b4:64:fc:
                    47:5b:e1:5e:51:7b:52:0e:54:10:10:15:b8:3d:18:
                    86:ac:ae:50:10:34:40:dc:1d:db:d8:7c:b3:20:44:
                    f3:61:04:e1:db:48:91:a9:0a:3f:fa:55:3f:1e:b3:
                    43:f3:27:f0:2b:8e:ae:2b:fc:2a:df:91:94:e4:3f:
                    a0:11:e7:e8:a1:a9:42:94:30:42:8d:1c:d7:fa:11:
                    dd:69:f0:99:28:d2:d8:23:a9
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Comment: 
                OpenSSL Generated Certificate
            X509v3 Subject Key Identifier: 
                88:EC:0A:2C:B2:F2:46:6A:83:E3:BF:BC:82:46:AE:6C:F9:D3:28:CD
            X509v3 Authority Key Identifier: 
                keyid:5E:C5:B3:CF:D1:50:00:C3:10:D9:05:4F:F6:49:FD:66:71:83:58:8
6
                DirName:/C=US/ST=California/L=San Francisco/O=Traina & Associate
s, LLC/OU=shockwave.org/CN=Shockwave Engineering CA/emailAddress=[e-mail]
g
                serial:00

    Signature Algorithm: md5WithRSAEncryption
        85:90:8a:e2:54:94:eb:1e:a3:65:c8:01:f9:3c:ce:56:1c:1a:
        93:44:a3:3b:ff:06:33:d0:76:3a:63:d0:91:97:6c:1c:56:e1:
        92:e8:07:77:ce:9d:06:39:02:a9:1f:d0:ca:46:98:02:82:fc:
        7b:c2:8b:9f:c1:96:2f:e9:5a:10:f8:37:f7:8b:bd:b8:a0:0d:
        43:45:73:d6:e7:ee:fe:dc:7c:a5:cf:fe:d7:33:af:d6:3a:fd:
        23:b1:70:2b:bb:2e:00:c2:69:99:ef:a8:73:46:f4:6f:38:a5:
        7f:d0:3e:c6:ac:9a:be:09:12:74:a4:4a:ae:e6:6d:fd:53:8c:
        c7:01

2. configure Thunderbird to connect to the imap sever listed as one of the CN's,
but NOT the last CN in the cert (e.g. protempore.shockwave.org) with TLS required

3. start thunderbird

Actual Results:  

When I start Thunderbird, I get the "Security Error: Domain Name Mismatch"
dialog box.  You have attempted to establish a connection with
"protempore.shockwave.org". However, the security certificate presented belongs
to "shockwave.org".  It is possible, though unlikely, that someone may be trying
to intercept your communication with this web site...

Expected Results:  
Check all possible CN's listed int he X.509 certificate, if any of them match,
there is not a domain name mismatch condition, do not emit the warning message.

I suspect this should be refiled against the common SSL/TLS module in firefox,
but I wanted to make sure it was understood this is a major tbird annoyance and
a regression since 1.0.6. :-(

Comment 1

[Scott MacGregor]

This seems like a potenially bad regression from 1.0.x. cc'ing some of the
security/cert gurus in case  they can think of any changes since 1.0 that would
have caused this change in behavior.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

No standard for public key certs has EVER called for using multiple 
CN= fields to all specify multiple different DNS names in a cert.  
No Netscape or Mozilla branded product has *ever* attempted to match 
URL host names against more than one Common Name AVA in the cert. 
AFAIK, no other browser has done that, either.  

RFC 2818 says:

   If a subjectAltName extension of type dNSName is present, that MUST
   be used as the identity. Otherwise, the (most specific) Common Name
   field in the Subject field of the certificate MUST be used. Although
   the use of the Common Name is existing practice, it is deprecated and
   Certification Authorities are encouraged to use the dNSName instead.

Notice the words "most specific".  The cert's subject name is made up of a 
series of fields ("attribute value asertions", AVAs) that form a hierarchy.  
The AVAs are ordered from most general (e.g. country name) to most specific 
(e.g. individual name), Although they are commonly displayed in reverse 
order (most specific first, most general last).  When an attribute type 
appears in more than one AVA in the subject name, one of those AVAs 
(generally the last one listed in the cert) is the "most specific" AVA 
for that attribute type.  The RFC quoted above clearly says that the
most specific common name must be used, but only when no subjectAltName 
extension of type dNSName is present.  

So, If a cert wants to have multiple DNSnames, it must put them into a
SubjectAltNames (SAN) extension, not into multiple CN AVAs.  It must put 
ALL the DNSnames into the SAN extension, because the Common Name AVA is 
not used at all when the SAN extension of type DNSname is present.

Mozilla has been following (or attempting to follow) RFC 2818 for years.
At one time, mozilla  mistakenly used the least specific Common Name,
rather than the most specific common name, when multiple CNs existed, 
but that was fixed quite a whiel ago.  Today mozilla follows RFC 2818 
and RFC 3280 rather carefully with respect to DNSname matching.  

Conclusion: If you want a cert to contain multiple names, and want 
standards compliant client products to honor all the names, put the 
DNSnames into the certificate's SAN extension, in the DNSname member(s). 

Comment 3

[Wan-Teh Chang]

I believe this is caused by the fix for bug 197964,
where we changed how we pick a CN if the Subject field
has multiple CN's.  We used to pick the first CN.
Starting in NSS 3.10 (in which bug 197964 was fixed),
we pick the last CN (the most specific one).

Thunderbird 1.0.x is using NSS 3.9.x.

Thunderbird 1.5 Beta 1 and its trunk (v1.6a1) are using NSS 3.10.x.

So all of the above can explain what Paul reported in
"Actual Results".