Improving SSL client auth and bad certificate reporting in non-browser applications
Kai Engert
The primary intention is to improve the functionality of SSL client
authentication in Mozilla software.
In short, we'd like to stop the current prompts and implement a better
user interface.
The basic idea is to show an indicator in chrome whenever a site asks
for client authentication, and give the user full control over using a
personal certificate for authentication (or not using one). The
interface should also support persistent configuration, per site. It
should be powerful enough to support complex sites and work with
appearing/disappearing certs which are stored on smartcards.
While brainstorming on above solution, I concluded that its core idea (a
chrome indicator for SSL authentication state) could be extended to
cover bad SSL server authentication status, e.g. server certs which can
not be chained to a trusted root cert.
Although we have a good solution in the browser (show an error page,
allow override), the solution in non-browser applications (e.g.
Thunderbird) is inferior. In version 3.x Thunderbird kept using a
click-through approach.
When a non-browser application encounters a bad certificate, we should
no longer show a prompt that allows click-through. Instead, we should
use an error status indicator in the chrome (for one or multiple
failures), and have users access it to deliberately add an exception.
Any application could use this approach, whether or not it has a content
area associated to a particular SSL connection.
I've described both ideas in detail in two documents which I've uploaded
here:
http://kuix.de/mozilla/sslauth/
I'm aware that Aza Raskin published some related thoughts at
http://www.azarask.in/blog/post/identity-in-the-browser-firefox/ in
November 2009. I apologize that I've not been able to publish my
documents earlier.
I'm looking forward to your feedback.
Thanks and Regards,
Kai
Eddy Nigg
> I'd like to announce two design documents.
>
> The primary intention is to improve the functionality of SSL client
> authentication in Mozilla software.
> In short, we'd like to stop the current prompts and implement a better
> user interface.
>
Excellent effort! I hope I'll find the time to study your documents a
bit more, just browsed through them for now.
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Wan-Teh Chang
Is your proposal or Aza Raskin's proposal similar to the proposal that
Henry Story of the "foaf" project has been advocating?
Wan-Teh
Kai Engert
> Is your proposal or Aza Raskin's proposal similar to the proposal that
> Henry Story of the "foaf" project has been advocating?
>
No, under the assumption you're refering to http://esw.w3.org/Foaf%2Bssl
Contrary to "foaf+ssl" I'm not proposing any new protocols.
My proposal covers user interface enhancements and application behavior,
related to the existing SSL client auth and server auth protocols.
(Should "foaf+ssl" require that a user actively manages and selects
personal client auth certs when visiting sites, then "foaf+ssl" could
even benefit from my proposal, but they would complement one another.)
Kai
Gervase Markham
I've been looking at your documents, but I do think this is a case where
a picture is worth a thousand words. Do you have any plans to provide UI
mockups?
On 16/03/10 23:12, Kai Engert wrote:
> In short, we'd like to stop the current prompts and implement a better
> user interface.
I think that it would be extremely wise to include Mozilla's UI design
community as we look for a solution to these problems. Do you have any
plans to reach out to them? I notice your message was not cross-posted
to mozilla.dev.usability... You mentioned Aza's previous post. Has he
looked at your proposals?
> The basic idea is to show an indicator in chrome whenever a site asks
> for client authentication, and give the user full control over using a
> personal certificate for authentication (or not using one). The
> interface should also support persistent configuration, per site. It
> should be powerful enough to support complex sites and work with
> appearing/disappearing certs which are stored on smartcards.
From reading the documents, it's clear that we do have a difficult
simplicity/power tradeoff to make here. In order to help make it, do we
have any statistics or ideas how common it is to have scenarios like:
- A page whose components and subcomponents together require auth using
more than one client certificate
- A page where the top level does not require a client certificate but
sub-parts do
?
> Although we have a good solution in the browser (show an error page,
> allow override), the solution in non-browser applications (e.g.
> Thunderbird) is inferior.
Why do you say that?
Non-browser applications are very different to browsers. For mail, for
example, you do not add and remove dozens of mail servers on a daily
basis. As long as the software allows you to remember an override, I
don't think there's an issue in using a popup in this case.
> Instead, we should
> use an error status indicator in the chrome (for one or multiple
> failures),
I think the risk is that such an indicator would not be noticed, and the
user would be confused when their application didn't work.
Gerv
Kai Engert
>
> I've been looking at your documents, but I do think this is a case where
> a picture is worth a thousand words. Do you have any plans to provide UI
> mockups?
Hi Gerv,
thanks a lot for your feedback. I've created a graphical presentation
for the client authentication part:
http://kuix.de/mozilla/sslauth/cli-v1-pres/
Some more explanations:
There isn't a lot of UI involved, besides some icons and a configuration
dialog with dynamic content (see ASCII screenshot in the client
authentication document, pages 7 and 8).
(For each icon there'd be a related menu command for accessibility.)
When an icon is clicked, you'd get a popup menu with the list of related
sites (connection attempt or currently authenticated).
If there's just one related site, we could jump to the config dialog
directly.
I'd put the icons on the status bar, but I'm fine with any location in
primary chrome. If neither client auth nor bad certs are involved, all
icons are hidden.
> On 16/03/10 23:12, Kai Engert wrote:
>> In short, we'd like to stop the current prompts and implement a better
>> user interface.
>
> I think that it would be extremely wise to include Mozilla's UI design
> community as we look for a solution to these problems.
Sure!
> Do you have any plans to reach out to them?
> I notice your message was not cross-posted
> to mozilla.dev.usability... You mentioned Aza's previous post. Has he
> looked at your proposals?
I made Aza and Johnathan aware the day I posted the documents here, but
I'm still waiting for their feedback. I'm fine to cross-post.
I believe the concept related the "logged in = using authentication"
state is similar or identical to Aza's post.
The differences are:
- the location where the indicator is shown
(I don't mind where exactly it will be shown,
but would highly prefer the same location for both
"authenticated" and "not authenticated" icons.)
- the contents shown in the indicator
(I propose an icon,
while Aza used a "john @" prefix in the URL bar,
which may be difficult to do when using client certificates,
because of the difficulty to derive a short unique name from a cert
containing a potentially very long common name (CN).
(Although Axel Hecht had the inspiring idea to allow a user to assign
short nicknames to each personal cert.))
> From reading the documents, it's clear that we do have a difficult
> simplicity/power tradeoff to make here.
I hope we can find a solution that is acceptable to UI designers
for simple scenarios, but powerful enough to cover advanced scenarios,
(without requiring background configuration to enable advanced modes).
> In order to help make it, do we
> have any statistics or ideas how common it is to have scenarios like:
I don't have any statistics.
As of today there are probably not too many sites on the web using
client authentication, but that may also be related to the fact that
it's difficult to use with browsers. It may change once we make it
easier to work with.
> - A page whose components and subcomponents together require auth using
> more than one client certificate
>
> - A page where the top level does not require a client certificate but
> sub-parts do
Even if a single certificate is sufficient to access all components, the
components may be located on multiple hosts, like html.site.com and
images.site.com and private.site.com, and the user needs to control
where to present the site, and where not.
I agree it's an advanced scenario that sites should avoid, but some may
not. There may be existing complex sites where there's the desire to
start using client auth, and where it may be hard to consolidate to
single hosts.
Automatic sending of client authentication credentials is considered a
privacy issue, that's why Mozilla software currently doesn't send it by
default.
For the same reason I would not automatically send authentication data
for sub content on separate domains, even thought the user has agreed to
authenticate with the main page.
>> Although we have a good solution in the browser (show an error page,
>> allow override), the solution in non-browser applications (e.g.
>> Thunderbird) is inferior.
>
> Why do you say that?
Because click-through is being considered "bad".
> Non-browser applications are very different to browsers. For mail, for
> example, you do not add and remove dozens of mail servers on a daily
> basis. As long as the software allows you to remember an override, I
> don't think there's an issue in using a popup in this case.
Let's say you have your mail server configured.
Now you're in an Internet Cafe, someone MITMs you, and you get a cert
warning for your mail server cert.
As people tend to click-through warnings, so we should make it more
difficult for this attack scenario to work.
>> Instead, we should
>> use an error status indicator in the chrome (for one or multiple
>> failures),
>
> I think the risk is that such an indicator would not be noticed, and the
> user would be confused when their application didn't work.
In the "bad cert" scenario for non-browser applications, we'd show the
error message (without click-through), which ensures that the user will
notice, and can find the status bar indicator (maybe a
yellow-human-with-question-mark) to get to the "add override" dialog etc.
Although I've stated that we want to avoid prompts, for the client-auth
scenario, we could agree to still use prompts, if the user visits a site
for the first time, in other words, if the user has never accessed the
client-auth configuration dialog for a site.
Once the user has configured (using a cert, or not using a cert), we'll
remember, and can avoid the prompt in the future.
With this approach, the user will have the chance to notice when a new
sites requires authentication.
Hope this all makes sense and looking forward to additional feedback.
Regards,
Kai
Eddy Nigg
> On 26.03.2010 13:44, Gervase Markham wrote:
>>
>> I've been looking at your documents, but I do think this is a case where
>> a picture is worth a thousand words. Do you have any plans to provide UI
>> mockups?
>
> Hi Gerv,
>
> thanks a lot for your feedback. I've created a graphical presentation
> for the client authentication part:
>
> http://kuix.de/mozilla/sslauth/cli-v1-pres/
Very enlightening.
> The differences are:
> - the location where the indicator is shown
> (I don't mind where exactly it will be shown,
> but would highly prefer the same location for both
> "authenticated" and "not authenticated" icons.)
My first thought was that this should be really where Larry is.
Nelson B Bolyard
> On 26.03.2010 13:44, Gervase Markham wrote:
>> I've been looking at your documents, but I do think this is a case where
>> a picture is worth a thousand words. Do you have any plans to provide UI
>> mockups?
>
> Hi Gerv,
>
> thanks a lot for your feedback. I've created a graphical presentation
> for the client authentication part:
>
> http://kuix.de/mozilla/sslauth/cli-v1-pres/
>
> Some more explanations:
>
> There isn't a lot of UI involved, besides some icons and a configuration
> dialog with dynamic content (see ASCII screenshot in the client
> authentication document, pages 7 and 8).
>
> (For each icon there'd be a related menu command for accessibility.)
>
> When an icon is clicked, you'd get a popup menu with the list of related
> sites (connection attempt or currently authenticated).
>
> If there's just one related site, we could jump to the config dialog
> directly.
The sequence of events in the dialog is likely, IMO, to give the users the
impression that client authentication is a user-initiated act, rather than
a server initiated act. It seems to say to the user, "if you want to
authenticate to this server with your cert, you select your cert and click
here". I gather that the intent is that the browser will (re)initiate an
https request to the server(s) in response to that click. But there is no
assurance that the server will request client auth when the subsequent
requests are sent.
I think this is likely to lead to a lot of inquiries/complaints from users,
asking "why can't I authenticate to this site whenever I want to?".
Also, what are those icons supposed to represent? It looks to me like a
book and a light beam, where the book eventually interrupts the light beam,
much as objects on a conveyor belt at a supermarket checkout break the
light beam which stops the belt. Perhaps that's not what it's showing me,
but if it is, that doesn't suggest to me anything having to do with
authentication. But this is a minor point. I'm sure that suitable icons
can be found.
Kai Engert
> The sequence of events in the dialog is likely, IMO, to give the users the
> impression that client authentication is a user-initiated act, rather than
> a server initiated act. It seems to say to the user, "if you want to
> authenticate to this server with your cert, you select your cert and click
> here".
yes: ... you click here (the icon), you select your cert, then the
browser or the user will reload ...
> I gather that the intent is that the browser will (re)initiate an
> https request to the server(s) in response to that click.
yes, after the user selects a different authentication (use a cert, use
a different cert, don't use a cert) in the dialog.
> But there is no
> assurance that the server will request client auth when the subsequent
> requests are sent.
>
> I think this is likely to lead to a lot of inquiries/complaints from users,
> asking "why can't I authenticate to this site whenever I want to?".
Thanks for making us aware of this scenario (server requests auth on
first connect, but doesn't on subsequent connects).
I think we can address your scenario with the following application
behaviour:
If we're connecting to a site and the site requests client auth, we will
look up our stored configuration. If we can't find any stored
configuration for the site, then, do the same as we do today, and show a
prompt (the same prompt as used for the configuration, which is similar
to today's client auth prompt).
It will be a one-time automatic prompt (for this site).
The action chosen by the user (use or cert or do not use a cert)
can be remembered as the future default (for this site).
In the future, if the user connects to the site, we don't need to bother
the user with a prompt. We'll either use a cert or not use a cert, and
indicate it showing the respective icon (allowing the user to click and
change her mind).
Would this work?
In addition, a site that requests a client cert only once, and on
failure will never ask again, probably isn't very smart.
I'd expect any reasonable site must deal with the possibility that a
user doesn't send a cert on first attempt. A site must make it possible
to retry in some way.
If the user notes the request to authentication, then configures to use
a cert, then uses the site's mechanisms to retry, I think we have
achieved our goal.
Does this make sense?
> Also, what are those icons supposed to represent?
The first icon is supposed to show a closed barrier, like the ones used
at streets on border crossings, or at railway crossings. It means site
requested a cert, but we're not sending a cert to the site.
The second icon is supposed to show an open barrier combined with a
passport. It means a site requested a cert, and we're sending a cert.
> It looks to me like a
> book and a light beam, where the book eventually interrupts the light beam,
> much as objects on a conveyor belt at a supermarket checkout break the
> light beam which stops the belt. Perhaps that's not what it's showing me,
> but if it is, that doesn't suggest to me anything having to do with
> authentication. But this is a minor point. I'm sure that suitable icons
> can be found.
I'm not a graphics artist. I don't propose to use these icons as is. But
people asked for a mockup, and here you are. :-)
Kai
Anders Rundgren
http://tools.ietf.org/wg/pkix/draft-ietf-pkix-certimage/
will IMHO be difficult to roll out because it mixes local GUI
requirements with relying party ditto.
anders
Would this work?
Does this make sense?
Kai
--
dev-tech-crypto mailing list
dev-tec...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
Kai Engert
>
>> for client authentication, and give the user full control over using a
>> personal certificate for authentication (or not using one). The
>> interface should also support persistent configuration, per site. It
>> should be powerful enough to support complex sites and work with
>> appearing/disappearing certs which are stored on smartcards.
>
> From reading the documents, it's clear that we do have a difficult
> simplicity/power tradeoff to make here. In order to help make it, do we
> have any statistics or ideas how common it is to have scenarios like:
>
> - A page whose components and subcomponents together require auth using
> more than one client certificate
>
> - A page where the top level does not require a client certificate but
> sub-parts do
In the previous explanations I proposed to always have the user go
through two clicks:
- clicks the icon
- gets a menu popup with a list of sites
- clicks the site name the user want to control
While this is powerful enough to handle any sites, it may be
unnecessarily complicated when dealing with simple scenarios, e.g. if
all content originates from a single host.
Here's a modification of that idea, let's consider a site that uses
three different hosts, www.site.com, subcontent.site.com, images.site.com
User clicks icon and we show this menu:
www.site.com (disabled menu item)
x Logged out
Authenticate using my Certificate...
--------------------------------------
Settings for additional sites...
(Whenever there is only a single site using client auth, we could hide
the "Settings for additional sites" menu item.)
If cou click the "Authentication for additional sites..."
we can open a sub-menu that lists the above for each site involved.
www.site.com (disabled menu item)
x Logged out
Authenticate using my Certificate...
--------------------------------------
Settings for additional sites... subcontent.site.com
x Logged out
Authenticate using...
-----------------------
images.site.com
x Logged out
Authenticate using...
-----------------------
....
-----------------------
....
-----------------------
More sites...
If the user authenticates using a certificate, we could show the
following menu:
www.site.com (disabled menu item)
Log out
x Authenticated (Kai Engert, StartCom Free Certificate Member)
Authenticate using a different Certificate...
--------------------------------------
Settings for additional sites...
In my earlier proposal I said we should use two separate icons,
and group the lists of "logged out" and "logged in" sites separately.
The above proposal combines both lists into a single list, and may be
easier to work with.
However, I still believe that we sometimes need to show two icons in
parallel, to indicate the "some logged in, some logged out" scenario.
Kai
Gervase Markham
> thanks a lot for your feedback. I've created a graphical presentation
> for the client authentication part:
>
> http://kuix.de/mozilla/sslauth/cli-v1-pres/
I still haven't had a chance to look at this :-(( I'm very sorry.
(I do have a good excuse, though:
http://weblogs.mozillazine.org/gerv/archives/2010/04/a_speech_for_easter_sunday.html)
Gerv