Remember user's client certificate selection across sessions
Categories
(Core :: Security: PSM, enhancement, P1)
Tracking
()
Tracking | Status | |
---|---|---|
firefox81 | --- | fixed |
People
(Reporter: t.petrzilka, Assigned: mbirghan)
References
(Blocks 1 open bug)
Details
(Whiteboard: [psm-assigned])
Attachments
(2 files, 3 obsolete files)
Comment 2•14 years ago
|
||
Comment 3•14 years ago
|
||
Updated•14 years ago
|
Comment 8•13 years ago
|
||
Comment 9•13 years ago
|
||
Comment 10•13 years ago
|
||
Comment 11•10 years ago
|
||
Comment 12•10 years ago
|
||
Comment 13•10 years ago
|
||
Comment 15•10 years ago
|
||
Comment 17•9 years ago
|
||
Comment hidden (advocacy) |
Comment hidden (advocacy) |
Comment hidden (off-topic) |
Assignee | ||
Comment 24•5 years ago
|
||
Comment 25•5 years ago
|
||
(In reply to Tomáš from comment #6)
(In reply to comment #3)
The dialog I described is IMHO shown at very rare circumstances as for
professional use mostly.. But still used..
No, it happens to everyone who uses certificates* to do their taxes online, access their bank account etc.
- even with a single installed certificate, the dialog is shown each time
Assignee | ||
Comment 26•5 years ago
|
||
Updated•5 years ago
|
Comment 27•5 years ago
|
||
Found this bugzilla-entry by googleing for a solution for my problem - I have two client-certificates - one already expired and one is valid.
By default the already expired certificate is selected (due to the lower serial-number?) which is annoying because no error-message is displayed if I try to connect to the server with this expired client-cert - just an empty page. Checked with the webdeveloper-tools - there is a message that is at least a hint for the error that just occured ("SSL_ERROR_EXPIRED_CERT_ALERT").
And yes - I checked the "remeber this decision" for the valid client-cert with the higher serial-number. But after a browser-restart the expired certificate is the default-selection again.
Yes - the workaround would be to remove the expired client-cert from Firefox' certificate-store. But a workaround does not eliminate a bug ;-)
If I can help with some testing from user's side (as I am "only" a webdeveloper and webserver-admin, not a Firefox-programmer) I will be happy to do so.
Updated•5 years ago
|
Assignee | ||
Comment 28•5 years ago
|
||
Depends on D54336
Assignee | ||
Comment 29•5 years ago
|
||
Depends on D54336
Comment 30•5 years ago
|
||
Comment 31•5 years ago
|
||
Backed out changeset a538b0497336 (Bug 634697) for causing android build bustages in /builds/worker/workspace/build/src/security/manager/ssl/nsNSSComponent.cpp CLOSED TREE
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=290853789&repo=autoland&lineNumber=33084
Comment 32•5 years ago
|
||
Comment 33•5 years ago
|
||
Moritz - when you fix the build issues, let's land this in a new bug so that the original purpose of this bug doesn't get lost.
Comment 34•5 years ago
|
||
Comment on attachment 9126100 [details]
Bug 634697 - Refactoring nsClientAuthRememberService to work as a service
Revision D62585 was moved to bug 1618710. Setting attachment 9126100 [details] to obsolete.
Comment 35•5 years ago
|
||
Comment on attachment 9110916 [details]
Bug 634697 - Remember user's client certificate selection across sessions
Revision D54336 was moved to bug 1620976. Setting attachment 9110916 [details] to obsolete.
Assignee | ||
Updated•5 years ago
|
Comment 36•5 years ago
|
||
Dana, it looks like this new data storage could effectively be used as a source for (abridged) browser history and should come under our regular data clearing mechanisms, so that "clear recent history...", "forget about this site", the forget button and other mechanisms we have clear the data when the user chooses to do that. Can that happen here, or if not, would you mind filing a follow-up bug to hook this all into nsIClearDataService, if that's not already part of the patches here? That way we don't end up creating a privacy liability when fixing this bug. Thank you!
Comment 37•5 years ago
|
||
Yes, that can happen here. Thanks for the reminder!
Updated•5 years ago
|
Comment 40•4 years ago
|
||
Comment 41•4 years ago
•
|
||
Backed out changeset 928233ea49ee (bug 634697) for causing leaks. CLOSED TREE
Logs:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309847107&repo=autoland&lineNumber=1730
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309847733&repo=autoland&lineNumber=1119
Push with failures:
https://treeherder.mozilla.org/#/jobs?repo=autoland&group_state=expanded&revision=928233ea49eeca3dddc25d4cdc59995b17f78092
Backout:
https://hg.mozilla.org/integration/autoland/rev/840f993400695f8c67d44b35f5f7f4b2c4bcf5fd
Edit:
Also afected a few other tests, including Mochitest and XPCshell:
https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=309847069&repo=autoland&lineNumber=1738
https://treeherder.mozilla.org/logviewer.html#?job_id=309847739&repo=autoland
Assignee | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 42•4 years ago
|
||
Comment 43•4 years ago
|
||
Backed out for failure at test_sss_readstate.js.
Backout link: https://hg.mozilla.org/integration/autoland/rev/f6e962ff9eb45359b95ec15f6471436fe74fef47
Failure log for xpcshell: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=311406771&repo=autoland&lineNumber=2903
Failure log for mochitest: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=311406741&repo=autoland&lineNumber=8155
Comment 44•4 years ago
|
||
Comment 45•4 years ago
|
||
bugherder |
Assignee | ||
Updated•4 years ago
|
Comment 46•4 years ago
|
||
I tested the 81 nightly.
Observations:
-
("Remember this decision" is selected) clicking Cancel does not really Cancel, but remembers "user wants to use the web site without a client certificate"
On next use, FF will not ask for certificate choice, but proceed with no certificate. This is IMO wrong. Cancel should mean "don't do anything". -
("Remember this decision" is NOT selected) clicking Cancel , just brings up the same dialog again. And again. I guess it is displayed for every HTTP request (for every embedded image, JS, CSS and so on ). This is also bad.
Also, in the second case, after I clicked Cancel 5 times, I selected OK. The page was then displayed, but with many elements missing (CSS, images). After I refreshed it, the main HTML did not see the selected certificate (in the first try it did). This is against my expectations. I would expect the first load (when I selected Cancel) to NOT see my certificate, and the second refresh to see it (because I selected one and had the "remember" option selected too).
Assignee | ||
Comment 47•4 years ago
|
||
These observations should in my opinion be handled in a different bug. They seem to show issues with the general client cert dialog.
This patch is focused on how remembering decisions are handled and persistently stored after the user interaction with the client cert dialog.
Comment 48•4 years ago
|
||
Indeed - this patch has landed, and we try and stick to 1 issue per bug, or bugs devolve into never-ending sagas where it's unclear which things got fixed for which releases. Please file a bug for the cancel vs. remember behaviour, and a separate one for the refresh behaviour (with more detailed steps and ideally with a testcase, as the behaviour of "the page" may well depend on JS (that was potentially cached from the "cancel" request before?) and to debug that we'd need to see an actual broken case).
Comment 50•4 years ago
|
||
cancel vs remember is already submitted: bug 537103 , but marked as a duplicate of another bug that is marked INCOMPLETE.
Should I try to revive it or just file a new one?
Updated•4 years ago
|
Comment 51•4 years ago
|
||
(In reply to David Balažic from comment #50)
cancel vs remember is already submitted: bug 537103 , but marked as a duplicate of another bug that is marked INCOMPLETE.
Should I try to revive it or just file a new one?
Just filing a new one is probably more straightforward. Thank you!
Comment 53•4 years ago
|
||
and bug 1657591 for the "dialog appears several times"
Comment 57•3 years ago
|
||
Is it really fixed? I recently updated to 91 ESR (Linux), I still have the popup appearing as it did before. I.e. I check "remember choice", hit OK, and some time after (when connection is reestablished, apparently), the dialog appears again. The same with browser restarts.
Comment 58•3 years ago
|
||
And somehow hitting Esc (which is easy to do accidentally as this freaking dialog appears randomly) when this dialog appears somehow is remembered very well, as I'm not prompted again (and certificate is not sent) until browser is restarted.
Comment 59•3 years ago
|
||
(In reply to WGH from comment #57)
Is it really fixed? I recently updated to 91 ESR (Linux), I still have the popup appearing as it did before. I.e. I check "remember choice", hit OK, and some time after (when connection is reestablished, apparently), the dialog appears again. The same with browser restarts.
Please note, that pop-up confirmation of authentication with selected certificate differs from remembering selected certificate in list of available.
Comment 60•3 years ago
|
||
If that's true, then the fix is almost useless. It does not address the main frustration: the dialog appearing over and over again.
Comment 61•3 years ago
|
||
I use Firefox v94 and it works fine: I select the certificate for a website and it is remembered "forever". It never asks again (for that website).
The list of remembered certificates choices can be seen in Settings / Certificates / View Certificates , in the tab titled "Authentication Decisions".
Comment 62•3 years ago
|
||
Okay, thanks for the input! I have such tab, but its contents are empty. Gotta debug it, and depending on the result, will either post a short comment here, or create a new bug.
Comment 63•3 years ago
|
||
I tried to solve this on my own, but I couldn't. I created a new bug 1746532
Comment 64•3 years ago
|
||
In the end, this was caused by serial numbers longer than 20 bytes. After I reissued certificate with shorter serial, choice is properly remembered. I also had to manually clean up ClientAuthRememberList.txt to make "Authentication Decisions" tab show anything (having even one long serial breaks it competely, apparently).
Description
•