osclientcerts: determining if keys support rsa-pss is still a problem
Categories
(Core :: Security: PSM, defect, P3)
Tracking
()
People
(Reporter: jakub.danek, Unassigned)
References
(Blocks 1 open bug)
Details
(Whiteboard: [psm-blocked])
Attachments
(1 file)
627 bytes,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:100.0) Gecko/20100101 Firefox/100.0
Steps to reproduce:
Middleware: SCInterface (cryptovision) 8.0.12
- Visit a site that uses smart card authentication
- Authenticate with smart card
- Choose smart card certificate
- Enter pin
Actual results:
The following error page is displayed:
Secure Connection Failed
An error occurred during a connection to xxx. A PKCS #11 module returned CKR_GENERAL_ERROR, indicating that an unrecoverable error has occurred.
Error code: SEC_ERROR_PKCS11_GENERAL_ERROR
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
Tested with:
a) osclientcerts only (cryptovision module not loaded),
b) osclientcerts disabled,
c) both enabled
Result is always identical (except for no osclientcerts logs in case when it is disabled)
Expected results:
Firefox should have authenticated to the site as normal.
Chrome and Edge connect and authenticate to the same server without issues.
Reporter | ||
Comment 1•10 months ago
|
||
This seems to be related to Bug 1725025 (especially pereng's last comment on the ticket).
Interestingly, users report ability to authenticate against different web servers with the same card.
We have the server under control and can test different setups to figure out what triggers the issue. Server is configured to use TLSv1.2 (card does not seem to support algorithms used with 1.3). We have tested HAProxy and nginx with no apparent difference in behaviour.
Comment 2•10 months ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
![]() |
||
Comment 3•10 months ago
|
||
If you configure the server to request something other than RSA-PSS signatures from the client, does it work?
Reporter | ||
Comment 4•10 months ago
|
||
I think I need an advice on how to do that. Havent been able to find any way to influence the algorithm used to sign the Certificate Request response on server side for nginx/openssl. I can only influence ciphersuites used for the initial browser - server negotiation via ssl_ciphers directive of nginx configuration. Just to be sure, Ive tested by enabling only ECDHE-ECDSA-AES128-GCM-SHA256, but to no effect, as expected.
In Wireshark, I can see that with Edge the Certificate Verify part is signed with rsa_pkcs1_sha1.
In FF there is no communication after Certificate Request is received.
![]() |
||
Comment 5•10 months ago
|
||
I think you have to include something like ssl_conf_command SignatureAlgorithms ECDSA+SHA256:RSA+SHA256;
in your nginx configuration.
Reporter | ||
Comment 6•10 months ago
|
||
Adding ssl_conf_command SignatureAlgorithms ECDSA+SHA256:RSA+SHA256;
successfully limits the list of signature hash algorithms presented by server to ecdsa_secp256r1_sha256
and rsa_pkcs1_sha256
. Client authentication works with FF as well as Edge and Chrome without any issues afterwards.
![]() |
||
Comment 7•10 months ago
|
||
Thanks! So, unfortunately this is more or less due to a limitation in how Firefox uses NSS uses PKCS#11 to support client authentication certificates, combined with the wide array of hardware and software involved in these stacks, all of varying degrees of quality. osclientcerts (the PKCS#11 module that provides support for client certificates in OS storage) more or less has to know what client certificates are available and what they're capable of before NSS even asks about them. In theory, we could use OS APIs to see if they support RSA-PSS, and accurately report this to NSS. In practice, this makes FIrefox slow (see bug 1662636), or throws up unexpected UI dialogs (see bug 1722306). So, currently osclientcerts pretends that everything supports RSA-PSS. It looks like your smart card doesn't support RSA-PSS, so when NSS tries to make an RSA-PSS signature, it fails, resulting in the error you're seeing.
Bug 696976 may mean that we can do something clever to work around the slowness, but until then, your best bet is to avoid RSA-PSS signatures for the time being.
Reporter | ||
Comment 8•10 months ago
|
||
Thanks for the information. For the time being, we are happy to have a working setup with acceptable security properties. Thanks for guiding me in the right direction.
If it helps, certutil -scinfo
identifies the card as Gemalto Classic V3.
Let me know if you wanted me to run more tests in the future.
Description
•