396441 - Improve SSL client-authentication UI

Status: NEW

(Core :: Security: PSM, enhancement, P3)

Description

[Bob Lord]

The Firefox UI presented to the user during SSL client-auth needs improving.  There are several important deficiencies, especially for users who have more than one certificate.

Here are some elements that I'd like to see in a design:
* works well for people who have only 1 cert, and use it rarely
* works well for people who have several (or many) certs, including 1 or more smartcards, including people who need to logout of a single SSL client-auth session and to login to the same server using a different certificate
* involves the user in authentication decisions, but doesn't get in the way
* doesn't bother people who do not have personal certs or smartcards
* does not require a preference for certificate selection
* works well in simple deployments, but also complex ones (like the US Federal Bridge deployment)
* Works well for people who have smartcards but don't have them plugged in right now. 

To that end, I see a model that has these elements:
* The first time you visit a site requesting a certificate, the browser asks you which cert you want to use.  It asks, even if you have no certificate.  That gives you the ability to insert a smartcard.  It also addresses the concern of people who believe automatic certificate selection might lead to leakage of some privacy-related information.
* The authentication UI has a "Remember this decision"-style checkbox to save the cert/site association
* The 'remember' decision should be inherited for all supplementary data loaded from a page (images, etc). Otherwise, it would difficult to have UI to show the current login state, and to logout.
* There needs to be a way to forget individual associations
* There needs to be some obvious way, hopefully in the chrome, to show exactly which certificate I used to login to this site.
* There should be an easily discoverable way to change certificates, and to logout.  Maybe we add a popup in the Status Bar that includes a list of all available certificates, as well as a Logout option.
* If you select a certificate for a particular site and do not ask the browser to remember the association, it should not keep asking which cert to use when new images/pages are loaded.  In other words, the behavior would be equivalent to "Remember this decision until I close the browser or click the Logout button".
* The client should not rely solely on the CA "hint" the server sends down in the SSL handshake.  That hint does not help in complex environments with CA cross signing in the deployment. Instead, the client should use the hint to highlight or to sort the personal certs that match the acceptable CAs.  Other certs should also be presented as valid options.
* If the last time you used a smartcard to login to this site, there should be some way of reminding the user. Perhaps that certificate shows up in the list, but grayed out with some notice that says "Smartcard not currently plugged in".

There are holes in this back-of-the-envelope proposal. There are cases that it does not address well. But I do think it should be possible to come up with a plan that will dramatically improve the usability of client-certificates.  We'll need help from many interested parties, including some UI work.

Comment 2

[Nelson Bolyard (seldom reads bugmail)]

Bob, I agree with nearly all that you've written, but please elaborate on 
your remark that "That hint does not help".  
The standard doesn't consider it to be a "hint", and calling it a "hint"
colors our conversation.  So let's call it the server's trusted CA list.  
I'd like to understand how/why it is considered unhelpful.

Is the problem that the user has too few cert choices? 
or that the user has too many choices, too many certs from which to choose?

If too few, which of these is (are) thought to be the cause(s)?

1) many servers are misconfigured and send the wrong information, identifying
fewer CAs than they actually trust, giving the user too few choices?

2) our old pre-libPKIX code only pursues a single issuance path, and so doesn't find certs that issue from roots above bridges, giving the user too few choices?  (And if so, won't libPKIX eventually solve this, with its ability to pursue all issuance paths for a cert?)

3) browsers and/or smart cards have incomplete cert chains, and hence don't have the intermediate CA certs necessary to determine that the user's certs were issued by one of the CAs in the server's trusted CA list, causing user
certs not to appear among the choices?

I'd also like you to elaborate on some other aspects of the certs that
we show the user, from which he can choose.

Do you propose that we show the user both valid and expired certs? 
(as PSM does now under some circumstances) ?
How about revoked certs?

Do you propose that we show the user non-signing certs?  NR certs?

When the user has multiple certs with the same subject name from the same
issuer, do you propose that we let the user choose a specific one from 
among them?  

As long as we're looking at client auth cert selection, we should consider
the existing bugs/rfes about it.  Here are some.  I think several of these
will be resolved when this bug is resolved.  Some of these are probably dup's.
(these will be links on the b.m.o page for this bug, or use the URL above)
- bug 32010
- bug 91495
- bug 91497
- bug 98972
- bug 100989
- bug 124187
- bug 135403
- bug 149673 
- bug 159274
- bug 163861
- bug 278689
- bug 295922
- bug 313945
- bug 322145    	
- bug 327001
- bug 350612
- bug 392790
- bug 395399

https://bugzilla.mozilla.org/buglist.cgi?bug_id=32010,91495,91497,98972,100989,124187,135403,149673,159274,163861,278689,295922,313945,322145,327001,350612,392790,395399

Comment 3

[Bob Lord]

(In reply to comment #2)
> 2) our old pre-libPKIX code only pursues a single issuance path, and so doesn't
> find certs that issue from roots above bridges, giving the user too few
> choices?  (And if so, won't libPKIX eventually solve this, with its ability to
> pursue all issuance paths for a cert?)

This is the particular issue that caused me to add the comment about the Trusted CA List not being reliable.  I have talked to people in very large organizations that use cross-signed bridges.  Here's how the deployment has been described to me: Some web servers are configured to allow anyone whose cert chains to the corporate bridge to login to that web server.  So any employee from any department in any country can see certain common, cross-department information (HR policies, legal statements, etc.).  In these cases, the web server does always not know which of many independently operated CAs might be valid. And keeping that list current in hundreds of web servers is too much work to be done reliably. 

These admins are considering using SCVP trust servers (or similar technologies) to perform the path construction and validation of the user certs, meaning the web server isn't configured to trust CAs, but to trust the SCVP nodes. All of which means the server will have a hard time telling the client which CAs it will trust. 

It's possible that LibPKIX support in the client will be able to address the current limitations. We just have to make sure it works in the many use cases already in production in the field. (Or at least a critical mass of them)


> 3) browsers and/or smart cards have incomplete cert chains, and hence don't
> have the intermediate CA certs necessary to determine that the user's certs
> were issued by one of the CAs in the server's trusted CA list, causing user
> certs not to appear among the choices?

We see this now (with smartcards especially).  Perhaps it becomes a thing of the past when the client can easily discover paths with LibPKIX?


> Do you propose that we show the user both valid and expired certs? 
> (as PSM does now under some circumstances) ?

Some deployment use expired certs to obtain new, valid certs.  This is a questionable practice. Perhaps we consider ways to tighten it up? From a UI perspective, it would also be a mess to keep showing expired certs, especially in those cases where people get certs every, say, 6 months. 

There might be some merit in somehow letting the user know "You have a cert that, if it were not expired, would have worked." Showing expired certs would be one UI technique, but I'll bet there are better ways. Even experienced users may not know how to troubleshoot this condition, and saving a help-desk call would be very, well, helpful. 

> How about revoked certs?

That seems like a bad idea, yes?


> Do you propose that we show the user non-signing certs?  NR certs?

Maybe?  Are there places where NR certs are used in SSL client-auth to make some attestation? 


> When the user has multiple certs with the same subject name from the same
> issuer, do you propose that we let the user choose a specific one from 
> among them?

If we can programatically and accurately reduce the list of decisions for the user, we should.  Are there cases where this is not possible, or non-deterministic?

Comment 5

[Henry Story]

