PSM:CertPrompt

Trying to handle automatic certificate selection is difficult. Currently both IE and PSM products have fairly noticeable corner cases. This page is meant to document how PSM currently and what kinds of problems it generates in deployments.

A revamp of the client authentication UI and behavior is tracked in bug 511384.

Current Interactions

When an SSL server requests that a client authenticate itself with a certificate, the server sends to the client a list of the names of issuers of client certificates that are acceptable to the server. The client is supposed to only respond with a certificate issued by one of the issuers named by the server. The list of acceptable issuer names is part of the server's configuration.

With some server products, when the server requests client authentication, it will require that the client successfully authenticate itself with an acceptable certificate, or else the SSL connection will be terminated. Some server products may alternatively be configured to request, but not require, a client certificate. Server thus configured will allow the SSL connection to continue, even if the client has no certificate or its certificate is not valid.

IE Current Usage

The first time that an SSL server requests client authentication from an IE client, IE will always prompt the user for a certificate, even if the user has no certificate issued by any of the named issuers. IE lists all the user certificates without regard to the server's list of issuer names. Once the user has select a certificate for the site (or the user has selected no certificate for the site), thereafter IE will use the user's chosen certificate (or chosen lack of certificate) for that site until IE is closed or until the user clears IE's SSL certificate cache.

PSM Current Usage

PSM has 2 modes in certificate selection:

1. ask every time.
2. select automatically.

If PSM is set to 'select automatically', it will find all the unexpired certificates for which the user has a valid private key, that chain up to one of the issuers named in the server's list of acceptable issuers. The first such certificate it finds is selected. The user may be prompted for his "Master Password", but otherwise, no user interaction occurs. If no certificates meet those criteria, no certificate is sent.

If PSM is set to 'ask every time', it will find all the certificates (expired or unexpired) for which the user has a valid private key, that chain up to one of the issuers named in the server's list of acceptable issuers. If no certs match those criteria, then no certificate is sent and the user is not prompted. If any certificates are match those criteria (even just one), the user is prompted to select a certificate from among those that matched the criteria. The user may be prompted for his "Master Password". The user has the option of selecting no certificate, in which case no certificate is sent.

Note that PSM goes through this every time a full SSL handshake is performed that requests client authentication with a certificate.

Server Action When the Client Sends No Certificate

If the client responds to the request with no certificate, a server that requires client authentication will cause the connection to fail. If the server was configured to request, but not require, a client certificate, the SSL handshake will complete as if the server had not requested client authentication.

Client Authentication Scenarios

Client Authentication with no Certificate: The client has no client auth certificates. This is the 'common' case of a user with not certificates trying to go to a site that uses client authentication.

Whether PSM is configured to 'select automatically' or 'Ask every time' it will send no certificate to the server, and no prompt will be displayed to the user. If the server required client authentication, a connection error will be occur. If the server only requested client auth, the SSL connection completes and the server can send either an appropriate error page, or request some sort of alternate authentication. This will happen each time the server requests client authentication. It does not occur when a server reuses a previous SSL session, and hence does not request client authentication.

The first time that the server requests client authentication from IE after IE has been started, IE will present an empty dialog. Once the user clicks 'cancel', IE will send no certificate to the server. IE will continue to respond to client authentication requests from the same server with the same response, until IE is closed or the user clears the SSL cache.

Basic Client Authentication: The client has exactly one certificate installed for which he has the private key, and the cert is issued by one of the issuers in the server's list of issuer names. This is the base scenario that all the software has been designed for initially.

If PSM is set to 'select automatically', it will send the one valid certificate to the server automatically. When set to 'Ask every time', PSM will present a dialog with the single certificate to the user. The user may refuse to use the cert (in which case no cert is sent). Each time that the server requests client authentication, rather than reusing a previously established SSL session, PSM will perform these steps again. These steps do not occur when a server reuses a previous SSL session, and hence does not request client authentication.

The first time that the server requests client authentication from IE after IE has been started, the user will be prompted to choose the single valid certificate. The user may refuse the cert, in which case no cert is sent. Any subsequent times that that same server requests client authentication, IE will again use that certificate to authenticate, until the user closes IE or hits the 'Clear SSL Cache' button.

Smart Card Client Authentication: The same as basic authentication except the one certificate lives in a smart card that can be removed.

For PSM, if the smart card is present, any initial connection will operate just like "Basic Client Authentication" above. If the smart card is removed, then PSM will clear the ssl session, so future SSL connections will operate as if the smart card is not present. In addition, PSM can send a smart card removal event to the browser, which can be handled in javascript to reload the page. This allows automatic logout semantics.

For PSM, if the smartCard is not present, the initial connection will operate just like "Client Authentication with no Certificate" above. If the smartCard is later inserted, PSM can send a smartCard insertion event to the browser. However, PSM does not yet terminate an SSL session for that event, so the server may not request client authentication again on the next visit. But the next time that the server requests client authentication, PSM will operate again like "Basic Client Authentication".

