Open Bug 475881 Opened 16 years ago Updated 2 years ago

Private browsing mode warning doesn't mention that newly-installed client certificates are not cleared when exiting private browsing mode

Categories

(Firefox :: Private Browsing, defect, P3)

3.5 Branch
defect

Tracking

()

Tracking Status
status2.0 --- ?

People

(Reporter: KaiE, Unassigned)

References

Details

(Keywords: privacy, Whiteboard: [pb-paper][psm-privacy])

The intention of Private Browsing mode is to not record any cookies sent by sites. However, a site might use JavaScript or HTML tags (KEYGEN) that can be used to produce a public/private key pair in the user's profile. A site might also generate a certificate (for this new keypair) on the fly and have the user accept and import it. Such a personal certificate might be seen as a "super-cookie". Should a user have changed their "SSL client auth" preference to "select automatically", the user might be tracked based on this certificate, even after having left the PB mode. Even with the default setting, which is to prompt the user when a site requires identification using a personal certificate, the end user might not realize he will confirm to use this super-cookie in regular mode, which has been acquired during PB mode
The primary design guidance for private browsing mode is around local traces, not anonymity (despite the somewhat confusing "Mask" iconography) - it can't really make that claim anyhow, given the surprising number of ways that data can be gathered (e.g. flash cookies). Nevertheless, saved certificates could serve to identify the sites you've visited after exiting private browsing mode, which does contravene the primary design purpose, so it would be nice if we could do something better here. If we can't, it would be nice to at least say so.
Whiteboard: [PB-P2]
Can wait, in the absence of a patch.
Priority: -- → P3
Target Milestone: --- → Firefox 3.2a1
If I understand this correctly, the main goal here is disabling installing user certificates inside private browsing mode and preventing such certificates to be sent to the servers inside this mode as well. Besides window.crypto.importUserCertificates, is there any other way for sites to install user certificates?
OS: Linux → All
Priority: P3 → --
Hardware: x86 → All
Target Milestone: Firefox 3.6a1 → Firefox 3.5b4
Priority: -- → P3
Target Milestone: Firefox 3.5b4 → Firefox 3.6a1
I know two ways to get to a user cert: (a) - You submit a form with <KEYGEN> html tag which produces a key pair and remembers the private key in the profile's NSS database - You access an URL that delivers a corresponding cert for the mime type application/x-x509-user-cert - you know have a personal cert in your NSS database Example site: https://digitalid.verisign.com/client/class1Netscape.htm This example is multi-step and involves checking email, but an attacker could skip the verification and immediately deliver a cert for tracking purposes. (b) Instead of using <KEYGEN> it's also possible to use JS function crypto.generateCRMFRequest
(In reply to comment #4) > This example is multi-step and involves checking email, but an attacker could > skip the verification and immediately deliver a cert for tracking purposes. This was however fixed mainly by prompting for each action, being it generation of a private key and certificate request, installation of the certificate and before sending any client certificate for authentication purpose if a server requests it. Of course there is a trace (of the installed certificate), not sure if this is of concern to private browsing.
If the intention of Private Browsing mode is "we don't record anything that happens here", then importing a cert is breaking that intention.
Right! But still allow authentication. In case keys will not be generated and certificates not installed, a meaningful message should be displayed to make the user aware.
(In reply to comment #6) > If the intention of Private Browsing mode is "we don't record anything that > happens here", then importing a cert is breaking that intention. What about importing a private key? Would that also be considered as data which can be somehow used to track the user? (In reply to comment #7) > Right! But still allow authentication. In case keys will not be generated and > certificates not installed, a meaningful message should be displayed to make > the user aware. I don't think we should allow authenticating with user's certificates inside the private browsing mode, and we don't really need to prompt the user, just like we won't prompt them when we refuse to send their normal session cookies in private sessions.
We can't blanket disallow _using_ client certs inside private mode any more than we can tell users they aren't allowed to use password forms. If the user already has a cert we should definitely let them use it. This is in reference to the last paragraph of comment 8 which is a somewhat separate issue from the starting point of this bug: what if a site tries to give a user a new cert?
(In reply to comment #9) > We can't blanket disallow _using_ client certs inside private mode any more > than we can tell users they aren't allowed to use password forms. If the user > already has a cert we should definitely let them use it. This is in reference > to the last paragraph of comment 8 which is a somewhat separate issue from the > starting point of this bug: what if a site tries to give a user a new cert? OK, so we have two separate issues here if I'm understanding things correctly. First, we should allow users to use the client certs that they have installed outside of the private browsing mode. Second, we should somehow handle the certs sent to them via websites from within the private browsing mode. For the former case, would changing the cert sending option to "Ask everytime" be enough? What do you suggest for the second case?
Assignee: nobody → ehsan
status2.0: --- → ?
Whiteboard: [PB-P2] → [pb-paper]
Target Milestone: Firefox 3.6a1 → ---
I propose: 1. This bug be re-summarized as "Websites can install client certificates without user interaction." Then, we should resolve this bug by making sure that client certs are only installed after a specific user action. That is, this is not a bug that affects only private browsing. 2. When the user switches to private browsing mode, we already warn that "files you download and bookmarks you make will be kept." A new bug should be filed to ammend this warning to include "client certificates you install".
Keywords: privacy
Whiteboard: [pb-paper] → [pb-paper][psm-privacy]
(In reply to comment #11) > I propose: > > 1. This bug be re-summarized as "Websites can install client certificates > without user interaction." Then, we should resolve this bug by making sure > that client certs are only installed after a specific user action. That is, > this is not a bug that affects only private browsing. This is actually already filed as bug 251690. > 2. When the user switches to private browsing mode, we already warn > that "files you download and bookmarks you make will be kept." A new > bug should be filed to ammend this warning to include "client > certificates you install". Let's make this bug about that.
See Also: → 251690
Summary: In Private Browsing mode Firefox should not allow acquiring personal certificates → Private browsing mode warning doesn't mention that newly-installed client certificates are not cleared when exiting private browsing mode
Depends on: 251690
(In reply to Kai Engert (:kaie) from comment #6) > If the intention of Private Browsing mode is "we don't record anything that > happens here", then importing a cert is breaking that intention. So... in the absence of discussion about how to handle this, why not redirect writes to the keystore under private browsing mode to an in-memory PKCS11 object? Oracle's Sleepycat db3+ will run against a database located entirely in-memory. I don't know if older BSD distributions can. db5+ also include a version of sqlite which is optimized to run with the KVP datastore. (Caveat licensee: Sleepycat db3+ are licensed under dual commercial/GPL, they may not be appropriate for use in Mozilla.)

Hello,

It seems I am observing similar issue.
Currently I am using locally generated SSL certificates for deploying and testing web apps.

When accessing the local web-service in Private Browsing mode I do get a initial warning about certificate authenticity.
When I add the local web-service to exception list, it seems that Firefox saves the certificate exceptions in the Certificate cache.

And the website exception is maintained in Firefox normal mode.

Can the certificate exception be dropped after the Private Browsing mode is ended?

In other browsers, I do not observe such behavior.

Will there be an update on this behavior?

Regards,
Ameya Vikram Singh

Assignee: ehsan → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.