On 8-Jan-09, at 7:48 AM, Jean-Marc Desperrier wrote:
I wish I manage to find the time to make some constructive
suggestions about it. Meanwhile it would be great if you were more
active on the group here, because I think it's much adequate than
blog post (and more visible, so more open, that a bug entry) for
such discussion (as long as it doesn't turn into a flame war :-( ).
I agree, though I'll confess, it would help if I were able to be in a
lot more places at once. :) Nevertheless, I'll try to lurk a little
less and speak a little more.
The error is that you decided to hid from the user most of the
information about what kind of error was encountered.
This is really bad because the *major* problem with the SSL error
screen is that at least 90% of the time when the user encounters it,
it's a false positive. Nobody is
*really* actively trying to attack him.
I absolutely agree that most untrusted cert errors will not represent
MitM attacks. However, a couple points to keep in mind:
- By making the default exception permanent instead of temporary
(and bound to the host, port, cert tuple) we set up a situation where
most "normal" users, who are not using their friend's self-signed
webmail server or their company's web-staging site, are unlikely to
see more than a handful of these in their browsing lifetime.
Certainly, they may have some intranet site or favourite forum that
uses one, but once they add that exception, they aren't likely to see
many more. When they do, particularly on a site that didn't used to
have one - our hope is that they will stop and consider.
- All of this would be better with KCM, which is why I filed this
bug to discuss the possibility. https://bugzilla.mozilla.org/show_bug.cgi?id=kcm
I then ended up helping out our mobile team for several months,
which limited my ability to drive that kind of thing, but there are
also several concerns raised in that bug that would need to be
addressed before we could get the behaviour it describes (what does
the first-visit experience look like? do we KCM-ify certs for
subelements of a page, or only top level loads, &c.) One thing people
in this forum could be really helpful with is nailing down those
issues so that we have something concrete to implement.
There will be a problem with SSL error screen as long as 90% of
those screen are false positive, but displaying the info about the
nature of the problem at least helps the user to figure out why he
got the screen so why there was a false positive, so trust the
screen more, and not just ignore it the day where it's not a false
positive.
So, I will make the assertion that at least 80% of our users are not
going to benefit from the technical details we include in that error
message, and that while we could do another round of wording
improvements to try to finesse that, the issue goes deeper. 80% of
users don't want to know what a certificate is, or how it is used to
secure a TLS channel, and the wording in the rest of that error page
is already an attempt to make the issue more concrete, without delving
into the specifics.
There were calls in fact, in 3.0 and 3.1, to just remove the technical
details altogether, but people like Nelson persuaded me that this was
an essential debugging tool for support, even if end users couldn't
make heads or tails of it. In that vein, the 3.1 error pages have a
happy quirk where, even when the technical details are collapsed,
selecting the error page text and copying will include them, suitable
for pasting into tech support emails.
I know you likely already know this, but do keep in mind as well that
if you are someone who *does* understand this information, flipping
the browser.xul.error_pages.expert_bad_cert pref in about:config will
show the details sections by default.
Cheers,
Johnathan
---
Johnathan Nightingale
Human Shield
john...@mozilla.com
_______________________________________________
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto
