1124410 - Improper validation of certificates with multiple Common Names

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[Ben Reser]

Attachment: Certificate with multiple Common Names

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:35.0) Gecko/20100101 Firefox/35.0
Build ID: 20141229214612

Steps to reproduce:

When presented with a server SSL certificate with a Subject like this:
C=US, ST=Washington, L=North Bend, CN=good.example.com, CN=evil.example.com

Firefox (35.0) will trust the last Common Name it finds.  Per RFC 6125 section 2.3.1 it should not trust any Common Names when multiple Common Names are found.

cert.crt is a certificate with the Subject used as an example above.  cert.key is the key needed to use this cert.  cacert.pem is the CA certificate used to sign the certificate.  Setup a server with this cert/key and import the CA certificate to be trusted in the bwoser.  Setup the hosts file to point good.example.com and evil.example.com to the server that you setup with this certificate.


Actual results:

Visit the server with the CA you've setup above and you will see that evil.example.com is allowed while good.example.com is disallowed.


Expected results:

Per RFC 6125 section 2.3.1 it should not trust any Common Names when multiple Common Names are found.  So this certificate should not be trusted regardless of trust.

Ideally, no Certifying Authority would sign such a certificate and the CA/Browser Baseline Requirements document says they should not sign such certificates in section 9.2.2.  However, clients shouldn't depend on CA's to correctly implement such limitations and should reject these certificates.  

The problem with Multiple Common Names has been known at least since 2009 when Dan Kaminsky presented his "Black OPs of PKI" talk at the 26th Chaos Computer Congress:
https://www.youtube.com/watch?x-yt-ts=1421782837&feature=player_detailpage&x-yt-cl=84359240&v=5DC8FYv-7X0#t=3329

Comment 1

[Ben Reser]

Attachment: Key for Certificate with Multiple Common Names.

Comment 2

[Ben Reser]

Attachment: CA Certificate used to sign Certificate with Multiple Common Names

Comment 3

[Ben Reser]

Should note that other browsers have the same problem so I'm reporting this to other browser vendors as well.

Comment 4

[Matt Wobensmith [:mwobensmith][:matt:]]

David, any thoughts on this?

Comment 5

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

We could probably be more strict and reject certificates with multiple CNs. It would be good to investigate the compatibility impact, however (as I understand it, we implemented it this way to be compatible with the current behavior of other browsers). cc'ing Brian for any further insight he might have.

