856060 - Name Constraints ignored by libPKIX verification engine (in both intermediate and toplevel CA certificates)

Status: RESOLVED FIXED

(NSS :: Libraries, defect, P1)

Description

[Kai Engert [:KaiE:]]

Given a CA certificate with a Name Constraints extension with:
                Permitted:
                  DNS:.de
                  DNS:.com
                  email:.de
                  email:.com

Given a server certificate, issued by above CA, using a hostname in the .org domain:

Using a Firefox profile that trusts above CA certificate, and connects to a server using a certificate issued by above CA, which isn't whitelisted as permitted.

Expected: NSS rejects the certificate and Firefox aborts the connection

Actual behaviour: NSS acceptes it and Firefox connects successfully.


Test case:
- create a new Firefox test profile

- visit https://n-2.org:8654/
  (expected: cert error because CA unknown)

- import the test CA that issued the server cert from
    http://kuix.de/ca/constrained-test-ca.php
  and mark it as trusted

- again visit (reload) https://n-2.org:8654/

- expected: cert should still get rejected

- incorrect behaviour: Firefox loads page without error


Dump of CA cert:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, ST=Test State, L=Test Loc, O=Test Org, CN=Kai's Constrained .de .com Test CA
        Validity
            Not Before: Dec 29 14:45:31 2012 GMT
            Not After : Mar 29 14:45:31 2021 GMT
        Subject: C=DE, ST=Test State, L=Test Loc, O=Test Org, CN=Kai's Constrained .de .com Test CA
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:cd:11:fe:24:95:eb:c2:a0:a5:23:ed:db:5c:03:
                    46:ef:00:48:8f:d3:12:c0:8a:82:f4:b1:82:80:4c:
                    89:84:59:72:75:0b:a4:77:69:8b:6c:c8:43:4f:7a:
                    08:b2:26:b4:25:46:69:90:40:25:5e:13:18:86:64:
                    28:9e:46:9d:54:cd:19:ae:d5:15:25:bf:b7:5c:66:
                    d1:bb:02:10:db:ae:70:f0:d7:d1:09:a0:77:a0:96:
                    2c:a3:20:82:6a:c0:61:4d:60:96:07:81:aa:48:13:
                    92:d9:53:e2:45:56:57:69:14:f9:de:9f:cd:57:e2:
                    89:8f:8a:92:21:0f:2b:95:55
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Netscape Cert Type: 
                SSL CA, S/MIME CA, Object Signing CA
            X509v3 Name Constraints: 
                Permitted:
                  DNS:.de
                  DNS:.com
                  email:.de
                  email:.com

            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Key Usage: 
                Certificate Sign, CRL Sign
    Signature Algorithm: sha1WithRSAEncryption
         6c:38:d4:6e:98:20:c6:96:86:0f:41:47:30:b5:ef:6a:3a:7c:
         06:40:88:bc:3d:db:a9:ff:d9:15:a0:af:67:43:9a:3a:c6:7f:
         b6:bc:95:f8:4e:c0:6d:25:9a:0e:d8:e9:09:c8:fc:86:ad:2b:
         a5:ef:d1:65:c7:b6:69:35:e4:79:a4:e0:c8:47:ee:52:b1:45:
         d4:c6:9a:76:e5:9c:88:d4:6e:a7:e2:49:7d:c6:11:63:b4:d4:
         ac:22:1d:ea:9f:33:b1:e9:17:4b:11:9a:5d:e5:46:48:fb:4c:
         7f:ed:d2:76:51:5d:4e:f6:80:55:5b:ca:c5:57:ee:a8:55:85:
         45:f6

Dump of server cert:
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 5 (0x5)
    Signature Algorithm: sha1WithRSAEncryption
        Issuer: C=DE, ST=Test State, L=Test Loc, O=Test Org, CN=Kai's Constrained .de .com Test CA
        Validity
            Not Before: Mar 29 15:03:31 2013 GMT
            Not After : Mar 29 15:03:31 2018 GMT
        Subject: C=DE, ST=Test State, L=Test Loc, O=Test Org, CN=n-2.org
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:bd:2f:35:7a:26:ef:82:15:55:93:27:38:c9:58:
                    c3:b5:3b:0c:c8:41:13:25:69:3f:56:90:ec:1b:fd:
                    54:20:e3:ca:34:b0:6a:96:9c:0a:f0:89:a7:4e:42:
                    1f:60:0e:33:f0:3b:35:85:e3:66:1c:f8:4a:5c:c3:
                    24:54:80:db:b8:9b:e9:ff:5a:2c:f8:88:9b:d2:7b:
                    a7:53:21:9b:21:9b:52:e7:ce:3a:03:9a:d1:66:09:
                    59:ef:09:9b:80:66:4d:83:df:3f:57:fb:c9:b5:14:
                    91:2d:4a:5b:ca:90:40:6d:00:2d:a0:64:25:8c:4a:
                    13:6f:9c:06:fe:a5:e9:05:23
                Exponent: 65537 (0x10001)
        X509v3 extensions:
            Netscape Cert Type: 
                SSL Client, SSL Server
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Key Usage: 
                Key Encipherment, Data Encipherment, Key Agreement
    Signature Algorithm: sha1WithRSAEncryption
         4b:81:63:a2:cb:31:21:24:01:cd:31:bc:40:77:73:41:fc:d4:
         42:55:08:00:ca:ca:44:f3:95:8e:bb:7e:2f:5c:b2:85:1d:0e:
         0e:47:b5:d0:67:24:78:c2:0d:c1:a6:26:8a:78:c1:3a:96:3f:
         f8:e9:d7:d4:63:45:a8:69:2c:e2:1d:fe:6f:86:b2:e5:e6:e0:
         69:54:0f:17:54:e2:0a:dd:9d:6d:3a:6e:46:c3:34:25:e5:35:
         32:5c:99:4d:32:c9:84:94:8c:66:41:e0:5e:ae:23:96:19:2f:
         e3:75:54:dd:84:91:42:3f:03:de:a9:ea:77:71:f4:b6:70:e2:
         59:b1

