User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; de; rv:1.8.0.12) Gecko/20070508 Firefox/1.5.0.12 Here is the posting I posted on tech-crypto, security and full-disclosure: While building the new OpenXPKI Live CD ... <shameless_plug>if you are looking for an (open source) enterprise-grade PKI system, consider OpenXPKI. You can now test development snapshots using our new Morphix-based live CD.</shameless_plug> ... I realised that you can do something with Firefox 2.0.x that you could not do with Firefox 1.5.x: track an unsuspecting user using TLS client certificates. Here is how it works: - The user visits a websites and leaves behind some personal data (for example on a registration form). - The website uses SPKAC using the <keygen> tag to create a private key for the user. This will pop up a dialog that says: "Key generation in progress ... This may take a few minutes ... Please wait ..." With a 1024 bit key on a modern machines, this only takes a few seconds, so it is barely noticable to the user. - Using the SPKAC data, the website creates a TLS client certificate for the user (which may contain just a unique identifier for the user and/or the personal data entered) and sends it to the user using the "application/x-x509-user-cert" MIME-type. Firefox will automatically install the certificate and pop up a dialog that says: "Your personal certificate has been installed. You should keep a backup copy of this certificate." This dialog may need some social engineering from the website to keep the user unsuspecting. But who has actually heard of a "personal certificate" except for the more technical users? One could even explain to the user what it really is without the user knowing that it will mean trouble for him. - Because Firefox's standard configuration is to automatically choose a TLS client certificate to be sent out, the certificate including the personal data will now be sent out to any website that requests it. Contrary to a typical cookie, this includes websites that are on a completely different domain. The user will not notice this at all. Caveats: - The user has to have saved a password in his password safe before. Otherwise, Firefox will ask the user to choose a password for the "software security device" during the SPKAC key generation. What other browsers do: - Firefox 1.5: Does not allow you to install a client certificate that is from a CA which you don't trust. I still believe this was a decent default setting. - Opera: During the key generation, it asks for "a master password to protect your client certificates in Opera". Note the wording, which is IMHO much more clear than the password for a "software security device". During installation, it asks whether you want to install the certificate and pops up another dialog "Are you sure you want to trust this issuer?". Before connecting via HTTPS, it pops up a dialog that says "The server requested a certificate. Please select one of these certificates or press [Cancel] to send none" and then requests the master password. - IE: Does not use SPKAC, but has a similar mechanism using the XEnroll control. With the default security settings, both requesting a certificate and installing one pop up confirmation dialogs explaining the situation and having a default of 'No'. Not that it does not have problems with certificates, though. Has anyone else ever noticed that if you have have more than a certain number of DNS subject alternative names, the certificate chain validation just breaks? This is actually a productive problem at $CUSTOMER, where they have a large webserver which has somewhere around 50 virtual hosts ... - Safari: Does not say a peep during the SPKAC request generation. Allows for 512 bit keys, btw - whoever would want a 512 bit key these days? I could not find the correct MIME type to send the certificate for installation (I'd be interested to know though if anyone has an idea), but I'd assume the installation uses keychain (at least under Mac OS X, no idea what they do on Windows), which hopefully does some prompting. - Konqueror: Pops up a 'KDE Certificate Request' wizard during SPKAC key generation which will ask for a password for the private key. I could not test this any further though, because my Konqueror installation did not create the request. Apparently, it sends 'deadbeef' though if it can now create correct SPKAC data ... :-) Allows for 512 bit keys, too. Proof of Concept: - http://0x90.eu/ff_tls_poc.html Best regards, Alex I later realized that this problem is also present in Firefox 1.5 - it is even worse there because no certificate installation dialog is presented there, this reduces the thing that a user could see to the short popup of the key generation dialog. Reproducible: Always Steps to Reproduce: A proof of concept is available at http://0x90.eu/ff_tls_poc.html This shows that the user sees very little of the actual process. Actual Results: The users has a TLS client certificate installed which will be used automatically. Expected Results: I'd expect Firefox to actually ask the user which certificates (or rather if a certificate) should be used to do TLS client auth.

The claim that "Firefox 1.5: Does not allow you to install a client certificate that is from a CA which you don't trust." is false. No version of any mozilla browser has ever required that the user's own personal certs be issued by a trusted CA. This is because the browser is not a "replying party" when using its own user's certs.

er, make that "relying party", a recipient of a cert who makes a decision whether or not to rely on the cert, and needs to ensure that a cert comes from a trusted CA before relying on it. In SSL client authentication, the server is acting as the relying party. It sends a list of issuers from whom it will accept certs, and the browser is free to use any cert from any issuer in that list. The issue presented in this bug concerns the ability to install a user cert in the browser without the browser user's knowledge. At one time there was a dialog that told the user that a new cert was being installed for him. That was removed long ago (~2001, IIRC). Maybe it should be reinstated.