For IE, smart card removal will not trigger any clearing of SSL session id, or change IE's cached notion of what certificate to use. This has the effect of keeping the user logged in even if the card has been removed. Only clicking on the 'Clear SSL cache' button clear IE's session id and its idea of what cert to use to authenticate. If the server requests client authentication again, and the smart card has been removed, IE will prompt for the smart card to be reinserted.

In the IE case, a later smart card insertion will not trigger any new redraw, nor will IE re-prompt the user the next time that the server requests client authentication. The user will have to manually click the 'Clear SSL cache' button and manually reload the page.

More than one certificate, only one is acceptable to the server: The client has more than one certificate, but only one has an issuer name found in the server's list of acceptable issuer names.

PSM treats this exactly the same as one certificate. Only the certificate that meets the criteria is shown in any prompts, and is sent to the server.

In IE all certificates are placed in the initial prompt and the user has to figure out which certificate will be acceptable to the server.

Smart Card Authentication with multiple certs, only one valid: The client has more than one certificate. The one acceptable to the server lives on a smart card.

In PSM, this is exactly like the "Smart Card Client Authentication" case. (This needs to be verified. A code review of PSM seems to indicate this is the case, but there have been reports that very different things happen if 'ask every time' is set.)

In IE, if the smart card is not inserted, the user is presented with a list of certificates whether or not they are acceptable to the server. The user can select from the list, or select none of the certs. IE remembers this choice even after the smart card is inserted. The user will have to click the 'Clear SSL Cache' button to be able to authenticate with the smart card.

More than one certificate is valid: The client has multiple certificates that are acceptable to the server.

This can happen either because the user has overlapping valid certificates with the same subject name, from the same issuer, (the user has renewed a certificate before it has actually expired), or the user has multiple certificates with different subject names or issuer names, acceptable to the server.

In this case if PSM is set to 'Select automatically', it will select the 'most appropriate certificate'. In the case where different roles may be associated with the different certificates, PSM may or may not pick the correct certificate (as it has no information about what role the user wishes to use). If PSM is set to 'Ask Every Time', it will present a dialog with all the user's certs whose issuers are found in the server's list of acceptable issuers, including expired certs.

IE treats this case the same as "More than one certificate, only one is valid".

Client has expired certificate: The client has certificates which are expired, but were issued by CAs acceptable to the server. This scenario typically happens if either 1) the user lets his certificate lapse, or 2) in the renewal case.

In PSM only unexpired certificates from the server's list of acceptable issuers are used in the 'Select automatically' case. If there are no unexpired certificates, PSM sends no certificates. In the 'Ask every time' case, expired certificates are listed at the end and shown to be expired.

IE lists all certificates, expired or not.

Multiple certificates, none acceptable to the server: The client has multiple certificates, but none are issued by issuers acceptable to the server. This can be because 1) the client has never been registered with the server and cannot authenticate to it, or 2) the server does not include a complete list of CAs in its CA list, or its CA list is incorrectly configured. This case can happen in a bridged environment.

PSM treats this the same as "Client Authentication with no Certificates".

IE treats this case the same as "More than one certificate, only one is valid".

Additional complications

Generally, when an SSL connection is terminated due to failed client authentication, the interaction between clients and servers is poor in both IE and Firefox.

When the SSL connection fails, there is no communication channel between the client and the server. Sometimes clients will show an error page, or an error alert dialog, but commonly they just quit loading the page, giving the user no information about the failure. Because there is no connection, the normal server methods of redirecting the user to an error page do not work.

The SSL connection can fail in the client authentication case for the following reasons:

• The client sent no certificate, but the server required one.
• The client sent a certificate that the server thinks is expired (either because the certificate is expired, or a clock is set incorrectly).
• The client sent a certificate that was not issued by any of the CA's trusted by the server for client authentication (this is a client error).
• The client certificate can not be validated for other reasons (missing extensions, key usages, policy, signature is bad, etc).

Fortunately, if the server is talking to existing Firefox clients, and the server is configured correctly (with the correct time), and the server is configured to 'Request but not require' client authentication, then SSL connection failures are fairly rare, and only exist if 1) the client cert has been corrupted, or 2) the client cert is expired and the client's clock is set incorrectly. While these cases are rare, they should still fail in a graceful way that gives the user a hint at what the problem might be.

Apache (modSSL ?) has an option to override client certificate verification to help debug setting up client auth connections, but it does not have an option to validate the certificate and redirect if the certificate validation fails.

Issues with these scenarios

IE's client authentication has the advantage of being a simple programming model (Find all the certificates, present them to the user, remember the user's selection for the remainder of the process lifetime). This model, however breaks down in the following cases:

1. If there are no certificates available, users are confused by an empty dialog box asking them to select a certificate.
2. If multiple certificates are available on the system, IE does nothing to help the user understand which certificate should be used to authenticate.
3. Because of the current poor client/server interaction, the choice of the wrong certificate often gives the user no input as to why the connection failed.
4. The model does not work well when the certificate can appear or disappear from the system (such as the smart card case).

The model does work well in the following cases:

1. The user has a single, fixed certificate.
2. The user has multiple certificates which represent different roles, and the user is sophisticated enough to identify the proper certificate.
3. The case where the server does not send a list of CA Certificates, or the list of CA certificates is not complete, and the user is sophisticated enough to select the proper certificate.

