(This is relevant to both n.p.m.security and n.p.m.crypto, so I'm cross-posting to both forums, but I'm setting followups to n.p.m.security to direct discussions to the wider audience associated with that forum.)
Briefly, the motivations behind this proposal are as follows:
1. Make the SSL/TLS UI as simple as possible, but not simpler.
2. Acknowledge the typical user's expectation that the display of a padlock is something associated primarily with e-commerce or financial sites, and basically means "it's safe for you to enter sensitive financial or other personal information on this page".
3. At the same time, allow for other legitimate uses of SSL/TLS beyond the traditional e-commerce/financial uses, and in particular promote wider use of SSL/TLS as a useful component of a comprehensive anti-phishing strategy.
4. Eliminate or at least minimize SSL/TLS-related error messages and warning dialogs, particularly in cases where they are arguably not warranted based on the security risk relative to not using SSL/TLS at all.
5. Discourage typical users from modifying the default list of "trusted" CAs and certificates, in particular by adding new site or CA certs as warning dialogs pop up.
Without further ado, here's the proposal:
* Retain the current Firefox UI when SSL/TLS is not used:
- no padlock or other SSL/TLS-related indicator in status bar - location bar background is white - site domain name is *not* displayed in the status bar
* Retain the current "normal case" SSL/TLS Firefox UI:
- display locked padlock in status bar - location bar background is yellow - site domain name from certificate is displayed in status bar
*but* reserve it for the cases where the site's certificate is a "high-assurance" certificate from a known CA. (Assume, at least for now, that we have a reasonable way to decide whether a given site certificate is "high-assurance" or "low-assurance"; see also below.)
We then add the following new SSL/TLS UI cases, for which we do *not* use the traditional "padlock" indicator in any form:
* SSL/TLS connection involving a "low-assurance" certificate from a known CA:
- display check mark in status bar (instead of padlock) - location bar background may or may not be yellow (this is debatable) - site domain name from cert is displayed in the status bar
* SSL/TLS connection involving a self-signed certificate or a certificate from an unknown CA:
option 1: - display question mark in status bar (instead of padlock) - location bar background is white - site domain name from cert is *not* displayed in the status bar
option 2:
- informational message of some sort (as for blocked popups), if it
can be written to convey useful information and not confuse the
typical user
- display exclamation point in status bar (as for blocked popups)
- location bar background is white
- site domain name from cert is *not* displayed in the status bar* SSL/TLS connection involving a certificate from a known CA where the domain name in the certificate does not match the domain name requested:
- display warning dialog describing the potential security risk,
and giving user the option of proceeding or cancelling
- if the user chooses to proceed, there are two options for the
subsequent UI (as there were for self-signed certs or unknown CA):option 1: - display "X" mark in status bar (instead of padlock) - location bar background is white - site domain name from cert is displayed in the status bar
option 2:
- informational message of some sort (as for blocked popups), if it
can be written to convey useful information and not confuse the
typical user
- display exclamation point in status bar (as for blocked popups)
- location bar background is white
- site domain name from cert is displayed in the status bar
Some follow-on comments:
* "Known CAs" are CAs for which we have a stored certificate with the SSL "trust bit" set on. Any other case (cert not stored or trust bit not set) is treated as an unknown CA. (I try to avoid the term "trusted CA" because of ambiguity over what "trust" actually means.)
* The UI for SSL/TLS with low-assurance certs should be similar but not identical to that for high-assurance certs. Whether or not to use the yellow background in the location bar for low-assurance certs is a judgement call. It may be that users have acquired the same expectations for the yellow background as they have for the padlock, in which case it may be desirable to use it only when the padlock is used.
* This proposal in a sense "breaks" existing sites using low-assurance certs, since users of those sites will no longer see the padlock. To ease in the transition, it may be appropriate to put up a warning dialog or informational message the very first time the browser encounters a low-assurance cert, so that the user will be informed about what is going on and will (we hope) be less confused when they see the checkmark instead of the padlock.
* The site domain name should be displayed in the status bar only when we have some reason to assume that it is valid. Hence it should *not* be displayed for self-signed certs and certs from unknown CAs, but *should* always be displayed for certs from known CAs.
* In the case of a self-signed cert or cert from an unknown CA, Firefox should *not* offer users the opportunity to accept the certificate or the certificate's issuing CA as "trusted", at least not from the immediately visible UI.
If an informational message is displayed in this case, then perhaps its dropdown menu could contain an option to not display the informational message in the future for self-signed certs or unknown CAs (similar to the option for blocked popups); in this case the UI indicators would remain the same, except possibly for a question mark replacing the "exclamation mark in circle" accompanying the original informational message.
(The other alternative would be to display no status indicator at all once the informational message had been dismissed; in effect this would treat sites with self-signed certs or certs from unknown CAs as similar to non-SSL sites.)
The informational message's dropdown menu could also contain a menu item "Edit Certificate Options..." or "Edit SSL Security Options..." (similar to the "Edit Popup Blocker Options..." item on the "blocked popup" informational message), and the resulting dialog box could contain options to accept the site's certificate or a new CA certificate. By default the cert would be added as a "low-assurance" cert, unless the user specifically indicated otherwise; future visits to the site would then display the check mark or pad lock as appropriate.
* In the case of a cert from a known CA but with an non-matching domain name, the warning dialog should be displayed at least once per browser session, without the possibility of turning it off permanently for that site. If an informational message is displayed in this case, then perhaps its dropdown menu can contain an option to not display the informational message in the future for not matching domain names (similar to the option for self-signed certs or unknown CAs); in this case the UI indicators would remain the same, except for an "X" mark replacing the "exclamation mark in circle" accompanying the original informational message.
(I don't think it makes sense to not display a status bar indicator at all after dismissing the information message, and to treat this case the same as a non-SSL site. There really is something wrong with the site -- it's either misconfigured or is using a stolen key and cert -- and the UI should reflect that.)
* The only way to add new CAs or server certs or to change the default "trust bits" should be through the Firefox preferences UI or (perhaps) through a detailed certificate dialog reached by selecting an item from the dropdown menu associated with an informational message (if used). (This latter option would be similar to the "Edit Popup Blocker Options" menu item displayed for the blocked popups informational message.)
* A "high assurance" certificate can be defined at a high level as "a certificate issued only after some level of human review of the cert subscriber", whereas a "low assurance" certificate might be issued through an automated process, e.g., one that simply verifies that the cert subscriber controls the domain listed in the certificate. With a low-assurance cert we can assume there is some basic protection against certain types of phishing attacks (e.g., attacks based on DNS spoofing), but we don't necessarily want to give the user the impression that the site is in the same category as traditional e-commerce/financial sites where they've been conditioned to look for the padlock.
The reason for making the "high/low" distinction depending on the presence or absence of human review is that this is directly related to the cost (in time and/or money) of doing phishing attacks that direct people to SSL-protected sites. Just as the low cost of domain registration allows phishers to register "throw-away" domains for their sites, evading anti-phishing defenses based on flagging URLs that contain IP addresses instead of domain names, under the current UI model the relative ease of getting low assurance certs means phishers would be willing and able to get "throw-away certs" for their throw-away domains so they could show the same padlock that users associate with e-commerce and financial sites. Reserving the full "SSL treatment" (i.e., with padlock and possibly yellow location bar background as well) for sites with "human reviewed" certs means that the incremental cost of setting up a complete "look-alike" site would be high enough to discourage doing this for throw-away domains.
* How would we decide in practice (i.e., at runtime) whether a given cert was "high-assurance" or not? Since this is not directly determinable from the information in the cert itself, we'd probably have to maintain a mapping from the stored CA certs to a "high/low" value. For certs in the default set the high/low value would be assigned at the time the cert were added to the default set, in the same way trust bits are assigned now, and our CA cert policy would have to have some criteria relating to high/low assurance. For certs added by the user the assurance level could be set by the user, with low assurance being the default. (Or if we want to be draconian we could arbitrarily decide to mark user-added certs as low-assurance only.)
An additional complication is that some CAs have a single root CA under which there are intermediate CAs issuing different classes of certs, e.g., one intermediate CA for low-assurance certs and another for high-assurance certs. Handling this case properly would likely require storing intermediate CA certs in the default set; otherwise we'd probably have to penalize the CA by marking the root CA (and hence any CAs under it) as low-assurance.
That pretty much completes my night-time excursion into the wonderful world of Firefox security UI discussions. Feel free to flame away.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ Mozilla-security mailing list Mozilla-security@mozilla.org http://mail.mozilla.org/listinfo/mozilla-security