The preferred solution would be to ask every time, which certificate to present for client authentication. I'm very, very much in favor for this for other reasons as well. It's about due to change that.

Eddy, You've apparently never existed in an environment in which many servers request client auth from you on a daily basis. If you did, you'd know why being asked every time is not the default. Maybe we need a whitelist, a way for the user to say "don't ask me again when this same server asks me for client auth - just do it."

@#1: Yes, I've noticed that later (it's in the paragraph below the post). No idea why I actually thought this was the case.

@#2: There is a dialog in 2.0.x, but it just informs the user. Letting him choose whether he actually wants to install the certificate would be better, I believe. And even if you are a frequent user of TLS client auth, how many times do you install a new cert? A few times a year, maybe?

@#4: But how many people use TLS client auth on a daily basis. Hell, I work in PKI, and I only use it occasionally. I am not against leaving people the option to say "do it automagically for me", but I don't think that should be the browser default. If you need it, turn it on. I like the idea of the whitelist, though.

In reply to Nelson (https://bugzilla.mozilla.org/show_bug.cgi?id=395399#c4): Of course I do! It's my daily bread I'd say...And even more to the point, specially in a bigger environment it's almost useless to have the browser choose instead of you. But even more annoying is, when user of Firefox try to login and wonder why they always login with the "wrong" certificate the moment they have more than one from the same CA. In reply to Alexander (https://bugzilla.mozilla.org/show_bug.cgi?id=395399#c7): You suggestion makes a lot of sense. The default should be, to present a list of certificates installed in the browser (or smart card). Should the user prefer to have FF do that automatic, he has the option. It also would solve the problem suggested by you from above.

First, I agree the problem is in loading a new cert without the user's knowledge. Ask always is specifically an advanced user function, one in which I would expect someone like Eddy to set, but not one we want to foist off on other user. Second, The interactions here are not as simple as one would like. There are several corner cases where all of the options chosen by various browsers do not work well I've tried to document these cases here: http://wiki.mozilla.org/PSM:CertPrompt . Smart cards in particular add an interesting challenge to mix. bob

I left a comment at the dev-tech-crypto mailing concerning the PSM:CertPrompt page. Very interesting! Still, when thinking about the costs for implementing a solution for this bug and related problems about the choosing of client certificates for authentication, opting for "Ask always" as the default would be the cheapest and fastest solution by far. In addition to that, users of competing browsers are used to such handling. And it might also solve additional problems with smart card removal/replace?

Another argument: Supposed I have three client certificates in my browser/smart card. One from Versign, one from Thawte and one from StartCom. I go to https://certifi.ca/ in order to login to this OpenID provider (just a convenient example). Which certificate does it present to the server since the server accepts all three? With all due respect, but this decision can't be left to the browser!

as a quick fix in FF2 should we just flip the pref to "ask every time"? Annoying for those who use certs, but the vast majority of users won't notice and would be protected from this problem.

Dan, I submit it would make FireFox unusable for users who use certs. There are numerous servers with broken SSL session caches that effectively request client auth on every connection. They become unusable when the user is prompted every time. If we're only concerned about the majority of users who don't use certs, we could just disable supports for user certs entirely.

How about remembering the current selection until the session expires or the browser is closed? I think this is what....errrr...another certain browser does.

And with that other browser, you cannot change roles (identities) without closing and reopening the browser, not even by change the token you have inserted, IIRC.

Correct! I think something smarter than that is needed. However the privacy/security implications of the current behavior must be evaluated carefully. Silent authentication is a problem - from every side I look at it. Also from a practical, user-centric point of view it doesn't look much better! The user is taken for a ride (even willingly), about which he doesn't know how to deal with it without plunging deep into the configuration settings. Certainly not user friendly either. Therefore I'm asking - as others did here - what would be your suggested short term fix and what would you suggest as the long term solution?

Answering some by myself. The obvious proposal for preventing authentication without the user's knowledge would be......another popup window - notifying the user about the authentication request by the server. Obviously nobody has proposed that, because how silly would that be. We already have a mechanism for doing that, called "User Identification Request". The window states the following: "The site has requested that you identify yourself with a certificate" followed by some details of the site. All we really need is to turn that thing on by default! Now, we could refine the mechanism with flags like: "Do that automatically for this site from now on" or similar ideas. However something like that could also pose some problems when the client certificate expires, in which case the user would have to choose a different (or new) certificate from the list. But it could solve the problem Nelson stated for some problematic servers.

Trying to summarize: (a) we import user certs, although they are untrusted I propose we stop doing that. After downloading, PSM can verify the cert and reject if not trusted. Objections? (b) users who already have such a bad cert Once we do (a), we won't be accepting untrusted certs any longer, but there might be users who already obtained bad certs. Should we prevent users from being able to use untrusted certs? Maybe at least for client auth? Should we do a cert-verify before using for client auth? (c) always prompt / select automatically IMHO we should not switch to "always prompt", for usability reasons mentioned in this bug. Can we change the definition of "select automatically"? We could change it to mean: "only ask once per site during session" (until we come up with a smarter solution). So, as a short term fix, we could have a in-process hashtable, where we store the associations site-to-user-cert. At first attempt during a session, we'll try to make the automatic decision. We'll show the selection UI and have our automatic choice of cert pre-selected in the UI. The user has a choice to reject/cancel (we'll remember that for the remainder of the session) and proceed without client cert for that site. If the user accepts, we'll remember this association for the remainder of the session. Opinions/objections? (d) ability to undo cert-association for a given site If we do (c), there will be that association that will live for the remainder of the process session. It will not live across sessions. IMHO this is acceptable short term. In classic Mozilla and still in today's SeaMonkey, there is menu command Tools/PasswordManager/Logout, which is also bound to clearing the SSL session cache. When the user selects this command, we could also "forget" all currently active site-to-client-auth-cert associations. Unfortunately AFAICT this menu command got removed from the Firefox UI when developers were striving for a simpler UI.

