Positive client certificate choices don't persist
Categories
(Core :: Security: PSM, defect)
Tracking
()
People
(Reporter: da-wgh, Unassigned)
Details
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0
Steps to reproduce:
- Open a website that requests a client certificate
- In the dialog window, choose a certificate, checking "remember choice"
- Exit the browser, or close the tab and wait for a while so persistent HTTPS connections get torn down
- Open the website again
Actual results:
Firefox asks for a certificate again.
Expected results:
Firefox doesn't ask for a cert, and sends the remembered certificate again.
This is supposed to be fixed in bug 634697, but the "fix" somehow made things worse. I'll give you my debugging notes.
I don't understand what's going on. I even tried deleting ClientAuthRememberList.txt to start from the scratch.
It seems the positive choice does get stored into ClientAuthRememberList.txt (at the browser exit):
redacteddomain.com,1D:D6:F3:7F:CE:5B:3C:B5:BB:7D:B1:70:9F:5A:B8:CF:74:57:F8:28:E0:A4:3D:68:9D:A1:8F:C6:A:CF:CA:07,^partitionKey=%28https%2Credacteddomain.com%29 0 18977 AAAAAAAAAAAAAAAgAAAAG37PGiMvTjDNYl5mJDIHUdTyal0gCLu4tnnlsaxCSFV5MBkxFzAVBgNVBAMM<redacted>
But it has no effect whatsoever. Every time I visit the site again (after a delay so persistent HTTPS connections get closed), I get asked for a cert. "Authentication Decisions" in the UI shows an empty list.
But if I hit cancel just once, the negative choice replaces the positive choice quoted above (ditto: the file gets rewritten at the browser exit):
redacteddomain.co,1D:D6:F3:7F:CE:5B:3C:B5:BB:7D:B1:70:9F:5A:B8:CF:74:57:F8:28:E0:A4:3D:68:9D:A1:8F:C6:8A:CF:CA:07,^partitionKey=%28https%2Credacteddomain.con%29 1 18978 no client certificate
And I never get asked for a cert ever again. Not even after browser restart. The "Authentication Decisions" still shows an empty list.
|
||
Comment 2•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Security: PSM' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
I personally know two other persons with the same problem. Firefox versions is 95 and unknown correspondingly. All of us are running Linux.
After throughout debugging, I determined that the underlying cause of my problem was bug 1139205.
Having zero useful logging and resorting to rebuilding both firefox and nss with debug symbols and single-stepping with gdb was not really fun, I have to admit.
Description
•