Comment 1

[Kai Engert [:KaiE:]]

As a first step, I'd be interested in confirmation of this bug.

Is my assumption correct, that n-2.org should be a forbidden hostname, and should be rejected by NSS, given above name constraints extension?

Comment 2

[Kathleen Wilson]

Kai, Thank you for looking into this. I believe that this is the currently expected behavior regarding root certs.

https://groups.google.com/d/msg/mozilla.dev.security.policy/5v-yMBII6Mw/h0vMICe1IL0J

Have you confirmed that name constraints are being enforced at the intermediate and end-entity cert levels? (If yes, then maybe this bug should be closed as a dup of Bug #743700.)

Thanks,
Kathleen

Comment 3

[Kai Engert [:KaiE:]]

(In reply to Kathleen Wilson from comment #2)
> Have you confirmed that name constraints are being enforced at the
> intermediate and end-entity cert levels?

If I understand your statement correctly, your *assumption* is:

(a) today, NSS does NOT yet respect name constraints in topmost root CA certificates

(b) today, NSS does already respect name constraints on intermediate CA certificates

The initial test case in this bug is scenario (a).

I just added another test case for scenario (b).
Using the same above setup, you can find it at
  https://n-2.org:8653/

It uses an intermediate CA which contains the same name constraints that I have described earlier in this bug.

Test result:
  NSS connects fine to the test case (b), too!

Expected result:
  NSS should reject the cert at https://n-2.org:8653/

Comment 4

[Gervase Markham [:gerv]]

In Firefox Nightly (23.0a1) and a copy of Firefox Beta 20, when connecting to that site, I get:

Secure Connection Failed
        
          An error occurred during a connection to n-2.org:8653.

The Certifying Authority for this certificate is not permitted to issue a certificate with this name.

(Error code: sec_error_cert_not_in_name_space)

That seems correct to me...

Gerv

Comment 5

[Kai Engert [:KaiE:]]

Gerv, thanks for testing, my Firefox was configured to use the libpkix verification engine. So, it seems it's working as hoped only in one scenario.

Summary:

(a) toplevel root constrained, using NSS classic verify: 
        constraint ignored, cert accepted

(b) toplevel root constrained, using NSS libpkix verify:
        constraint ignored, cert accepted

(c) intermediate root constrained, using NSS classic verify:
        constraint respected, cert rejected

(d) intermediate root constrained, using NSS libpkix verify:
        constraint ignored, cert accepted

I talked to Gerv on IRC. We agree that (d) is a bug.

This means we found another blocker for using libpkix by default.

I propose that we handle scenario (d) in this bug, and I'm adjusting the subject accordingly. Given that libpkix has its own verification logic, it's probably reasonable 
to handle both (d) and (b) in this bug.

Regarding (a), I'm disappointed that it's not yet working, let's get that fixed with a high priority. I agree to use bug 743700 to track (a).

Given that bug 743700 is already a public bug, I will copy the information about the test case to bug 743700.

Regarding this bug, given that Chroms uses the libpkix engine by default, I'd like to hear Wan-Teh's opinion if this bug should remain hidden until the bug gets fixed in libpkix.

Comment 6

[Gervase Markham [:gerv]]

I get a "root not trusted" error on the n-2.org site in Chrome, which suggests that we've got past the check-name-constraints stage (as otherwise we'd get the same error in Firefox)...

Gerv

Comment 7

[Kai Engert [:KaiE:]]

I used the chromium 23 browser on Fedora, I imported the test CA from comment 0, and chromium connects to both test sites (8654 and 8653), no errors.

Comment 8

[Daniel Veditz [:dveditz]]

This needs to "block" the tracking bug for Firefox's switch to libPKIX

Comment 9

[Ryan Sleevi]

Attachment: Correct name constraints

Tests to follow. I haven't yet started to figure out why the NSS tests didn't catch this particular case, since the PKITS tests cover NCs.

I'm also trying to trace down all usages of buildCheckedCritExtOIDs, since it's incorrectly saying nameConstraints were checked during the build phase, when in fact they're *not* being checked (this checks them during the verify chain phase).

Comment 10

[Ryan Sleevi]

To add state to better understand this change:

Compare the differences between http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/top/pkix_build.c#976 , which is part of the chain building algorithm for CERT_PKIXVerifyCert (via PKIX_BuildCHain), and http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/top/pkix_validate.c#239 , which is the API for PKIX_ValidateChain [private]

The core functional diff between these two functions are:
pkix_NameConstraintsChecker_Initialize
pkix_NameChainingChecker_Initialize
pkix_BasicConstraintsChecker_Initialize

I added the call to the NConstraintsChecker here, and I'm still working through tracing whether there's equivalent functionality for the NameChaining and BasicConstraints checker through other aspects of the forward path builder checkers.

Ideally the nameConstraints would be handled by the forward builder state, but the way the merge algorithms are setup, it's "simpler" (eg: won't require 3 weeks in the bowels of libpkix) to simply use it as a reverse checker, the same way Validate does.

