OpenSC 0.24.0 PKCS#11 + Firefox + TLS client-side auth via PIV = connection timeout #2987
Comments
|
I found the culprit using I can get a working build using:
|
|
Your certificate appears to be self signed. It could be that FireFox 121 has changed how it trusts a self signed certificate. Google for: firefox 121 self signed certificate OpenSC can cache certificates under ~/.cache/opensc does it have any files? The debug log ends unexpectedly at: OpenSC debug does not print some parts dealing with the PIN unless the debug level >= 8. Could you get a opensc-spy trace to see what PKCS11 calls are going on. See: |
|
But 1e625a3 is adding that the key is on the token, which in past it ignored. You may still have an issue with self signed certificate. Best to tell Mozilla of what you found. |
Do you mean self signed server certificate or client certificate? The server has an SSL certificate signed by Lets Encrypt and uses HSTS. Accessing the server without OpenSC works without SSL errors. My Yubikey has two PIV certificates, one self-signed for SSH and one signed by a custom (self signed) CA which is used for client-side TLS auth. Importing the custom CA into the trusted CA list of firefox does not make a difference.
No the directory does not exist.
The same happens with debug level 9 (link below). I use the following procedure to create the logs:
Full debug level 9 log with only the Yubikey that has the client-side auth:
env var logfile is created, but empty |
|
Can you provide a listing of the objects on your token with |
Note: I'm using OpenSC latest master (commit c354501) custom build (build flags) for both pkcs11 module and spy module for this one env vars: This still yields the same crash as mentioned above: Doing The correct binary is being used:
pkcs11-tool -O --loginpkcs11-tool -O |
|
I changed the fprintf to printf in the spy module, this is the output: |
|
Good to see @Jakuje is looking at this too. https://www.mozilla.org/en-US/firefox/releases/ You said:
To me it looks like the problem is in Firefox 121, not OpenSC. That may also b Your card has only 2 certificate and keys. Note that the "Certificate for Card Authentication" id 04 with key ref 9E is not meant for a user key and cert, as it is designed so the card can authenticate itself and it does NOT require a login to do that. What you may have been seeing with previous versions of FireFox is it does a C_Login to verify the PIN before doing anything. But FireFox 121.0 is not doing that and then getting confused or has some other issue. If reverting 1e625a3 fixes the problem, Unfortunately, I do my linux testing using Ubuntu 22.04, where FireFox was recently is updated to 121.0 but Ubuntu is installing it as a SNAP package, and they have not figured out how to get SNAP packaged to work with smartcards! |
|
pkcs11-spy.c:1579 if (strcmp(pInterface->pInterfaceName, "PKCS 11") != 0) { needs to check if |
|
The objects looks reasonable. I do not see any private certificates and the profile objects matches this expectation. You can get also PKCS#11 trace from the NSS to see what it does with the pkcs11 modules: https://www-archive.mozilla.org/projects/security/pki/nss/tech-notes/tn2 |
I just tried Firefox 120.0.1, same result. I can try older versions till I get dynamic linking issues (after which I'd have to compile the thing and that will take a while). Anything particular you want me to try? https://archive.archlinux.org/packages/f/firefox/
Same OpenSC and Firefox as me, stopped working for them after installing OpenSC 0.24.0, they also have the same Yubikey config.
Interesting that you mention that, I really just needed another Authentication card slot as the first one was used by SSH (not sure if I can mix that stuff, we're not using PKI for SSH, just plain old authorized_keys).
if you want to install the newest versions as non-snap: https://ubuntuhandbook.org/index.php/2022/04/install-firefox-deb-ubuntu-22-04/ |
|
|
Here is a way to install Firefiox nightly builds without SNAP It installed 123.a1 in my Ubuntu 22.04. Will see if I can get at least spy to work. |
The log shows the The slot with key 4 is in some way weird that it allows operations without authentication. Not sure if Firefox/NSS handles this well. See the [1], which describes this behavior (no need for the pin). I would certainly propose to try a different slot, probably one from the range of 82-95, as they should not have any weird behavior such as this one or user constent in the [1] https://developers.yubico.com/PIV/Introduction/Certificate_slots.html |
|
I created another cert and put it in the digital signature slot (9c). Using this cert I get prompts for entering the PIN and can successfully load the page. Not really usable as a workaround though as it prompts for a pin each time it creates a new SSL connection. I guess using the Key Management Slot (9d) would be a better choice due to the PIN "caching" ability (like the Authentication slot (9a) has) as described by the Yubikey docs. So I guess Firefox does not handle the Card Authentication (9e) slot correctly. |
|
Moved the certificate to the key management slot (9d). This restores the previous working behavior and resolves the issue. |
|
I am not sure if this will be considered by Firefox though as I would consider this more like a configuration issue -- you probably did not want your key to be able to provide signatures without login and it worked mostly accidentally because firefox logged in into everything before correct introduction of the profile objects in 0.24.0. |
|
@Jakuje in regards to the segfault I made the following hack: because gdb was showing Here is the start of a spy trace. Firfox 123a1 starts a lot of threads. |
|
@SCjona I agree with @Jakuje that using the cert/key without a pin is a good idea. Years ago I added code to card-piv.c to allow the use of the 30 retires key management keys/certs to be used based on the certificate keyUsage. i.e. not just for encryption. But only if the FASC-N in the CHUID started with 9999. (i.e. not gov issued) The FASC-N uses some 5-bit encoding. And you have to write a Discovery object to the card saying how many of the retired keys are present. I could try and find the instructions if you are interested. |
|
Sorry should have said "without a pin is a bad idea." |
|
Most likely the reason Firefox worked before 1e625a3 has to do with: And because it found CKP_PUBLIC_CERTIFICATES_TOKEN it now know it did not require a PIN to find the certificates, @SCjona what version is your Yubikey? |
|
Going back to original debug log, at line 7494 is the C_Sign request ending at line 7618, with the command sent and response received between lines 7583 and 7598 Why the log ends at line 7800 is still not clear. So Firefox requested a C_Sign, and OpenSC returned a signature. So other then the segfault in spy, it looks like OpenSC is working. |
YubiKey 5 NFC - Firmware 5.2.7
Chromium doesn't need a PIN, so I think you can assume it follows NIST PIV specs
don't think so
we're not using the key for auth directly, it just authenticates you to a reverse proxy, which grants access to internal services, which are protected by another login page (because the software doesn't support PKI based auth). so for me there are just two risk scenarios here:
maybe i forgot a scenario here, but with just those two i don't see a benefit in having to enter a PIN. I just thought PIN was a requirement at all times. |
I'd assume pInterface is just NULL and offsetof(pInterface, pInterfaceName) is 0x20, so you really just need to check if pInterface is not NULL |
|
@SCjona This might be your best bet; This requires a PIV History object to be written to the token if used via OpenSC which is also listed here: #847 was the original complaint. Since then you can find more info - Google for C10114C20100FE00 |
The po->C_GetInterface is passed the callers ppInterface where *ppInterface may not be valid. if the po->C_GetInterface may not update the *ppInterface and return an error. In this case spy_interface_function_list should not be called, as it assumes the *ppInterface has been modified. Found debugging FireFox version 121 where FireFox passes a ppInterface where *ppInterface is not a valid pointer, causing a segfault in spy_interface_function_list. FireFox calls C_GetInterface twice with flags = CKF_INTERFACE_FORK_SAFE twice then on third time requests with flag = 0 where po->GetInterface can support and it updates the *ppInterface with valid data. See OpenSC#2987 On branch pkcs11-spy-segfault Changes to be committed: modified: pkcs11-spy.c
The po->C_GetInterface is passed the callers ppInterface where *ppInterface may not be valid. if the po->C_GetInterface may not update the *ppInterface and return an error. In this case spy_interface_function_list should not be called, as it assumes the *ppInterface has been modified. Found debugging FireFox version 121 where FireFox passes a ppInterface where *ppInterface is not a valid pointer, causing a segfault in spy_interface_function_list. FireFox calls C_GetInterface twice with flags = CKF_INTERFACE_FORK_SAFE twice then on third time requests with flag = 0 where po->GetInterface can support and it updates the *ppInterface with valid data. See #2987 On branch pkcs11-spy-segfault Changes to be committed: modified: pkcs11-spy.c
|
What's the status of this issue? It seems that your hopping from one problem to another. Ideally, you would open one issue for one problem so that others can spot the solution(s) without spending hours of reading through this issue. |
|
It is not clear yet where the real problem is: OS, FireFox or OpenSC. The circumvention for @SCjona is to not use the PIV 9E key which is intended for the card to authenticate to physical devices like a door lock without using a PIN. One way to do this is outlined in #2987 (comment) to use one of the "retired" key slots on Yubico. The Spy issue was found trying to debug FireFox and committed to OpenSC master yesterday. @SCjona if you could provide a spy trace using OpenSC master build that would help locate the problem. |
|
Thanks for quick response. In https://gist.github.com/SCjona/eb9d15e4e7ebe798b2d660f92a9ed4eb In lines 424- 564 it found the certificate which you CENSORED. in line 929: It signed something without requiring entey a PIN as the key with CK_ID=04 does NOT require a PIN as expected. In 955 it closes the session. So in my option, OpenSC is working as expected. These probable do not apply but somethings to look at:
|
|
Correction: It signed something without requiring entry of PIN as the key with CK_ID=04 does NOT require a PIN as expected. |
I freshly created it, but I don't think it's a cache issue.
certainly, it should check at least expiration, probably also keyUsage. it's nginx with this config
all certificates and the certificate chain is valid. as explained before client side certs are signed with a custom CA, server side cert is lets encrypt. I also did a spy trace with with the same setup with me logging into the card manually first (via security devices in firefox settings), which makes everything work fine. the spy trace is 33MB though. i can send you that one via email if you want. |
The po->C_GetInterface is passed the callers ppInterface where *ppInterface may not be valid. if the po->C_GetInterface may not update the *ppInterface and return an error. In this case spy_interface_function_list should not be called, as it assumes the *ppInterface has been modified. Found debugging FireFox version 121 where FireFox passes a ppInterface where *ppInterface is not a valid pointer, causing a segfault in spy_interface_function_list. FireFox calls C_GetInterface twice with flags = CKF_INTERFACE_FORK_SAFE twice then on third time requests with flag = 0 where po->GetInterface can support and it updates the *ppInterface with valid data. See #2987 On branch pkcs11-spy-segfault Changes to be committed: modified: pkcs11-spy.c
|
Sed the trace to deengert at gmail.com |
|
The spy trace 33 MB exceeds the gmail max email size or 25GB. (Google for: gmail max email size ) |
System & OpenSC Information
Component: opensc-pkcs11.so
Smartcard(s): 2x Yubico YubiKey OTP+FIDO+CCID 00 00 (YubiKey 5). Also happens with just one card connected.
Operating System: Arch Linux
Package: https://archlinux.org/packages/extra/x86_64/opensc/
Version number: 0.24.0 (package is compiled from Github releases)
Also happened to other coworkers on MacOS with brew and its OpenSC package.
Problem Description & Steps to reproduce
This bug only occurs in Firefox. Chromium works fine.
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0
Steps to reproduce:
I'm using a YubiKey to authenticate myself to a web server which requires client-side TLS certificates for authentication. This worked fine with OpenSC version 0.23.0 (on MacOS and Linux (Windows untested)), but yields a timeout error on OpenSC version 0.24.0.
You can work around this issue by going to Settings -> Security Devices (under Certificates) -> Select the Smartcard under the OpenSC module -> Log In.
This will prompt the pin and after completing the login everything works as expected.
Actual results:
Opening an website which is protected by client-side TLS certificate authentication yields an network timeout error after 5 to 10 seconds. No PIN/Password prompt for the smart card is shown.
Expected results:
A PIN/Password prompt for the smartcard should be shown. After entering the correct PIN the page should load.
Logs
https://gist.github.com/SCjona/0c3c963afbcd17a18178c0d8f06d53a8
The text was updated successfully, but these errors were encountered: