NSS allows unrelated certificates in the certificate chain during TLS client authentication.
Categories
(NSS :: Libraries, defect)
Tracking
(Not tracked)
People
(Reporter: mario.korth, Unassigned)
Details
Attachments
(1 file)
33.68 KB,
application/zip
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.97 Safari/537.36
Steps to reproduce:
Create a nssdb in which the supplied root certificate is trusted (./certutil -A -d /cert/keydb/nssdb/ -t "TC,," -n rootv3 -i /cert/inputCerts/rootv3.pem) and add an arbitrary certificate which nss can use as the server certificate (./pk12util -d /cert/keydb/nssdb/ -K 123456 -i /cert/inputCerts/rsav3.p12 -W 123456).
For convenience I attached a zip of my nssdb used during testing.
If you got no ready to run NSS installation use the attached dockerfile to build a fitting image with the following command:
docker build -t nss-3.53-server -f Dockerfile-3.53 .
Then start the container with this command:
docker run -it --rm -p 4433:4444 -v $(pwd):/cert nss-3.53-server
Navigate to /src/dist/Debug/bin/
Copy all content of /src/dist/Debug/lib/ to /lib
Start the nss selfserv utility with the following command line to require client certificate authentication:
./selfserv -n "TLS-Scanner CCA Leaf Certificate (ROOTv3_CAv3_LEAF_RSAv3) - RUB" -p 4444 -w 123456 -d /cert/keydb/nssdb/ -r -r
Connect to the server using the supplied certificates. Sadly I'm not aware of any utility that allows one to add arbitrary unrelated certificates in an TLS 1.2 certificate message. For the certificates used and wireshark traces depicting this behavior please see the attached zip archive.
Actual results:
NSS accepted the TLS connection with an authenticated user even though the user's certificate message contained unrelated certificates in the chain, once in between the leaf and intermediate CA certificate and once after the intermediate CA certificate.
Expected results:
As TLS 1.2 does not allow unrelated certificates in the chain presented in the certificate message NSS should reject such messages/chains and abort the handshake.
"certificate_list
This is a sequence (chain) of certificates. The sender's
certificate MUST come first in the list. Each following
certificate MUST directly certify the one preceding it. Because
certificate validation requires that root keys be distributed
independently, the self-signed certificate that specifies the root
certificate authority MAY be omitted from the chain, under the
assumption that the remote end must already possess it in order to
validate it in any case." [RFC 5246}
Comment 1•4 years ago
|
||
I’m resolving this as WontFix/Invalid.
RFC 8446 explicitly addressed this, and retroactively, because the spec language existing as cited did not reflect rough consensus or running code.
Note: Prior to TLS 1.3, "certificate_list" ordering required each
certificate to certify the one immediately preceding it; however,
some implementations allowed some flexibility. Servers sometimes
send both a current and deprecated intermediate for transitional
purposes, and others are simply configured incorrectly, but these
cases can nonetheless be validated properly. For maximum
compatibility, all implementations SHOULD be prepared to handle
potentially extraneous certificates and arbitrary orderings from any
TLS version, with the exception of the end-entity certificate which
MUST be first.
Description
•