Ka-Ping Yee wrote:
It's an assumption of Gervase's current anti-phishing proposal that
everything starts with SSL. Indeed, sites really should have no
business slinging around passwords and credit card numbers in
cleartext -- it's pretty irresponsible. Here are a few thoughts
on how we might encourage the use of SSL and move towards a world
in which users come to expect it.
1. As mentioned in my last message, a transient warning could
appear when the user is typing text into a form on an unencrypted
site. The warning would appear below the text field while the
focus is in the field, and disappear automatically (no extra user
effort needed) when the focus moves elsewhere. The warning could
say something like "The text you enter here will be visible to the
public" if the connection is unencrypted.
Good one.
2. Currently, typing in password fields shows a bunch of stars to
give the impression that what you type is secret. Well, if we
are really serious about the necessity of SSL for keeping passwords
secret, then why should we give that impression when there's no
encryption? Suppose that, if there's no SSL, password fields
*don't* blank out the text with stars -- they just behave like
normal visible text fields. That would be instant, unmistakable
feedback, and i think it would be a pretty intuitive way to show
that the password isn't being kept secret.
The reason for the stars is based on the old Unix
security threat of students reading over shoulders
in terminal labs. 20 years ago this was a reality,
something that was done every day in the labs...
But, in practice, it would be more secure these days
to show the password in the clear all the time, as
there is nobody peeking over the shoulder most of
the time in today's computing, and the ability to
remember the password is far more important than
any such.
But, turning off the stars is a non-starter, one would
have to convince all the people who code and use
these things of where they came from, and who's
got the time to do that?
OTOH, your suggestion has some merit ... it
certainly isn't going to reduce security markedly,
and may result in a big hint. Worth experimenting
with.
3. Consider these three cases:
(a) Unencrypted connection.
(b) SSL connection with a self-signed certificate.
(c) SSL connection with a certificate signed by a known CA.
Of these three options, (a) is the riskiest context in which
to submit an HTML form; (b) and (c) are safer. (If you trust
centralized CAs, then you might also believe that (c) is safer
than (b). I *don't* trust the CAs, but that is an issue for
a separate thread. In any case, i hope we can agree that (b)
is still safer than (a).)
Compare this ranking of risk to the user experience. (b) is
heavily penalized by a pop-up warning, but (a) and (c) are
not penalized at all. It may be worth thinking about how to
bring these user-experience costs more in line with the actual
risks, so that sites are encouraged to use encryption without
being required to pay the extortion^H^H^H^H^H^H^H^H^Hfees
demanded by centralized CAs.
4. What if the browser chose SSL by default first? As in, when
you type "paypal.com" in the location bar, the browser *first*
tries https://paypal.com/. If that fails, then it falls back
to http://paypal.com/. In a world where self-signed certificates
aren't penalized with a big scary warning, this might go a long
way toward encouraging more widespread use of SSL.
Perhaps. I think an alternate is to perhaps probe
the SSL port and perhaps pop up a little upgrade
logo if a connection can be established ...
If the SSL connection were tried first, it would
slow most browsing down a lot. SSL takes order
of many seconds to connect and start up in the
first instance. Putting this in front of every browsing
attempt isn't going to make for happy campers.
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
