295922 - (CVE-2007-4879) Client Auth "select cert automatically" is considered a privacy issue

Status: RESOLVED FIXED

(Core Graveyard :: Security: UI, defect, P2)

Description

[Peter Brodersen]

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

Comment 1

[Kai Engert (:KaiE:)]

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.

Comment 2

[Damon Sicore (:damons)]

-'ing.  Been around for a while.  Won't block Fx 3 for it.  If someone disagrees, please re-nom.

Comment 3

[Daniel Veditz [:dveditz]]

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.

Comment 4

[Damon Sicore (:damons)]

OK.  We'll block on this, make it a P3.  Who's going to work on it?  Hurry.  :)

Comment 5

[Daniel Veditz [:dveditz]]

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.

Comment 6

[Mike Beltzner [:beltzner, not reading bugmail]]

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.

Comment 7

[Daniel Veditz [:dveditz]]

Attachment: flip the pref

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.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 306897 [details] [diff] [review]
flip the pref

I wonder how this works in non-english builds?

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

looks like the answer is "just fine", http://lxr.mozilla.org/seamonkey/source/security/manager/ssl/src/nsNSSIOLayer.cpp#2285

Comment 10

[Brendan Eich [:brendan]]

Is this waiting for anything to land?

/be

Comment 11

[Daniel Veditz [:dveditz]]

Fix checked into trunk.

Comment 12

[Samuel Sidler (old account; do not CC)]

Comment on attachment 306897 [details] [diff] [review]
flip the pref

Approved for 1.8.1.13; a=ss for release-drivers. Please land asap.

Comment 13

[Daniel Veditz [:dveditz]]

Checked in to branch.

Comment 14

[Christopher Aillon (sabbatical, not receiving bugmail)]

Looking, and this affects the 1.8.0.15 branch, and looks like we want this there.

Comment 15

[Christopher Aillon (sabbatical, not receiving bugmail)]

Comment on attachment 306897 [details] [diff] [review]
flip the pref

a=caillon for 1.8.0.15

Comment 16

[Al Billings [:abillings - ex-MoCo]]

Does anyone have an environment available for verifying the fix? We don't have one handy in the QA lab or on our machines.

Comment 17

[Mike Shaver (:shaver emeritus)]

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!

Comment 18

[Andrew Schultz]

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).

Comment 19

[Nelson Bolyard (seldom reads bugmail)]

In reply to comment 18, that sounds like an unfortunate configuration of 
whatever SSL server you're connecting to.

Comment 20

[Daniel Veditz [:dveditz]]

(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.

Comment 21

[Daniel Veditz [:dveditz]]

bug 359399 is not just about UI, we're lacking the back-end support required to build a better experience.

Comment 22

[Al Billings [:abillings - ex-MoCo]]

I verified this using the two sites above and a generated cert. With 2.0.0.13 (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/2008031114 Firefox/2.0.0.13), 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 verified1.8.1.13.

Comment 23

[Reed Loden [:reed]]

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: 1.12.92.1; previous revision: 1.12
done

Comment 24

[William Cattey]

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?

Comment 25

[Nelson Bolyard (seldom reads bugmail)]

(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.  

Comment 26

[William Cattey]

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?

Comment 27

[Nelson Bolyard (seldom reads bugmail)]

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.

Comment 28

[Daniel Veditz [:dveditz]]

(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.

Comment 29

[Violhaine Grimly]

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.

Comment 30

[Violhaine Grimly]

Forget comment #29. Problem is not Firefox related, but comes from a weird Apache config. Sorry for the inconvenience.

Comment 31

[William Cattey]

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.