OK, sounds like fun :)  Following are some MINOR comments
that hopefully would improve the proposal ... I'll post
my two MAJOR comments under separate cover.

iang




Frank Hecker wrote:
Prompted by some comments by Gerv Markham, the following is an strawman proposal for changing the Firefox UI relating to web pages retrieved via SSL/TLS. It was created upon waking in the middle of the night, so please feel free to treat it with extreme skepticism :-)

(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.


I'm not as yet sure what you mean by the "SSL/TLS UI" ...
hopefully that will become clear.

(padlock?  edit/prefs/privacy?)

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.

OK. (I've written on the goal of security elsewhere.) It would be desirable for Mozilla to adopt a goal of security. At the moment, it is written about but not adopted. If it were adopted, we could then identify anti-phishing as a "clear and present danger" to users and then pursue that as a danger to be addressed.

Having a goal of security forces you to meet the goal.  This
helps because it separates out the distractions from the
important tasks.  In the above, "promote wider use of SSL/TLS"
is a distraction.  Only if it helps security should it be used,
as a tool.  Wider use might actually make things more insecure,
if employed like a hammer on all nails in sight.

Also (annoyingly) we need to differentiate between SSL, TLS,
HTTPS, S/MIME, certs, PKI... in any proposal.  I generally
use SSL to refer to "the lot" and TLS to refer to the raw
protocol, sans certs.  HTTPS as TLS+certs+browsing.

But others do not do that...


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.

OK.


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.


Discourage typical users ... Um.  That I'm unsure of.  The
user is king, or queen in cryptoterms.  It may be that the
browser cannot distinguish between "user is told by boss"
and "user is told by phisher" but that isn't really enough
to go on in.


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


This I agree with.  I note there is some preference to display
a site domain name even without SSL, as being "this is where
you ended up".  If so, it should be a different colour or the
like.  But, I'd prefer it not to be there at all, for strategic
reasons.


* 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.)


OK.  Hopefully we also find out what "assurance" means :-)


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


OK, so if we accept the assumptions (!) then I think you have
this about correct.  The status bar is (for me) Mozilla's
security display, so it should show the domain that the cert
says you got to.  This is valid regardless of the assurance
level, which displays something else.  The yellow location
bar is just another padlock for me, one that is easier to see.


* 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


As the status bar is "what we are sure of" then it should
only show the domain name for a known good chained cert,
_or_ for a cert (self-signed or otherwise) that the user
has explicitly accepted as good.  In this case, the user
acts as her own CA.  As there is no mechanism for the latter,
there is no case for now for showing the cert's domain name.


* 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

This raises one issue - how good is our definition of "the domain name in the certificate" ? Reading some of Nelson's posts indicates that there is quite a bit of variance here.


  - 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.


For me it means the padlock, but in a place where I can
see it.  This needs to be tied down.  If we accept that
"yellow bar means padlock" then replacing the padlock
with a new symbol in some cases means we also need to
replace the yellow bar with a new colour.  So, we could
use pink for low assurance sites, purple for unknown
CAs, etc.


* 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.


OK.  Because I think users ignore the padlock, I'd ignore
that.  We will find out just how useful the padlock is
by the volume of complaints.  I'd expect a few noisy
fireworks going off, but on the whole, a storm in a teacup
would be about it.  (By which I mean, no real users noticing,
and no impact.)


* 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.


OK.  See my caveat above about users explicitly accepting
an unknown-CA/self-signed cert as good.


[more on that snipped...]


iang

--
News and views on what matters in finance+crypto:
        http://financialcryptography.com/
_______________________________________________
Mozilla-security mailing list
Mozilla-security@mozilla.org
http://mail.mozilla.org/listinfo/mozilla-security

Reply via email to