Bug 502343 "display client certificate selected" was marked as a duplicate. It adds a new element to the discussion though, as the spread of the foaf+ssl protocol ( http://esw.w3.org/topic/foaf+ssl ) could enable the widespread use of client certificates.

Comment 7

[Henry Story]

bug 502344 "certificate selection mechanism presents too much information" was marked as a duplicate of this bug. It also has links to pictures on how this works in other browsers.

Comment 8

[Henry Story]

Hi all, this may seem somewhat unusual, to place an invitiation to a camp in a bug report, but I believe this would be a place for those of you working in the Bay Area, to get an idea exactly why this bug report is so important to the Mozilla platform.  First of all here is description of how it works in Fennec, which is it works, but you just need to implement a few UI improvements:

  http://blogs.sun.com/bblfish/entry/foaf_ssl_in_mozilla_s

If you are in the Bay Area November 2, there is a Social Web Camp at Sun Microsystems, where it should become clear why there is a lot at stake in getting this right:

  http://barcamp.org/SocialWebCamp-Santa-Clara

Comment 9

[Nelson Bolyard (seldom reads bugmail)]

The web page   http://blogs.sun.com/bblfish/entry/foaf_ssl_in_mozilla_s
criticizes Fennec's client authentication certificate selection dialog 
for displaying a URL as part of the certificate identification.  What it 
fails to appreciate is that the issuer of that client certificate put that
URL into the certificate field that is supposed to contain the name of the
certificate's subject (the human user) as commonly spoken.  Fennec is 
attempting to display the name from the certificate field that should contain
the user's name, and through no fault of Fennec's, that field contains a URL.
The web page criticizes Fennec for this, as if this is a fault of Fennec. 
If the certificate issuer wants to see the user's name displayed, rather 
than the a URL, then it should put the user's name in the Common Name field
where it belongs, and not put a URL there. 

Next, the page criticizes Fennec's cert selection UI for displaying both the 
subject's common name and the issuer's Common Name.  Perhaps the author of 
that critique has never experienced the phenomenon of having multiple certificates issued by various issuers, all issued with the same subject 
common name.  When all the issuers issue a cert for "John Smith" (as one 
might well expact they would do), it doesn't help John to show him that all
his certs are for "John Smith".  It help's him to see that he has a cert 
from issuer A and a cert from issuer B, etc.  That's what Fennec does.  

While the client authentication certificate selection dialog may indeed 
continue to have room for improvement), changing it to fit the expectations 
of a certificate issuer that has apparently ignored the standards for 
certificate name fields (attributes) is probably not the right way forward.
Changing the issuer to follow the standards will probably produce better 
results. 

/Nelson Bolyard, Sun Sr. Staff Engineer.

Comment 10

[Henry Story]

Thanks Nelson for your comment.  

sorry for taking so long to accept your post. I have been very busy recently organising the Social Web Camp in Santa Clara.

On point 1: you are completely right that http://foaf.me, which created the certificates, should not be putting the User's URI in the certificate CN. It should be as you say, his pronounceable name. In fact I would suggest creating names such as "Joe Smith (personal)" or "Joe Smith (professional)"

On point 2: You are right that if a user had different certificates, each where the CN was the same name, then this would be a problem for the user selecting the certificate. But clearly this is not the only solution available to a UI designer. It should be relatively easy to allow
- the user to tag certificates named in the same way, in such a way as to help him distinguish them. The UI could then display things like Joe Smith (Professional) or Joe Smith (personal)
- The UI can show more information about each certificate, but only so much as is required to clearly distinguish the certificates. (So perhaps the CN of the user and of the Issuer).

Once these tricks are built in to the user interface to help the user select among his certificates, then the other details, that most people do not understand, should be hidden but available to anyone who wishes to inspect them, on a click of a button. Opera does this quite nicely.

[PS, there is also the problem pointed out in that blog that I could not find how to edit certificate preferences in Fennec]

Comment 11

[Nelson Bolyard (seldom reads bugmail)]

As seen by the underlying crypto library that keeps the database of 
certificates, the string that identifies the user's certificates, the one 
that the browser presents to the user in the cert selection dialog, is a 
free-form UTF8 string.  Years ago, the browser would require the user to 
enter the value for that string whenever a new user certificate was imported.  
Invariably, for the user's first certificate, the user would enter 
"my certificate" or "<my name>'s certificate".  For his second certificate, 
the user would either attempt to enter that same string again, or would add 
the word "second" to it, e.g. "my second certificate", which was 
insufficiently mnemonic to enable the user to make good choices later on.  