PSM's 'always select' is targeted to the less sophisticated user. It breaks down in the following cases:

1. Switching from no certificate to having a certificate (smart card insertion) if the server does not invalidate the session id (server performance issue).
2. The user has multiple certificates which represent different roles.
3. The server does not send a list of CA Certificates, or the list of CA certificates is not complete.
4. The user needs to do online renewal of an expired certificate.
5. Sending a certificate with identity information to a random server without advice to the user is considered a privacy risk (see [1]).

It works extremely well when:

1. There is only one certificate.
2. Smart cards are used, particularly when card insertion and removal detection when no certificate is available.
3. There are lots of certificates to choose from, but no role differentiated certificates.

PSM's 'ask always' is targeted to the more sophisticated user. It breaks in the following cases:

1. The user has a valid certificate, but the server always does full hand shakes (always invalidates the session id).
2. Switching from no certificate to having a certificate (smart card insertion) if the server does not invalidate the session id (server performance issue).
3. The server does not send a list of CA Certificates, or the list of CA certificates is not complete.

PSM Recommendations:

1. Add a javascript function to clear the current ssl session id which can be called on smart card insertion. This will eliminate the need for servers to invalidate the session id for Firefox clients.
2. Include on all the user's certificates in the 'ask always' list, with those that match the CA list at the top and clearly marked as matching, and those that do not match at the bottom. (currently we already do this for expired versus unexpired).
3. Work on the server UI for fortitude to allow easy configuration of client authentication, so that client authentication errors are reported back to the client in a friendly manner.

TODO: still need to figure out how best to handle the 'select always' user who needs to do certificate renewal.

TODO: do we need to handle the 'select always' user in the case where the list of CA certificates do not match (this inherently requires a sophisticated user?).

Proposed design

Here is an attempt to formulate a design that meets all the requirements. Feel free to revise. Mattmccutchen 15:47, 26 August 2011 (PDT)

Configuration schema

A persistent map from host:port to entry as follows:

• Last decision made: "no cert", (cert nickname, token name)
• Lifetime: historical, bound to given SSL session ID, client session, or permanent
• If decision is to send a cert from a removable token and lifetime is at least the client session, a flag indicating whether to proceed automatically with no cert if the token is not present

The default for an absent entry is "no cert", historical.

The above does not provide for a per-site "select automatically" mode. Under what circumstances would such a mode be beneficial and acceptable privacy-wise?

During private browsing, a separate private browsing map is used in place of the main map; the structure is the same except that there is no "permanent" lifetime. The private browsing map is deleted when private browsing ends.

Have a tab in the cert manager to review and delete the entries in the active map, and (for the browser) maybe also a button in the URL bar to review or delete the entry for the current site.

Entry expiration:

• When the client exits, client-session entries become historical.
• When the client discards an SSL session (including on exit), any entries bound to it become historical.

SSL handling

When making a non-anonymous SSL connection to a given host:port, switch on the entry as follows:

For an anonymous connection (cross-site XMLHttpRequest without credentials, etc.), resume or negotiate an SSL session using no cert.

Connection reuse via mechanisms such as HTTP keep-alive is viewed as equivalent to resumption of the connection's SSL session and is allowed if and only if the resumption would be allowed (i.e., the cert must still be available and PSM prefs must still allow the SSL version and cipher suite).

CHOOSE represents the following procedure:

1. Begin negotiating a new SSL session, if not already done, to check for a CertificateRequest.
2. If the server did not send a CertificateRequest, resume or negotiate an SSL session using no cert.
3. If the server sent a CertificateRequest: Prompt the user to select:
   • an available cert (or no cert) from a suitably sorted list
   • a lifetime: bound to the SSL session being negotiated, client session, or (outside private browsing) permanent
   If the cert in the existing entry is available (or the entry has "no cert"), pre-select that choice (even if it is now a worse choice with respect to CertificateRequest matching or expiration? c.f. "U" and "T" server cert override types), otherwise indicate that the cert was previously used but is now unavailable. If the user presses OK, save the selections to the entry and continue the negotiation using the cert choice. If negotiation fails and the entry was to be SSL-session-bound, make it historical instead.

General notes:

• All prompts offer a Cancel button that cancels the connection without changing the entry.
• Error pages for SSL negotiation failures that might be related to client authentication offer a button to retry with CHOOSE regardless of any existing entry.
• If the server declines to resume an SSL session, the client drops the SSL session (and changes all entries bound to it to historical). But PSM only ever uses an SSL session for one host:port, right? Do we garbage-collect SSL sessions that are no longer referenced? If not, should CHOOSE try to resume them? In that case, we'd like to keep the new session in case the resumption fails, but that won't work on a server that only accepts one connection at a time. Alternatively, is it acceptable to use cached CertificateRequest data?
• Browser: If the current site has a non-historical entry for a cert in a removable token, when the token is inserted or removed, notify the user via a doorhanger but do not automatically reload the page. A manual reload will respond appropriately to the change.