Kai, what would be your estimates in terms of investment/time for each of the points above? Do you expect any overhead/degrading in terms of speed/memory? Which part would be most affected (if at all)?

(In reply to comment #18) > (a) we import user certs, although they are untrusted > > I propose we stop doing that. After downloading, PSM can verify the cert and > reject if not trusted. Objections? I object. :-) It doesn't matter if your browser trusts the CA. It matters if the SSL web server you want to visit trusts that CA. As Nelson said, the browser is not the Relying Party. The to-be-visited web server is. > (b) users who already have such a bad cert These are not bad certs. In fact, that's a normal way to deploy certificates. > Once we do (a), we won't be accepting untrusted certs any longer, but there > might be users who already obtained bad certs. Should we prevent users from > being able to use untrusted certs? Maybe at least for client auth? Should we do > a cert-verify before using for client auth? > > > (c) always prompt / select automatically > > IMHO we should not switch to "always prompt", for usability reasons mentioned > in this bug. Always prompting is a very bad idea. In summary, we need to rethink the SSL client-auth UI entirely to address a number of issues at the same time. We can make some big wins for both occasional and heavy users, but it will require some surgery and UI changes. We should open a new bug report to track those proposals/ideas. I don't see any need to change the existing functionality in the mean time.

> Once we do (a), we won't be accepting untrusted certs any longer, but there > might be users who already obtained bad certs. Should we prevent users from > being able to use untrusted certs? Maybe at least for client auth? Should we do >> a cert-verify before using for client auth? >> >> >> (c) always prompt / select automatically >> >> IMHO we should not switch to "always prompt", for usability reasons mentioned >> in this bug. > > Always prompting is a very bad idea. I agree. We should take time and design the cert prompting UI correctly, not igoring the lessons learned from previous experience. As far as the issue at hand, for now we have a situation similiar to cookies. cookies are on by default, but recognized as a potential privacy issue. There is an option to turn them off. We also already allow the user to set 'always prompt' if they have a concern. Those users who are privacy sensitive can turn that option on today. bob

(In reply to comment #20) I think concerning a) and b) you are correct, so I guess that what Kai meant is, to prevent installation of an untrusted certificate as in the scenario reported by Alexander (bug 395399), even so the relying party is the server in this case. Concerning the rest of your reply, what are your concrete suggestions in order to fix this problem for the short and long term? It might be likely that two different solutions will have to be found, both for short and long term. However unauthorized authentication without the users consent, is in my opinion a very serious issue and not only about privacy. Users of the Mozilla browser are AUTHENTICATING without even knowing about it? And you don't see any need to change the existing functionality? Common! That's like sending the user name and password automatically on every submission form out there, without any interaction by the user....Well, the password manager has some issues ;-) But worse, in this case NSS makes also the decision which user/password pair (speak certificate) to send....And what if I don't want you to know that I have a certificate from Verisign but your server accepts it? Must a (new) user really have to figure, if/where/when this happens and if/how/where one turns that behavior on or off? Folks, you can't be serious!

An alternative suggestion - except making "Select Always" the default - would be to prompt a user to select the behavior ("Select Automatic" or "Select Always") every time a new web site requests authentication. This would be perhaps the least intrusive and fastest short term solution to this problem. How about that?

I don't think we can realistically expect to fix this in 1.8.1.8 if we don't have a trunk fix. There may even be UI involved which makes fixing the branch trickier due to translation issues.

(In reply to comment #18) > (d) ability to undo cert-association for a given site > In classic Mozilla and still in today's SeaMonkey, there is menu command > Tools/PasswordManager/Logout, which is also bound to clearing the SSL session > cache. When the user selects this command, we could also "forget" all currently > active site-to-client-auth-cert associations. > > Unfortunately AFAICT this menu command got removed from the Firefox UI when > developers were striving for a simpler UI. Correct, and it has been added back in other form (in Firefox 1.5, it looks like): menu Tools->Clear Private Data->Authenticated Sessions.

Just for reference, this is filed as CVE-2007-4879, thanks to RedHat.

With no patch here, this is at risk for Firefox 3.

Kai: is there any solution on the horizon for this bug?

Will wait for a trunk fix to back-port.

My piece to discussion: We may consider that SSL client authentication become one day frequent and common way of logging in/authentication on web sites, web services and web applications. This also leads users to have more then just a single persona to offer to web servers. Some use cases: 1. I have a single certificate to authenticate on just a single server - e.g. e-banking. I want to let just my bank server to see the certificate and no one else even it were on some white list. I (the user) don't care/know what SSL client authentication is. This is most common case now a day. 2. I have N certificates that I am using to authenticate on just a single server. These N certificates might belong to my self (my several persons) or to several people using the same FF profile (the computer actually). In such a case I a) want to choose which certificate is gonna be used to authenticate b) want to have easy way to switch persona/log-in c) potentially want to protect persons with a password (IE offers this but it is not much user-friendly, MAC OS X offers key chain protection) but don't want to switch among/(even) create several FF profiles (common users don't know how!) Thus, for those N certs I want to allow just that server to see it. This is less usual but please see https://bugzilla.mozilla.org/show_bug.cgi?id=163861#c6. 3. I have N certificates for M servers. This might be considered generalization of #2 but also I may use just subset of N certs on each server. This seems to be sound of a future. According to these use cases the white list should be per-cert and adaptable by user but prepared to allow zero-user-interaction in some limited scenario - use case #1. Also it would be very nice to have UI (as Larry is or more visible) that provides immediate knowledge that 'This site recognize you as <My Identity>'. This is probably not just power users option. This UI should IMHO also provide easy way to log out, change persona, setup the authentication automation.

After installing Firefox 2.0.0.13, I'm getting the "Choose a certificate" dialog popping up at intervals, for no immediately obvious reason (i.e. the dialog is nothing to do with the page in any browser window or tab, and nothing to do with a request initiated via the browser UI). The dialog is actually related to a "live bookmark" which references a secure site. Having the dialog pop up apparently at random is *very* annoying. I want to be able to configure Firefox so that my certificate selection (I have more than one certificate, representing different personas) can be made permanent for the server (or for the certificate presented by the server).

A the very least, the dialog must tell the user WHO (what web site or other server) is asking for this information.

bug 431819 is a partial implementation of this, but keeps the association only in memory because we couldn't add UI for managing the selections on the branch. For the branch it will at least reduce Dave.Sparks' annoyance to a single interruption per browser start. For Firefox 3.1 we should fix this the right way and remember the association, which means some rudimentary UI for changing or at least deleting those associations. I've nominated for blocking, but I guess if push came to shove we could limp along with the fix in bug 431819 which is better than nothing.

Sounds like an NSS bug, feel free to assign back if i'm wrong.

Okay. :)

Nelson: Ok, could you please help me triage this bug then (as far as blocking or not, and priority), as I don't really know most of what's being discussed here.

Jonas, a personal cert is a crypto key pair with a signature that certifies ownership. a personal cert can be used to identify to protected content on web sites (or any SSL server), instead of providing a username/password PSM has the ability to either "choose one automatically" or "prompt the user to select one". The "choose one auto" feature has been declared as a privacy issue, so the default was changed to "prompt always". But the setting "prompt always" is very annoying to users who require this feature. This bug proposes to have a list of servers (user configured) for which the user allows the "select auto" feature, while keeping the "prompt" setting for all other (unknown) servers.

Right. The implementation of this requested feature requires more UI, UI that provides a way to manage a list of sites, much like the UI for managing lists of sites that are permitted to set cookies or that are not permitted to set cookies. Anything that involves UI is PSM. NSS doesn't do UI. PSM does all the UI related to NSS for Mozilla products. Also, this is very browser specific, and is not a feature of interest to other SSL clients or servers, which is another reason why this belongs in PSM and not in NSS. (NSS is used by MANY non-Mozilla products also).

Ok, doesn't sound like a blocker to me then. And not something that terribly many people would use (or is the hope that they will in the future?). Setting wanted but with low priority.

Hasn't this been fixed by now?

Same problem for me.

Dup of bug 32010?