The current scheme, where the browser presets the string with the combination 
of user's common name and issuer's organization name has obviated the cert 
naming learning curve for browser users, and has served the needs of most
of those browser users who have user certificates very well.  

Giving the user the ability to edit the "nikname" string for any of his user certificates might be a nice touch, although it runs the risk of reintroducing that learning curve for a great many who could get by nicely without it.  There's a separate RFE for that.

Comment 12

[Henry Story]

"Years ago, the browser would require the user to enter the value for that string whenever a new user certificate was imported."

ok, this is clearly a bad policy. Don't ask the user to create distinctions when none are needed, or before the user himself feels the need for one.

"The current scheme, where the browser presets the string with the combination 
of user's common name and issuer's organization name has obviated the cert 
naming learning curve for browser users,"

Ok that's not that bad as a default, though when there is no clash of name, I would just suggest showing less information, so just the Common Name, and I would try to indicate more clearly in human language or in a clearly visible way, the part of the name that is certified and the part that is that of the certifier. (And I don't mean by using abbreviations like CN=)

For a computer, there is not really so much as too much information. For people though, the opposite is true. The more information you present to the user, the less he will see. (That is why Google was right to put just one search box and a a button or two on their home page).

So when a user who has never used a certificate in his life, gets the pop up shown on my blog, what is he meant to think? Is he meant to think that it is important to know the port number of the service he is connecting to? And what if he does not understand that? Is he meant to understand what CN= stands for? What serial numbers stand for? He is going to think that since he is given all this information it is relevant to his making the decision. And so inevitably he will be confused.

But all really we usually need the user to select, is which certificate he wants to choose. What personality does he want to have on this web site. And THAT is currently hidden. The user has to notice that his name is a  clickable menu bar, from which he can choose different names. So the piece we are asking the user to select from is hidden, and the information most users won't understand is visible. 

That is the problem. The information about the certificates should be visible easily on demand, as extra verification info. But the first thing the user should see, especially on space restricted telephones, is a list of identities he can choose from.

You can see that both Opera and Safari do it that way. Opera makes it easy to find the extra information, though I would not say that a button giving access to the extra information is the only and best way to do this. I think one could do even better than that.

Comment 13

[Henry Story]

Btw, I wrote up a detailed post on how the Weave Identity Account Manager projec functionality could be applied to this problem:

http://blogs.sun.com/bblfish/entry/identity_in_the_browser_firefox

Comes with pictures and links to a post by Aza Raskin.

Comment 14

[Henry Story]

In Firefox if a user mistakenly canceled the certificate selection box, and the server then refuses access to a protected resource, that behavior remains until the browser is restarted. 

In Opera, the error page will explain why the connection failed, and allow one to restart the connection. This would be a very small but very useful change. Should one open a new bug report for this?

Comment 15

[Henry Story]

Client side certificates are used widely by very large institutions. The French internet minister Nathalie Kosciusko-Morizet just lauched Idenum, a client side certificate based ID scheme.

 on her blog: translation http://is.gd/7Zr2I she goes into the pros and cons.

To tell the truth I can't tell if this is using X509 client side certificates. But I can't really see any other solution.

Comment 16

[Henry Story]

Google Chrome are working on fixing the whole client certificate piece. It now works with the latest nightly releases. Also they working on allowing the user to see what certificate was used. Check out issue 29784

    http://code.google.com/p/chromium/issues/detail?id=29784
   
They are developing a simple User Interface, that should make it easy to change certificate.

