Closed Bug 295922 (CVE-2007-4879) Opened 16 years ago Closed 14 years ago
Client Auth "select cert automatically" is considered a privacy issue
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 By default, security.default_personal_cert is set to string "Select Automatically". A client certificate would be sent without the knowledge of the user. This setting ought to be "Ask Every Time" per default. Explanation of retrieving user's name (when user has installed a certificate): Danish government has issued certificates to all Danes (and Danish companies) with validated name of the person (or company) as Subject CN. There should be no issues itself with this decision, as long as the user stores the certificate safely and might use a Master Password. After the Master Password has been entered, Firefox does not request it again until Firefox exits. Isolated, that is okay as well. The result, though, is after the Master Password has been entered, any site could fetch the user's certificate information. As related to the digital signature issued in Denmark, any website is able to retrieve the name of the user (through Subject CN) without the knowledge of the user. Result: Any website can retrieve the name of the user. I believe this is a serious privacy issue. A site is, of course, not able to copy and exploit the user certificate itself (this is not a case of identity theft), but retrieving the name of the visiting user still is a major concern. In short: Any user certificate installed should not be presented to any website without further notice. There might be privacy issues here, as a user could be uniquely tracked by the certificate Subject SN, and maybe identified by the certificate Subject CN. Reproducible: Always Steps to Reproduce: 1. Create a webserver setup with SSL that requires client certificate validation, e.g. (for Apache): SSLVerifyClient require SSLCACertificateFile ssl.crt/some.crt 2. Wait for users to visit site (or create img-links from other sites, etc.) 3. Log or show them their own name :-) .. or just go to https://ter.dk/ with a Danish digital signature Actual Results: Firefox logs in and shows certificate info (including name of user, if user has Danish digital signature). Output for https://ter.dk/ with my signature is: Your name is: Peter Brodersen Your serial is: ... This step could be performed silently for the user. Expected Results: Firefox should ask the user about sending the certificate. security.default_personal_cert ought to be changed to 'Ask Every Time' as default value. The "Master Password" request is of little or no practical use. A user would usually enter the Master Password early in the process of surfing - maybe the user has already logged into a site with http authentication - or a certificate. https://ter.dk/ requires a Danish digital signature for succesful login. It should be easy to recreate another setup with another CA (as mentioned under "Steps to Reproduce, 1"). Two related thoughs, though: 1. security.default_personal_cert is a string? Shouldn't this be a boolean or an integer? 2. Master Password seems to be really annoying. If a user wants to log into a site that requires http authentication, after u/p has been typed, Firefox requests for Master Password. This could be ignored, and the u/p could still be saved. But if the user has entered his Master Password in advance, any further authentication requests is remembered under the Master Password. In this case some u/p's require Master Password, and some don't. Furthermore, a user can't just have his certificate protected behind the Master Password. Assuming the user visits a lot more websites requiring http authentication than certificate, he is met with the Master Password dialogue several times (if he only wants his certificate to be stored under the Master Password). I reckon this annoyance has made a lot of users turned Master Password off for their client certificate! But again, even if the user uses Master Password (and otherwise default values), a site could still fetch his subject CN without any problem (assuming the user has already entered his Master Password before visiting the site). With the propagation of digital signatures in Denmark, I believe the default settings in Firefox results
Component: Security → Security: UI
Product: Firefox → Core
Version: unspecified → Trunk
Whiteboard: [sg:investigate] → [sg:investigate] [kerh-noi]
Shorter summary: The reporter has privacy concerns, because our default behaviour is to offer personal certs to web sites as authentication, allowing a web site to learn about the user's identity.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Default Firefox certificate settings expose client signature information → Client Auth "select cert automatically" is considered a privacy issue
Whiteboard: [sg:investigate] [kerh-noi] → [sg:investigate] [kerh-coa]
-'ing. Been around for a while. Won't block Fx 3 for it. If someone disagrees, please re-nom.
Flags: blocking1.9? → blocking1.9-
This needs to block. Several European countries issue certs to every citizen (for logging into gov't benefit/tax sites) and it becomes trivial to track such users anywhere they go on the 'net and get their full real names and sometimes their gov't ID numbers. Other users have e-mail certs and these include the email address which is pretty much as identifying in most cases. Can be used to unmask users of anonymity services like TOR. The issue has been independently rediscovered and raised in public http://www.heise-security.co.uk/news/96239 There may be another dupe bug with more information, I remember Bob Lord commenting on the issue.
Flags: blocking1.9- → blocking1.9?
Whiteboard: [sg:investigate] [kerh-coa] → [sg:want P2] [kerh-coa]
OK. We'll block on this, make it a P3. Who's going to work on it? Hurry. :)
Flags: blocking1.9? → blocking1.9+
Priority: -- → P3
The bug I was thinking of is bug 395399. This bug could perhaps be duped to that one, no one likes the idea of simply flipping the pref so it asks every time. But failing a better solution in that bug, flipping the pref is an option.
Depends on: 395399
Dan, assigning to you for a decision, which might just be the sucky one of flipping the pref. Need to resolve before we ship, though.
Assignee: nobody → dveditz
Flags: tracking1.9+ → blocking1.9+
Priority: P3 → P2
I will happily flip the pref. The vast majority of our users will notice nothing unless there were attempts to abuse their privacy. For the minority where this option gets annoying there is clear UI to reset the pref, it does not require about:config hacking. If it gets too annoying then we can implement a fix for bug 395399.
Attachment #306897 - Flags: review?(cbiesinger)
Comment on attachment 306897 [details] [diff] [review] flip the pref I wonder how this works in non-english builds?
Attachment #306897 - Flags: review?(cbiesinger) → review+
looks like the answer is "just fine", http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSIOLayer.cpp#2285
Is this waiting for anything to land? /be
Fix checked into trunk.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Attachment #306897 - Flags: approval126.96.36.199?
Comment on attachment 306897 [details] [diff] [review] flip the pref Approved for 188.8.131.52; a=ss for release-drivers. Please land asap.
Attachment #306897 - Flags: approval184.108.40.206? → approval220.127.116.11+
Checked in to branch.
Looking, and this affects the 18.104.22.168 branch, and looks like we want this there.
Flags: blocking22.214.171.124? → blocking126.96.36.199+
Comment on attachment 306897 [details] [diff] [review] flip the pref a=caillon for 188.8.131.52
Attachment #306897 - Flags: approval184.108.40.206+
Does anyone have an environment available for verifying the fix? We don't have one handy in the QA lab or on our machines.
Al: can you file a bug to track the necessary test infrastructure needed to build an automated test for this (or a manual one that can be run out of the tree for litmusing)? Seems like we probably don't have a lot of coverage on this from ambient, stochastic testing of nightlies and such, so we probably want to beef up a bit. Thanks!
FWIW, when making connecting to moznet over SSL, I get asked for a personal cert (I happen to have a personal cert, unrelated to moznet, of course). If I let the server have the cert, it connects OK. If not, it asks me again and if I deny that as well it connects OK. Of course, it asks every time (twice).
In reply to comment 18, that sounds like an unfortunate configuration of whatever SSL server you're connecting to.
(In reply to comment #16) > Does anyone have an environment available for verifying the fix? The testcase from bug 395399 will work: 1) visit http://0x90.eu/ff_tls_poc.html to get a cert 2) visit https://www.apache-ssl.org/cgi/cert-export to have your cert read bug 395399 is mostly a duplicate of this one, but since it delved into the potential usability problems of simply flipping the pref (which we've done here) it morphed into developing a better UI, such as remembering cert decisions per host.
bug 359399 is not just about UI, we're lacking the back-end support required to build a better experience.
I verified this using the two sites above and a generated cert. With 220.127.116.11 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:18.104.22.168) Gecko/2008031114 Firefox/22.214.171.124), I am prompted to give my cert. If I choose not to (by choosing 'cancel'), the site does not display any of the cert information. If I do choose to ok it, the site displays the information. This acceptance is remembered for the session. Marking this as verified126.96.36.199.
MOZILLA_1_8_0_BRANCH: Checking in netwerk/base/public/security-prefs.js; /cvsroot/mozilla/netwerk/base/public/security-prefs.js,v <-- security-prefs.js new revision: 188.8.131.52; previous revision: 1.12 done
I just lived for half a day with the new default. OUCH! Ever try to do work viewing and editing content on a Wiki, only to be interrupted after EVERY single page to pick a certificate? My forecast is that people will rush to change the default back to the promiscuous mode from the new default. I fear what will end up being needed is a per-site association like we have for cookies and pop-ups so that sites seen before won't ask and ask and ask and ask and ask and ask. (Try it, you'll see I'm not exaggerating.) Is there common code in cookies and pop-ups that could be applied here for a more nuanced approach without a whole development project?
(In reply to comment #24) > Ever try to do work viewing and editing content on a Wiki, only to be > interrupted after EVERY single page to pick a certificate? That behavior indicates that the server is not implementing SSL session caching correctly, or at all. It is not the behavior that will be seen by most users of SSL/TLS servers which request client authentication. Perhaps you should speak to the administrator of the wiki server and ask why SSL/TLS session caching is not working on that server.
Thanks for that clarification. I will indeed chat with the administrator. If I may trouble you for a teeny bit more information. How should SSL session caching work properly? When is the next time I *should* see a prompt for a certificate? Is it a matter of time after the first page I have seen?
When an SSL client and an SSL server go through the full procedure of negotiating a cryptographic connection (known as a "handshake"), including any authentication, they establish a "session". The client and server are each supposed to keep the information about that session in a local store (or "cache") of sessions (typically kept in RAM memory), and to reuse it in subsequent connections, rather than going through the full handshake again every time. That session is expected to last in the cache until a) either the client or server is stopped (or restarted), b) the client or server operator manually empties the cache, or c) the cryptographic device (if one is being used) is disconnected, or c) some time limit has expired. The recommended time limit is 24 hours, although it's common to use 8 hour limits. The intended effect is that a user needs to authenticate to each server only once a day, or as often as he restarts his browser, which ever comes first.
(In reply to comment #24) > I fear what will end up being needed is a per-site association like we have for > cookies and pop-ups so that sites seen before won't ask and ask and ask and That's the subject of bug 395399.
This is a followup to comments #24 to #27. Our test server (Apache/2.2.8 (Unix) mod_ssl/2.2.8 OpenSSL/0.9.8g) has, or seems to have, proper SSL session caching (the cache file do grow, change and such). But we STILL get the "choose certificate" dialog from Firefox (2.0.12 to 2.0.14, XP and Linux) for all requests. Really bothersome.
Forget comment #29. Problem is not Firefox related, but comes from a weird Apache config. Sorry for the inconvenience.
Nelson, Thanks VERY much. The maintainer of the MIT wiki service was able to quickly able to correct the caching configuration. Now we're talking to a couple obstinate vendor partners who don't yet believe they have a problem with their web sites. :-) Thanks very much for taking a little extra time and helping me understand well enough to help others.
You need to log in before you can comment on or make changes to this bug.