Certificate key usage is not enforced strictly when verifying server certificate

NEW
Unassigned

Status

()

defect
P3
normal
6 years ago
2 years ago

People

(Reporter: briansmith, Unassigned)

Tracking

(Depends on 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [psm-backlog])

The first patch for bug 878932 tries to map NSS SECCertificateUsages to appropriate (KU, trust bit) pairs. However, some certificate usages are ambiguous. In particular, the key usage to require for TLS_ECDHE and TLS_DHE ciphersuites is digitalSignature, but for TLS_RSA cipher suites it is keyEncipherment and/or dataEncipherment (still not clear what is needed for compatibility). Since we don't have the cipher suite as an input into the certificate verification, we just always try all three.

When verifying the server's certificate, we need to determine which KU to use based on the cipher suite selected, and enforce that KU.

In particular, a server that wants to require ephemeral key exchange, and reject RSA key exchange, should be able to enforce that by having a KU of only digitalSignature. Currently, we'd try RSA key exchange for such a certificate anyway, and that's bad.
Also see bug 237877, which is the corresponding NSS bug.
Bisecting mozilla-aurora shows that the switch to mozilla::pkix as default certificate verifier (bug 990248) fixes this bug. The changeset is https://hg.mozilla.org/releases/mozilla-aurora/rev/50ff5b820452.
Verified that this bug is fixed in a clean installation and a clean profile of Firefox 31 beta 7, built from FIREFOX_31_0b7_RELEASE aka https://hg.mozilla.org/releases/mozilla-beta/rev/56ec82ed9283.

I only tested ciper suite ECDHE-RSA-AES128-GCM-SHA256 with a self-signed server certificate with KU=digitalSignature and EKU=id-kp-serverAuth (TLS Web Server Authentication, 1.3.6.1.5.5.7.3.1).
Flags: needinfo?(brian)
(In reply to Nico R. from comment #3)
> Verified that this bug is fixed in a clean installation and a clean profile
> of Firefox 31 beta 7, built from FIREFOX_31_0b7_RELEASE aka
> https://hg.mozilla.org/releases/mozilla-beta/rev/56ec82ed9283.
> 
> I only tested ciper suite ECDHE-RSA-AES128-GCM-SHA256 with a self-signed
> server certificate with KU=digitalSignature and EKU=id-kp-serverAuth (TLS
> Web Server Authentication, 1.3.6.1.5.5.7.3.1).

Nico, the problem you are describing is bug 51466, where NSS-based clients reject RSA certificates with KU=digitalSignature. That is indeed fixed with Firefox. 

However, this bug is about the fact that we are too permissive about which key usages we accept for a connection. In particular, for RSA-AES128-GCM-SHA256 we should in theory only accept KU=keyEncipherment and NOT KU=digitalSignature, but we aren't that strict. The problem is that NSS's libssl doesn't allow us to know which cipher suite is being used at the time the certificate is being validated. Consequently, we added a hack: a function called BuildCertChainForOneKeyUsage that validates a certificate for multiple KUs.

The real fix is to add a way to libssl to allow the auth certificate callback to determine which key usage to validate for, and then replace the BuildCertChainForOneKeyUsage function with logic that uses that new mechanism. And, that is what this bug is about.
Flags: needinfo?(brian)
You need to log in before you can comment on or make changes to this bug.