(Now I should probably not be posting this on April Fool's day... ;-)

Comment 17

[Kai Engert (:KaiE:)]

I had announced the following proposal in the mozilla.dev.tech.crypto newsgroup 2 weeks ago:

http://kuix.de/mozilla/sslauth/

Comment 18

[Henry Story]

I just thought of the final piece that would completely nail the User Interface. I am not 100% sure but I thought it would be worth writing down here.

Let us imagine a future secure web where everything is behind https. (Why not? it's cheap now!) Imagine some friend sends you an https link to content on some site. You arrive at the site and the server is set up for optional client certificate usage. Bang! Up pops your browser asking you to select a certificate. 

Problem: you don't yet know which site you have arrived on, or even what kind of site it is, or what the resource is! And it is asking you for a certificate. So really what you want to do is click "Cancel" on the certificate selection box to first check out the site a bit before you give away your identity. But then as things are currently you cannot change your certificate later on and are forever stuck being anonymous - well you have to restart your browser, but that is just as bad. 

What is needed is simply for the URL bar to show the server certificate used but to also show the client certificate used, and to click on it and change the certificate. This is what the Google Chrome folk are exploring here

   http://bit.ly/bMOEpl


Another problem is that of course you should not even have to click "cancel" the first time you reach a site. You should be able to choose to be logged in by default as anonymous on any new https sites that optionally requires your certificate. The browser bar can blink a bit to alert you to the fact that you can login to this site if you like it. To log in you would just click on the "anonymous user" next to the logo of the site you are connected to - (here it is mozilla.org)

The advantage of this simple User Interface feedback will be manifold. Not only will the user know what certificate is used when he is logged in, but he will be able to change his login any time. 

This would essentially then have fully integrated identity into the browser at very little cost, and we could finally completely deploy https.

Comment 19

[Henry Story]

A quick note to people following this bug report. The W3C has started a WebID Incubator Group at http://tinyurl.com/webidxg . If you are reading this then you are probably an expert and are invited to join as invited expert by following the procedure described here  http://www.w3.org/2004/08/invexp.html .
In short:

 1. you create an account at the W3C
 2. you ask for invited expert status on WebID XG

( if you are already member of the W3C then things should be a lot easier, just follow the link on the WebID XG page. You may need to ask your W3C representative )

Comment 20

[Henry Story]

As a a matter of interest the WebID XG at the W3C has submitted a paper "The WebID Protocol & Browsers" that covers the issues here. The paper was accepted for the upcoming W3C Workshop on Identity in the Browser 24/25th May 2011, taking place in Mountain View (USA)

    http://bblfish.net/tmp/2011/04/26/

Comment 21

[Henry Story]

So that W3C meeting given at Mozilla's headquarters in Mountain View is over. Below is a blog covering what went on there with pointers including a 10 minute video of the WebID talk, packed full of demos, and ideas very relevant to this issue

   http://bblfish.net/blog/2011/05/25/

Also a short video showing how to use a crypto key in an internet cafe with WebID.

Comment 22

[Niclas Hoyer]

As there were some updates to the Site identity UI, wouldn't it be feasible if we integrate WebID with further updates on this? Maybe the Mozilla UX Team could have a look at this issue.

http://blog.mozilla.org/ux/2012/06/site-identity-ui-updates/

Comment 23

[Ikonta]

www-client/firefox-17.0.6 (amd64 build)
"Remember this decision" function for certificate choice still inoperable.
Maybe, issue is not at remember phase, but in fit one (see bug #877561 ?).

For test purposes I need to keep installed in my browser's profile several client certificates verified by the same CA.
Currently it uses (fits) last imported certificate. I remember such behaviour at least since 3.6-branch.
It would be very nice to make auto-fit remembered cert function operable.

Issue (inoperability of "Remember certificate decision" function) listed in some independent bugs:
#503664
#523336
#538133
#634697

Comment 24

[g.rossolini]

Hi,
Without focusing at all on the technical aspects, is it possible to have a better UI for this modal box? I am talking about just the appearance of the modal box.
Other browsers have a perfectly understandable UI for non-technical people, while Firefox has such a modal that most people I interact with on a day-to-day basis say "bleh, just say Yes".
I believe the current UI of this modal is a hindrance for Firefox users who have a choice between Firefox and other browsers (ie. Chrome in my case), which in turn slows down the adoption of the client certificate technology.
I believe this is a very useful technology in some cases (mine is back office authentication and ACL in a small company). BUT the UI of this one modal (that users see every morning) relegates Firefox to the rank of an "undesirable browser" for non-technical users (and then some), and they choose Chrome instead.
Best regards,

Comment 25

[nicola greco]

+1, a slightly nicer UI would make a difference for people using it

Comment 26

[Ikonta]

(In reply to g.rossolini from comment #24)
> Other browsers have a perfectly understandable UI for non-technical people
For my experience the concept of client certificate is not clear for non-technical users.
So, almost always they need in help.
And on this side alternatives to FF (I know new Opera and Chrome/Chromium) is far from perfection.

> I believe the current UI of this modal is a hindrance for Firefox users who
> have a choice between Firefox and other browsers (ie. Chrome in my case),
> which in turn slows down the adoption of the client certificate technology.
> I believe this is a very useful technology in some cases (mine is back
> office authentication and ACL in a small company). BUT the UI of this one
> modal (that users see every morning) relegates Firefox to the rank of an
> "undesirable browser" for non-technical users (and then some), and they
> choose Chrome instead.

I agree with the task of review certificate handling UI.
But we should NOT copy other, probably more popular, solutions.
We need not only to review UI and try to find the best solution, but also we need to work under populating developed solution.

Comment 27

[g.rossolini]

(In reply to Ikonta from comment #26)

That's it exactly: end users don't want to understand everything about client-side SSL certs, and maybe they shouldn't need to. There is some kind of teaching involved, but it shouldn't have to require much of it.

I most assuredly don't know all use cases. I only know mine: each user has 1 (or possibly two) SSL cert to facilitate their authentication on an internal network for back-office use.

Over time, I have seen my users build a preference for Google Chrome and not Mozilla Firefox. One reason I know of, is this exact problem that the SSL client cert auth dialog is unfortunately not user friendly. They simply don't get what is asked of them, and they click either button presented to them as if it didn't matter. And why sould it matter to them? We developers didn't take the time to make things understandable to users. I mean, there are not even any newlines in the displayed dialog (there hasn't been for years, at least). Even a tech-oriented person would lose patience very quickly, when confronted with this on a daily basis.

I'm not saying "just copy popular browsers, they nailed it". I'm saying "maybe there's some middle ground to be found as a temporary measure, while the right solution is being figured out". Just don't keep that dialog as it is. Please.

Maybe the right solution would involve an admin (the one who installs the certs) configure the fields that will be displayed in the dialog? Who knows.

In the use case I've described, a few newlines and tabulations would be enough. Nothing complex, nothing fancy unless you are so inclined. Anything that represents key/value pairs in a sensible way would do, I'd guess (think dl/dt/dd HTML structure, maybe with some bold). There'll always be time later for a proper UI.

As a matter of fact, it seems like firefox-v43 is a bit better at this than the version I was using when I posted my initial comment. That's a nice touch.

Best regards,

Comment 28

[Ikonta]

(In reply to g.rossolini from comment #27)
> Over time, I have seen my users build a preference for Google Chrome and not
> Mozilla Firefox. One reason I know of, is this exact problem that the SSL
> client cert auth dialog is unfortunately not user friendly.

Just related note:
For my experience the first reason to use Google Chrome as an alternative to IE is that its Windows build uses system (OS-level) certificate storage at the time when FF uses it's own one.
The similiar (OS-level global, i.e. for all applications) software certificate storage for Linux, or, globally, Free *nix, I don't know.

Comment 29

[Victoria Wang [:victoria]]

Some new planning and design discussion for this ancient bug is happening on github :) https://github.com/devtools-html/planning/issues/1

Comment 30

[melvincarvalho]

Thanks so much for looking at this.  I've literally been waiting 11 years for this day!

Comment 31

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.

Comment 32

[Marco Castelluccio [:marco]]

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.