TPM-backed client certificates on CrOS do not support RSA-PSS, mandatory for TLS 1.3
Reported by
swood...@lyft.com,
Today
(10 hours ago)
|
||||||
Issue description
UserAgent: Mozilla/5.0 (X11; CrOS x86_64 11151.61.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Platform: 11151.61.0 (Official Build) stable-channel eve
Example URL:
Steps to reproduce the problem:
1. Set up a TLS 1.2/1.3 server that accepts client certificates and
includes RSASSA-PSS schemes in the supported_signature_algorithms
list sent by the server in the CertificateRequest message.
2. Add a certificate with an RSA keypair to a Chromebook using the
"Import and Bind" function in the Chrome certificate manager to add
the RSA private key to the Chromebook TPM.
3. Use the Chromebook to navigate to the server you set up in step 1 and
present the hardware-backed certificate.
4. Chrome will fail to connect to the server with a
ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED error.
What is the expected behavior?
Chrome should select a signature scheme supported by both the server and client/TPM and prepare a valid CertificateVerify message to allow the TLS handshake to complete successfully.
What went wrong?
Relevant Chrome logs
--------------------
[0118/131505:ERROR:chaps.cc(1094)] C_SignInit - CKR_MECHANISM_INVALID
[1381:3383:0118/131505.292085:ERROR:ssl_platform_key_nss.cc(44)] PK11_SignWithMechanism failed: -8186 (SEC_ERROR_INVALID_ALGORITHM)
[1381:1540:0118/131505.293184:ERROR:ssl_client_socket_impl.cc(1013)] handshake failed; returned -1, SSL error code 1, net_error -141
Relevant chapsd logs
--------------------
2019-01-18T14:04:47.377903-08:00 DEBUG chapsd[1262]: CALL: SignInit
2019-01-18T14:04:47.377925-08:00 DEBUG chapsd[1262]: IN: session_id=14
2019-01-18T14:04:47.377944-08:00 DEBUG chapsd[1262]: IN: mechanism_type=13
2019-01-18T14:04:47.378047-08:00 DEBUG chapsd[1262]: IN: mechanism_parameter={80, 2, 0, 0, 0, 0, 0, 0, 2, 0, 0, 0, 0, 0, 0, 0, 32, 0, 0, 0, 0, 0, 0, 0}
2019-01-18T14:04:47.378092-08:00 DEBUG chapsd[1262]: IN: key_handle=9
2019-01-18T14:04:47.378146-08:00 ERR chapsd[1262]: Mechanism not supported: 0xd
What is "mechanism 0x0d"?
-------------------------
Mechanism 0x0d appears to be related to RSASSA-PSS from the PKCS #11 spec
http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/csprd01/pkcs11-curr-v2.40-csprd01.html#_Toc372721685
#define CKM_RSA_PKCS_PSS 0x0000000D
Relevant server config details
------------------------------
openssl s_client -connect [REDACTED]:443
...
---
Acceptable client certificate CA names
[REDACTED]
Client Certificate Types: RSA sign, ECDSA sign
Requested Signature Algorithms: ECDSA+SHA256:0x04+0x08:RSA+SHA256:ECDSA+SHA384:0x05+0x08:RSA+SHA384:0x06+0x08:RSA+SHA512:RSA+SHA1
Shared Requested Signature Algorithms: ECDSA+SHA256:RSA+SHA256:ECDSA+SHA384:RSA+SHA384:RSA+SHA512:RSA+SHA1
Peer signing digest: SHA256
Server Temp Key: X25519, 253 bits
---
Did this work before? N/A
Chrome version: 71.0.3578.98 Channel: stable
OS Version: 11151.61.0
Flash Version:
Refiling https://bugs.chromium.org/p/chromium/issues/detail?id=923596 as an open ticket because this isn't a security vulnerability and doesn't need to be restricted.
,
Today
(10 hours ago)
,
Today
(10 hours ago)
Not sure if this should block on Issue 792204, although Issue 634494 is also related. I don't think it's "strictly" a bug, although David may chime in for the TLS 1.3 bits.
,
Today
(10 hours ago)
Thanks Ryan. Not sure if I'm understanding correctly. I acknowledge that I could probably work around this server-side by reordering the supported_signature_algorithms list somehow. That said it still seems like a bug that Chrome is selecting an algorithm the TPM doesn't support when there are alternative advertised algorithms that the TPM does support.
,
Today
(10 hours ago)
[ I expect you're just running into TLS 1.3 mandating RSA-PSS, but just to confirm, could you attach a NetLog per these instructions? Thanks! https://www.chromium.org/for-testers/providing-network-details ] Given ssl_platform_key_nss.cc is coming up, I don't think this is related to issue #792204. That means the key is backed by NSS, rather than an extension. On the NSS side, it's true that we don't ask the key what it supports. At least on other platforms, there isn't really a reliable API to do so. Ryan, you'd know better about NSS. Is there something we can query there? That said, I don't think that would actually switch connections to working here, only replace ERR_SSL_CLIENT_AUTH_SIGNATURE_FAILED with ERR_SSL_CLIENT_AUTH_NO_COMMON_ALGORITHMS. Since we can't query the key, we instead ignore the server preferences (so reordering wouldn't make a difference) and prioritize PKCS#1 over PSS. That means that, if we ask the key to sign PSS, the server/protocol combination must not have allowed PKCS#1 at all. To that end, that openssl s_client output is showing the TLS 1.2 output, not the TLS 1.3 output. In TLS 1.3, PKCS#1 is forbidden. RSA keys must support PSS to work with TLS 1.3. That means that, on the server deployment side, a client-cert-using server can't deploy TLS 1.3 until its client base are using 1.3-compatible keys. :-( On the client side, we need to get all the RSA keys supporting RSA-PSS. The browser-side support is there. We know how to ask NSS to sign RSA-PSS. The problem is that the TPM-backed key does not support RSA-PSS. Owners of the TPM bits need to fill in that missing piece.
,
Today
(10 hours ago)
(I don't think issue #634494 is related either. id-RSASSA-PSS keys basically do not exist, and this is presumably an id-rsaEncryption key if it *doesn't* support PSS.)
,
Today
(10 hours ago)
None of the current code, on any platform, takes hardware capability into consideration, although that capability exists on all platforms (to varying degrees of accuracy, however).
,
Today
(9 hours ago)
Thanks David. I've attached a NetLog, though I should note I removed some of what I believe to be irrelevant details containing pseudo-sensitive information (extensionInfo, prerenderInfo, etc) because I'm reproducing this from my own machine. If for some reason you need an unmodified file please let know.
,
Today
(9 hours ago)
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Today
(9 hours ago)
Thanks! That confirms things. The NetLog shows that you're connecting to the server via TLS 1.3. While the CertificateRequest does include rsa_pkcs1_*, in TLS 1.3, that code point is only allowed for the signatures within the certificate, not the TLS-level signature, made by, in this case, the TPM-backed private key. So we ignore it and only consider the RSA-PSS algorithms. See: https://tools.ietf.org/html/rfc8446#section-4.2.3 (Even if we didn't filter it out on the client, your server would reject the signature.) In the meantime, though it makes me sad, probably your best bet is to disable TLS 1.3 on those servers. :-( I've renamed the bug to capture the root issue. I've filed issue #924284 to track querying capabilities more accurately, but since your root problem is on the TPM-backed certificate side, I think it makes sense to keep this bug for the TPM-side issue. CrOS folks, could you fill in the missing bits?
,
Today
(8 hours ago)
Thanks for all the help David! Appreciate your responsiveness in finding the root cause here.
,
Today
(8 hours ago)
Issue 923596 has been merged into this issue. |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by ericorth@chromium.org
, Today (10 hours ago)