The real solution is to not fall back to using the subject CN at all (i.e. currently if there's a subject alternative name extension, we just use that and ignore the subject CN), but that's a huge compatibility concern. It will probably be some time before we would be confident in making that change.

(In reply to Ben Reser from comment #0)
> Ideally, no Certifying Authority would sign such a certificate and the
> CA/Browser Baseline Requirements document says they should not sign such
> certificates in section 9.2.2.  However, clients shouldn't depend on CA's to
> correctly implement such limitations and should reject these certificates.  

Misissuance is definitely a concern, but we're not going to be able to stop all attacks that start with "get a CA to sign something they shouldn't". Key pinning and certificate transparency can help here, though.

Comment 6

[Matt Wobensmith [:mwobensmith][:matt:]]

FWIW, I'm happy to run compatibility tests if we ever do consider a change.

Comment 7

[Ben Reser]

(In reply to David Keeler [:keeler] (use needinfo?) from comment #5)
> We could probably be more strict and reject certificates with multiple CNs.
> It would be good to investigate the compatibility impact, however (as I
> understand it, we implemented it this way to be compatible with the current
> behavior of other browsers). cc'ing Brian for any further insight he might
> have.

Pretty confident that compatibility is not a reason for this behavior.

Here is a rough list of browser/http library behavior that I came up with around when I reported this I haven't updated it since:
Firefox 35.0: Trusts the last Common Name.
Chrome 40.0.2214.91: Trusts the first Common Name.
Safari 8.0.2: Trusts all Common Names.
Neon 0.30.1 (OpenSSL or GnuTLS): Trusts last Common Name.
Serf 1.3.8: Trusts first Common Name.

I haven't personally tested Internet Explorer but it apparently it trusts all of the Common Names like Safari.

Unless someone has a mono-culture of browsers/http libraries they can't depend on any particular behavior.
 
> The real solution is to not fall back to using the subject CN at all (i.e.
> currently if there's a subject alternative name extension, we just use that
> and ignore the subject CN), but that's a huge compatibility concern. It will
> probably be some time before we would be confident in making that change.

Total agreement here on all fronts.  

> Misissuance is definitely a concern, but we're not going to be able to stop
> all attacks that start with "get a CA to sign something they shouldn't". Key
> pinning and certificate transparency can help here, though.

I also agree about this but given the random behavior of various clients, I don't see how leaving this hole helps anyone.  I'm very strongly in favor of trusting CAs no more than is required.  

For what it's worth Chromium closed this as WONTFIX on the basis that CA errors are not part of their threat model:
https://code.google.com/p/chromium/issues/detail?id=450768

Comment 8

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

It seems likely we can come to some kind of agreement to make at least Chrome and Firefox consistent with each other.

IIRC, there are real-world certificates that have something like "CN=foo.example.org, CN=Foo Organization." I don't know if any of them chain to root CAs that are in Mozilla's CA program. Compatibility testing would have to be done if mozilla::pkix were to be changed here.

The mozilla::pkix code was written to be consistent with existing code in Firefox. In order to change Firefox's behavior, we'd need to find all the places Firefox calls the NSS CERT_GetCommonName and/or CERT_GetLastNameElement functions, and change those callers to be consistent with whatever change is made.

Opening up this bug as this is well-documented behavior. From the code:

  // Attempt to match the reference ID against the CN-ID, which we consider to
  // be the most-specific CN AVA in the subject field.
  //
  // https://tools.ietf.org/html/rfc6125#section-2.3.1 says:
  //
  //   To reduce confusion, in this specification we avoid such terms and
  //   instead use the terms provided under Section 1.8; in particular, we
  //   do not use the term "(most specific) Common Name field in the subject
  //   field" from [HTTP-TLS] and instead state that a CN-ID is a Relative
  //   Distinguished Name (RDN) in the certificate subject containing one
  //   and only one attribute-type-and-value pair of type Common Name (thus
  //   removing the possibility that an RDN might contain multiple AVAs
  //   (Attribute Value Assertions) of type CN, one of which could be
  //   considered "most specific").
  //
  // https://tools.ietf.org/html/rfc6125#section-7.4 says:
  //
  //   [...] Although it would be preferable to
  //   forbid multiple CN-IDs entirely, there are several reasons at this
  //   time why this specification states that they SHOULD NOT (instead of
  //   MUST NOT) be included [...]
  //
  // Consequently, it is unclear what to do when there are multiple CNs in the
  // subject, regardless of whether there "SHOULD NOT" be.
  //
  // NSS's CERT_VerifyCertName mostly follows RFC2818 in this instance, which
  // 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.
  //
  //   [...]
  //
  //   In some cases, the URI is specified as an IP address rather than a
  //   hostname. In this case, the iPAddress subjectAltName must be present
  //   in the certificate and must exactly match the IP in the URI.
  //
  // (The main difference from RFC2818 is that NSS's CERT_VerifyCertName also
  // matches IP addresses in the most-specific CN.)
  //
  // NSS's CERT_VerifyCertName finds the most specific CN via
  // CERT_GetCommoName, which uses CERT_GetLastNameElement. Note that many
  // NSS-based applications, including Gecko, also use CERT_GetCommonName. It
  // is likely that other, non-NSS-based, applications also expect only the
  // most specific CN to be matched against the reference ID.
  //
  // "A Layman's Guide to a Subset of ASN.1, BER, and DER" and other sources
  // agree that an RDNSequence is ordered from most significant (least
  // specific) to least significant (most specific), as do other references.
  //
  // However, Chromium appears to use the least-specific (first) CN instead of
  // the most-specific; see https://crbug.com/366957. Also, MSIE and some other
  // popular implementations apparently attempt to match the reference ID
  // against any/all CNs in the subject. Since we're trying to phase out the
  // use of CN-IDs, we intentionally avoid trying to match MSIE's more liberal
  // behavior.

Comment 9

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

After bug 1245280 ships (and all old certificates expire) this will cease to be an issue.

Comment 10

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

In fact, we're not going to make any further changes to address this, so I'm just going to WONTFIX it.