Improved SSL Client Authentication for Mozilla applications
(includes a generic design of reporting and controlling properties of an SSL connection) Author:
Kai Engert [email protected] August 2009
The SSL client authentication mechanisms in Mozilla are insufficient.
The motivation of this document is to design a solution that works with SSL connections in any Mozilla application, including (but not limited to) Firefox.
Improved SSL Client Authentication Introduction
For background information and why there is a need for improvement, see https://wiki.mozilla.org/PSM:CertPrompt
As an addendum to that page:
Because „select automatically“ has become a privacy issue in some scenarios (where a user unknowingly posseses a client cert and gives it out to sites automatically, „super cookie“), recent versions of Mozilla software have started to use „always ask“ by default. In order to relax the pain of continuous prompts, a bandaid has been approved which allows to remember a cert selection for the remainder of the session, similar to the described behavior of IE. (Which is not user friendly for smartcard environments.)
Proposal
Introduce a new user interface element (in the „chrome“) to give feedback about „current ssl authentication state“, which is also a control element to change the SSL authentication credentials as needed. Let's call it „CliAC“ (CLIent Auth Control).
A recent trend in Firefox is to avoid prompts, to no longer use the traditional approach to pause loading and prompt the user. Instead, use a good automatic decision for the client authentication and proceed. Give the user a chance to notice what happend and a chance (using CliAC) to change the authentication details, the credentials used by the application.
The CliAC may be shown in the application status bar, next to (or grouped with) the existing „status bar padlock“. CliAC may be invisible whenever the visited site did not ask for SSL client
authentication.
In a simple scenario, using CliAC in Firefox, the following states (icons) may be used: • invisible (not using SSL, or site not asking for client auth)
• not currently using client auth (if a site asked for it, but no user selection yet) (this may also be shown on SSL error pages when a site requires client auth) • currently authenticating using client cert.
A click on CliAC opens a menu that allows to start or stop using a client cert, or to use a different client cert.
Scope of CliAC
Let's assume a simple status bar indicator located in a browser's chrome. It will be obvious this is tied to the currently shown toplevel document, to the address shown in the URL bar. This is the same scope as used for the padlock icon (showing SSL server auth status on the statusbar) and the identity indicator used to the left of the URL bar („Larry the passport agent“).
Using a simple SSL client auth status would be based on the assumption that a single SSL client auth status and selection is sufficient for web documents.
lower content level? (e.g. inside a frame, or for scripts/pictures loaded from a different site than the toplevel page). What if the toplevel document does not require SSL client auth, but some sub-element asks for client auth?
Loading a complete document from a complex site may involve multiple source hosts, multiple client certificate issueing CAs. In order to view all content it may (in theory) even require the user to choose more than one client certificate.
Using today's mechanisms, users may get an SSL authentication prompt for content used anywhere as part of loaded documents. The proposed new mechanism must not be a functional regression. It must continue to support independent authentication for both the toplevel document and sub-elements.
A complete solution for CliAC would list each site requiring client auth and allow for an
independent client cert selection for each site. This would require to display multiple states at the same time.
In other words, on a simple site, where only the toplevel document asks for client auth, the state will be one of the simple states {invisible, not using client auth, using client auth}.
However, on a complex site, where a document (loadgroup) involves more than one site asking for client auth, it will be necessary to show both states „not using client auth“ and „using client auth“ at the same time.
The icon for each those states shall open a menu that shows pairs of {hostname, authentication state and client cert}.
Simplified CliAC
This paragraph shortly describes the possibility of a simpler implementation and the consequences. In order to reduce the workload to implement this proposal, someone may decide that client auth support in Firefox shall be limited to one client cert per document. In other words, no independent client cert selection for sub-elements.
This would mean, on sites where a sub-element requires a different client cert, that sub content will never be shown, and the user has no opportunity to know what's wrong, and has no way to fix it. This will reduce the CliAC implementation to care for the simple scenario, only. It would require that web site authors ensure a homogeneous authentication environment for their content.
This implementation strategy may break some existing sites that work with the prompts used by today's SSL client auth mechanism.
The advantage is, CliAC for web sites would never show multiple states at the same time, and would not need to list multiple hostnames, each with their own client auth selection mechanism. However, the remainder of the document will explain how CliAC shall be used for any connections, even SSL connections not tied to a browser window. It seems necessary to implement this complex user interface, anyway, involving multiple hostname-to-client-cert feedback and selection.
Therefore hoping for this simplification may be futile. CliAC and browser navigation
The client auth choices made by users („use this client cert for this site“) shall be remembered at least for the remainder of the session. Feedback shall be given (using CliAC) whenever such an authentication is effective.
When a user navigates to a different page, CliAC shall be re-populated. CliAC shall stop to show authentication information for web pages (or sub-elements) that are no longer displayed in the web page associated to the browser window (or tab).
CliAC and smartcards
When a smartcard gets removed and the currently used cert is no longer available, CliAC will change state appropriately. It's a web site's reponsibility to listen to smartcard removal events and potentially change the shown contents.
A smartcard removal or insertion event shall cause a logout event for all active SSL sessions. On next SSL handshake the application will attempt to use the remembered SSL client cert
configuration. If a cert is configured but no longer available, CliAC will show the „not using client auth“ state. If a configured now became available, CliAC will show the „using client auth“ state, and the popup will indicate which cert is being used.
However, in order to trigger that shown content (on a web page) matches the information accessible using the currently available certs, a user may need to reload the page (in the case where a web site does not listen for smartcard status events). However, no new manual cert selection shall be
necessary when having a previously remembered selection and under the assumption the user has not changed the client auth settings for this site while a smartcard was absent.
Remember selections permanently
In a first implementation step the lifetime of the list of remembered client cert per site may be lost when the user exits the application. But the goal is to have this list remembered permanently. Default behavior for client auth
By default (in a fresh profile, or when starting to use software with this new feature) there will be no remembered certs per site. Therefore, when loading a site for the first time, no client certificate will be used for authentication. There will be no prompt asking for a client cert. In the case where client authentication is not optional, but required, there will be the usual SSL error message (or error page) that informs about a terminated connection.
In order to proceed with client auth, the user needs to notice the CliAC status display and must explicitly access CliAC and pick a certificate.
Connections outside the browser
opened by an application, the owning window shall be specified by the initiating code. This way the CliAC located in the associated window can display the information related to the connection. (Besides the browser, another example is the Chatzilla extension that opens a separate window and uses connections to an IRC server.)
There may be application windows that are responsible for multiple separate connections. A good example is Thunderbird's main window, which may manage connections to multiple mail servers. For server A the user may already have chosen a client cert, while server B also asked for client authentication, but the user has not yet chosen a client cert for server B. Therefore CliAC must be able to list the state for multiple servers in parallel. (Another example is Chatzilla using multiple connections to multiple IRC servers.)
In addition there are background connections used in Mozilla applications, not associated to a specific window. One example is the connection that Mozilla uses to ask for software updates. Another example may be an extension that synchronizes user bookmarks to a server, uses some configuration dialog, only, but never displays its own window.
CliAC shall support such background connections, too. When an application uses them, but can not specify a specific window to display related SSL status, then the CliAC controls in all windows will include information about those background connections in addition to the connections specific to the window.
(Here may be need for discussion. Maybe it's confusing to see a status bar control that indicates „using client authentication“ when the shown web page does not use that, but a background
connection is the single reason to display CliAC. The solution may be to use a separate, differently looking status icon to inform the user about SSL status for background connections. Another possible solution may be to not inform the user about problems with background connections at all, but require the user to explicitly go to a menu item like „SSL status of background connections“. I'd personally prefer some notice in the status bar, though.)
Optionally, at socket creation time, the application may explicitly request that a SSL connection shall be silent (and potential SSL client auth requests by the server shall not be shown anywhere in UI).
Another challenge is the SMTP protocol used by Thunderbird. SMTP connections are short lived. They are usually associated to a message compose window. The connection isn't started prior to sending the first message. And during the sending attempt there is even a progress indicator dialog on top of the window.
Today, if the SMTP connection requires SSL client auth, a prompt will show up dynamically. With the CliAC approach, the connection would have to fail and Thunderbird would have to show an error message. The SMTP window could change to include the CliAC status bar area, indicating that client auth has been requested by the server. The user can use CliAC to configure the desired client cert and re-attempt to send the message.
After the message has been sent, CliAC can continue to show configuration information for SMTP connections while the user composes a message. This can either happen in message compose windows, only, or it could be permanently shown in Thunderbird's main window.
This SMTP scenario demonstrates one more feature needed for CliAC. An application may request that some hostname-to-client-cert association shall be permanently visible in CliAC, even while there is no such connection currently in progress.
Also, problematic connections will usually close right away. Some logic needs to determine the duration that SSL connection status shall be visible in CliAC. A time limit shall be used, because after a longer application session, the CliAC shouldn't show the full list of e.g. 50 problematic sites encountered during the day. Therefore, at socket creation time, the application may specify a „keep error visble“ timeout. That may be „forever“ or a time value like „keep error available for 5
minutes“.
Proposed Icons shown in CliAC
When a site asks for a client cert, use an icon like „key with question mark“. The menu accessible should list the hostname that asked for a key. This may be a single hostname or a list of multiple hostnames. (Selecting a hostname should open a dialog that will be used to perform the client cert selection.)
CliAC may also show this icon while the browser displays an SSL error page, when a site requires a client cert in order to allow a connection.
When a connection is already configured to use a client cert, CliAC uses an icon like a solid lock with an inserted key. A click on the icon will show a list of pairs {hostname, name of client cert}. A click on any such entry will open a dialog where the user can switch to a different client cert or to stop using a client cert.
Client cert selection dialog
This dialog appears when a user accesses CliAC to change a client authentication setting, either to specify a new authentication, or to terminate such an authentication.
The dialog will be similar to the classic prompt. It shall look like this:
Site www.host.com[:nnn] *7 asks that you authenticate using your SSL client certificate. It accepts certificates from the following CAs: (show a list of names sent by the server) *1 How would you like to authenticate yourself? *2
• Do not authenticatiate, do not show any of my certificates. *2a • Authenticate using one of my personal certificates *2b
[dropdown with names of certificates]
| Text area that shows detailed information about the certificate | currently selected in the dropdown.
| It shall include issuer CA and subject name and certified use.
| It shall include the name of the cert storage device if it's stored on a smartcard.
You do not own an appropriate personal certificate. Please contact a system administrator in order to learn how to obtain an appropriate SSL client certificate. *3
The certificate you had selected previously is not available. Either you deleted the cert or you may need to insert your smartcard. *6
[x] allow me to select certificates that are no longer valid because they have expired *4 [x] allow me to select certificates that were issued by other CAs *5
Comments:
The destination port number *7 will be shown in brackets after the hostname, to allow a user to distinguish cert selection by application protocol. In order to simplify the user interface for the web browser, the port will be hidden if it's the standard SSL port 443.
Section *1 may not be shown while this information is unknown, for example, for SMTP like connections, where the association from site to client cert has been permanently remembered, where the application asks to always show this association in CliAC, but where no connection has yet occurred during this application session.
An appropriate client cert is one that was issued by one of the accepted CAs and has not yet expired. If the dialog is started at a time when the information *1 is not available, then the test for matching CA will be skipped.
If there is no appropriate client cert available, then text *3 will be shown. Text *3 will be shown even when checkboxes *4 or *5 are checked.
The list shown in *2b will list personal certificates. The list contents are influenced by checkboxes *4 and *5.
The text entries listed in *2b shall contain the (personal) subject name and the serial number. They shall include a test suffix in [brackets] that indicates their relationship to *4 and/or *5.
If, after consideration of *1, *4 and *5 there are still no personal certs for selection, then section *2b shall be disabled (grayed out) and radio button *2a shall be automatically selected.
When opening this dialog while a previous selection has been remembered, the dialog should be prefilled with the remembered information. If the currently selected certificate has expired, *4 will be checked. If the currently selected certificate has not been issued by one of the accepted CAs, then *5 will be checked.
Only when opening this dialog while a previous selection has been remembered, but the cert can not be found, then text *6 will be shown and *2a will be selected. The cert will not be listed in the dropdown. However, this dialog will be updated on smartcard events. If a smartcard containing this missing cert gets inserted while the dialog is open, then *6 will disappear, the radio selection will switch automatically to *2b, the list in *2b will be updated. If the user has not yet made an attempt to select a different cert in the dialog, then the remembered cert will automatically get selected in list*2b, too.
In general, if a smartcard gets inserted while this dialog is shown, the contents of list *2b will be populated with the additional certs, and potentially *3 will be hidden.
Behaviour after client cert selection dialog
Once a user closes the cert selection dialog with [OK] the configuration will be remembered by the application and used for future connections.
An application may specify a „client auth configuration change“ callback function. This callback will be called by CliAC after a configuration change was made by the user. The information provided will include {hostname, port number} that received the new configuration.
The application may decide to re-attempt the related connections after having received such a callback notice.
When an SSL connection was associated to a specific window and has been remembered by CliAC as such, then CliAC may send a similar notice to a specific window callback. The window could then decide to reload its contents.
Applications that don't include a CliAC in their chrome
Such applications will not be able to use SSL client authentication, unless they implement their own mechanisms.
Implementation thoughts
PSM (mozilla/security/manager) shall provide the full implementation of this mechanism. It shall use IDL files to design the interface between the backend implementation and the user interface. It shall provide a XUL based default implementation. This may allow embedding applications to specify their own UI.
Applications that desire to use CliAC shall include the control in the user interface of their XUL windows and register it with PSM at application start.
