[NSS RSA-PSS] ActivID ActivKey SIM USB Keys not working when RSA-PSS present in Server Hello Certificate Request
Categories
(NSS :: Libraries, defect, P3)
Tracking
(Not tracked)
People
(Reporter: ryarnyah, Unassigned)
References
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:79.0) Gecko/20100101 Firefox/79.0
Steps to reproduce:
The issue appear when we use mTLS in Traefik with Go 1.14 which now add rsa-pss in Server Hello Certificate Request.
A example snippet is available here https://github.com/golang/go/issues/40344
Token module has been added in Firefox with path C:\Windows\System32\CnfPkcs11v220.x64.dll
Token model is and HID ActiveKey SIM (https://www.hidglobal.fr/products/cards-and-credentials/activid/usb-tokens)
Firefox version: 79.0 (64 bits)
Informations on certificate:
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 42133 (0xa495)
Signature Algorithm: sha256WithRSAEncryption
Issuer: C=XXXXXXXXXXXXXXXXXXX, O=XXXXXXXXXXXXXXXXXXX, OU=XXXXXXXXXXXXXXXXXXX, CN=XXXXXXXXXXXXXXXXXXX
Validity
Not Before: Jan 30 11:39:44 2018 GMT
Not After : Jan 29 11:39:44 2021 GMT
Subject: C=XXXXXXXXXXXXXXXXXXX, O=XXXXXXXXXXXXXXXXXXX, OU=XXXXXXXXXXXXXXXXXXX/UID=XXXXXXXXXXXXXXXXXXX, CN=XXXXXXXXXXXXXXXXXXX
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (2048 bit)
Modulus:
XXXXXXXXXXXXXXXXXXX
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
62:XXXXXXXXXXXXXXXXXXX
X509v3 Authority Key Identifier:
keyid:XXXXXXXXXXXXXXXXXXX
X509v3 Certificate Policies:
Policy: 1.2.250.1.257.0.1.1.2.1.21.1.1
CPS: XXXXXXXXXXXXXXXXXXX
X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage: critical
Digital Signature
X509v3 Subject Alternative Name:
email:XXXXXXXXXXXXXXXXXXX
X509v3 CRL Distribution Points:
Full Name:
URI:XXXXXXXXXXXXXXXXXXX
Signature Algorithm: sha256WithRSAEncryption
XXXXXXXXXXXXXXXXXXX
To reproduce, we need to connect with Firefox on the server and select Token and firefox refuse it with error SEC_ERROR_INVALID_ALGORITHM.
More informations:
- I'm not able to reproduce it with Firefox Developper Edition 79.0b9 (64 bits)
- i reproduce it with success in Firefox Nightly 80.0a1 (2020-07-22) (64 bits) without CnfPkcs11v220.x64.dll (using only bare install) with error: SEC_ERROR_PKCS11_GENERAL_ERROR
Actual results:
Firefox refuse connection with SEC_ERROR_INVALID_ALGORITHM (chrome does not seem to have this issue).
In Wireshark, it seem that Firefox stop when Server Hello is Done.
Expected results:
No error, connection OK.
More information: In Firefox Nightly 80.0a1 (2020-07-22) (64 bits) without osclientcerts.dll module and with CnfPkcs11v220.x64.dll module it seems to work.
|
||
Comment 2•5 years ago
|
||
Thanks Ryar.
Dana - This is TLS 1.2, so it's not quite the 1.3 rsa-pss assert bug ... but since the failure happens via osclientcerts, can you think of a place this could be related?
|
||
Comment 3•5 years ago
|
||
Dana:
- Theory 1: It's possibly related to https://dxr.mozilla.org/mozilla-central/source/security/manager/ssl/osclientcerts/src/lib.rs#236 unconditionally saying the slot supports particular mechanisms.
- Theory 2: It's possibly related to the fact that y'all only use the CNG functions (
NCrypt*), as we've still seen some tokens that are CAPI-only
Theory 1
On Windows, the supported mechanisms are really closer to per-key mechanisms. You need to know this to affect the TLS handshake and the cipher suites negotiated when using client cert auth, in order to make sure you won't negotiate a ciphersuite the token can't use. For Chrome, we don't fully interrogate the key, as is the "correct" response, because middleware/drivers are janky and bad, but we do inspect some of the properties to work around known bugs we've seen. For NSS/PKCS#11, that sort of info is stored slot level (via the mechanism list), rather than necessarily being key-level, IIRC.
In theory, creating a slot-per-key would avoid these issues, so that you can tailor the mechanisms of the slot to the key, except NSS is super-bad with that (read: leaks memory over and over).
You can see our handling of that at https://source.chromium.org/chromium/chromium/src/+/master:net/ssl/ssl_platform_key_win.cc;l=62;drc=94493c6554081529c04eea5b97a1f2ff2649e4a8?originalUrl=https:%2F%2Fcs.chromium.org%2F and https://source.chromium.org/chromium/chromium/src/+/master:net/ssl/ssl_platform_key_win.cc;l=223;drc=94493c6554081529c04eea5b97a1f2ff2649e4a8?originalUrl=https:%2F%2Fcs.chromium.org%2F , respectively. Note the latter case for special-handling some broken Estonian eID cards, which might also be relevant here.
Theory 2
It is what it says on the tin, and it's why we haven't nuked the CAPI legacy path yet. Same reason we see weirdness on macOS regarding tokend depending on which platform we're on.
|
||
Comment 4•5 years ago
|
||
Thanks, Ryan. We actually added capi support a couple of weeks ago, so either that's not the issue or there's a problem with that implementation. The mechanism list was never a complete solution, so I guess it's time to address that. I was thinking one approach might be to have one slot that supports the more modern mechanisms and one slot that only supports the legacy mechanisms.
|
|
||
Comment 5•4 years ago
|
||
Can you test this build out? https://firefox-ci-tc.services.mozilla.com/api/queue/v1/task/PcDqmt2SSGuBoNWrsvKwHg/runs/0/artifacts/public/build/install/sea/target.installer.exe
Thanks!
I tryied it and windows show me a pop-up that telling me that the token can't do the requested operation and need another token when i oppened this version of Firefox.
|
|
||
Comment 7•4 years ago
|
||
Currently pursuing this as an osclientcerts fix in comment 5.
Description
•