Comment 11

[Robert Relyea]

Comment on attachment 760676 [details] [diff] [review]
Correct name constraints

r+ rrelyea

Comment 12

[Ryan Sleevi]

To wrap up the investigation on the code (but not the tests):

The patch adds pkix_NameConstraintsChecker_Initialize, to explicitly check that NCs are valid when examining the constructed chain.

The bug is the difference between libpkix's Build (which is what NSS uses) and Validate (which is never used by NSS). Build uses PKIX_ComCertSelParams_GetNameConstraints ( http://mxr.mozilla.org/nss/source/lib/libpkix/include/pkix_certsel.h#1616 ). If non-NULL, then during the build phase it will only evaluate certs that match that NC - but if NULL, it does no enforcement whatsoever of NC in the built chain.

pkix_BasicConstraintsChecker_Initialize enforces the isCA & pathLength fields for Validate, but this is handled differently during the build phase, by having pkix_Build_BuildSelectorAndParams use PKIX_ComCertSelParams_SetBasicConstraints to set the traversal length, which is then checked at http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/certsel/pkix_certselector.c#1274

pkix_NameChainingChecker_Initialize is handled in a similar way - http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/top/pkix_build.c#1480 sets the path to names in the cloned params, and http://mxr.mozilla.org/nss/source/lib/libpkix/pkix/certsel/pkix_certselector.c#1290 then matches.

Comment 13

[Ryan Sleevi]

This only seems to trigger for cases where the subjectAltName is not present. The nameChaining test above handles all the SAN constraints, but the only handling of the CN is done by http://mxr.mozilla.org/nss/source/lib/libpkix/pkix_pl_nss/pki/pkix_pl_cert.c#3130 , which is ultimately what the NameConstraints checker calls.

So this is a much less serious issue - as per the BRs, the CN may only contain a value that's ALSO present in the SAN, and the SAN is already constrained, so it will reject.

Kai's test does not make use of the subjectAltName, which is why it fails.

Comment 14

[Ryan Sleevi]

Attachment: Added unittests, fixed mem leak

Bob, this is a minor tweak - just the addition of tests.

I went the route of using a certutil script (consistent with TestCA/TestUser50/TestUser51), compared to defining a whole new syntax and parser for the chains test to be able to express SANs and nameConstraints. I'd rather avoid extending that syntax, given that it's all processed in bash helper functions.

Comment 15

[Robert Relyea]

Comment on attachment 761232 [details] [diff] [review]
Added unittests, fixed mem leak

r+  

I'm OK with using certutil here. We really aren't preserving the ;ibrary independence' of the pkix code anyway.

bob

Comment 16

[Ryan Sleevi]

https://hg.mozilla.org/projects/nss/rev/7f527629198a

Comment 17

[Ryan Sleevi]

Note: I don't think this actually represents a security-bug. The behaviour described is something not found in any RFC, and instead is back from Bug #394919

The 'normal' test (where SANs were present) were and are already checked.

Comment 18

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

rsleevi and I agreed that this should be considered sec-low *at most*. It could also be considered an enhancement. Also, because Firefox validates the certificate chain using both the classic verification library AND libpkix for EV certs, then Firefox and other Gecko-based products seem to be unaffected in a practical sense by this bug.

Comment 19

[Camilo Viecco (:cviecco)]

Comment 18 is slightly incorrect. For EV certs Firefox only validates unsing libpkix.

Comment 20

[Kai Engert [:KaiE:]]

Can we open this bug?

Comment 21

[Ryan Sleevi]

I don't see any reason not to. This is something that no (public) CA should be issuing, as per the Baseline Requirements.