Closed Bug 431826 Opened 16 years ago Closed 16 years ago

Handling of invalid SSL certificates lacks in usability

Categories

(Core Graveyard :: Security: UI, defect)

Product:
Core Graveyard
Component:
Security: UI
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.1b2

People

(Reporter: ivanr, Assigned: johnath)

References

Details

(Keywords: user-doc-complete)

Attachments

(2 files, 6 obsolete files)

Screenshot w/ latest patch, all sections expanded
133.64 KB, image/png
Details
with nits
57.31 KB, patch
johnath
: review+
johnath
: ui-review+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9b5) Gecko/2008032620 Firefox/3.0b5

The error page displayed when Firefox encounters an invalid certificate is too technical. One needs to know a lot about SSL in order to understand what the error is about. The low-level details should be hidden, but click away from those that do understand them. For example, there could be a "Details" link, which expands the error message to show the technical details.

Furthermore, the users need to be told what to do in clear terms. I would add a sentence that states the user should not proceed to the site, but attempt to contact the site operators in some other way to try to resolve the problem.

Reproducible: Always
I disagree that it's "too technical" since the only technical thing there is the error code (useful for admins trying to fix their site). Burying it under a click makes tech support harder, but if possible putting it after the bullet list would be better, or at least make the font smaller to deemphasize it.

I'm going to confirm this bug, though, to see if we can come up with better text in a future version. It could be much clearer about helping the user answer the question "What do I do now?".

The second bullet point is good ("try again later"), but what if I've never been here? The first bullet point really needs to convey "don't go there until you've talked to the site's operators and are sure it's the first possibility, not MITM". Somehow.

The warning text around the exception buttons could be expanded, it doesn't explain why. Old hands will ignore any additional text anyway but it would help first timers. 

   If you add an exception &brandShortName; cannot ensure that your
   network connection has not been hijacked [or: ensure that you are
   connected to the intended site]. You should not add an exception
   if you are using [etc.]
Assignee: nobody → kengert
Status: UNCONFIRMED → NEW
Component: Security → Security: UI
Ever confirmed: true
Product: Firefox → Core
QA Contact: firefox → ui
Version: unspecified → Trunk
I know I've been very quiet since reporting the problem but, for what it's worth, I will try to find some time in the following months to perform a small usability study (with my mom, and other relatives) on this topic.
(In reply to comment #2)
> I know I've been very quiet since reporting the problem but, for what it's
> worth, I will try to find some time in the following months to perform a small
> usability study (with my mom, and other relatives) on this topic.
> 

Maybe it's a case of explaining in layman's terms what an invalid security certificate means? For instance, saying something along the line of: "A certificate is like an identity card for a secure web site. As the certificate for this site is invalid, Firefox cannot confirm its identity and therefore cannot ensure that you are connected to the intended site. The web site itself or your connection may have been hijacked. It is therefore recommended that you do not proceed further."

But I think you're right: a usability study with non-technical friends and relatives is the way forward.
Attached image WIP (obsolete) — 
No patch yet, but this is the kind of language I'd like to see us explore.

 - More human descriptions
 - Clear preferred choice
 - More clear that this is a trust issue, not a network error
 - retains technical information, error message, for troubleshooting
 - retains override option (and honours browser.xul.error_pages.expert_bad_cert to auto-show) - in fact I think this makes the decision a lot clearer than either the current error page or the text in the exception dialog.

This can't be done with netError.xhtml without an absurd amount of hackery, so I think this would make sense as a new about:certerror page.  I think that change is overdue anyhow though, since the current approach (netError pulling UI in via dtds that are overridden by various consumers) is really sub-optimal.
Assignee: kaie → johnath
Copying a couple of folks who are generally helpful with wordsmithery, or have expressed an interest in this page previously.
Terrific! So I'm not sure about the "trusted" word, it might also give the wrong impression. Actually it's not a trust issue either, it's a "missing verification/validation" issue. Or a "certification" issue...sites aren't trustworthy per se even when secured by SSL...errr...even EV.
Sorry for the delay...

Overall, I like the more human descriptions. Some of the nits I dislike are:

  * The use of "we" in place of "Firefox" or "it" or (sometimes) simply 
    nothing.
  * The definition of what "trusted" is isn't very clear. Specifically, "...
    this site's identification isn't trusted." seems confusing since it's
    not clear who doesn't trust it. I'm aware this information is mostly in the
    Technical Details section, but it feels like we need a watered down version
    of it (or some link to a help doc?).
  * I'm not a fan, overall, of using "site's" as a word. I think the answer is
    yes, but, are you purposely avoiding using "domain"?

Beyond that, I like it. I'm not sure what negative affects there are for other consumers if we change the way this page is created. I'd ask a few of them if they care.
I think the new language is great. Just one thing: would it be better to say "[...] but this site's identity cannot be verified." (instead of "but this site's identification isn't trusted")?
(In reply to comment #9)
> I think the new language is great. Just one thing: would it be better to say
> "[...] but this site's identity cannot be verified." (instead of "but this
> site's identification isn't trusted")?

+1
(In reply to comment #9)
> I think the new language is great. Just one thing: would it be better to say
> "[...] but this site's identity cannot be verified." (instead of "but this
> site's identification isn't trusted")?

+1
Attached patch Patch v1 (obsolete) — — Splinter Review 
- Creates the page as a new "certerror" component in browser/components.
- Adds a dtd (no properties file needed since unprivileged code can't make helpful use of stringbundles anyhow.)
- Adds the hook into docshell to use the page for certerrors, if it's available
- Auto-shows the technical information section only in cases where we have hyperlinked for you
- Basically works.

No tests yet.  Haven't integrated string feedback from Sam yet, though I did change the line people are +1'ng.  :)
Status: NEW → ASSIGNED
Any screenshots?
Comment on attachment 343646 [details] [diff] [review]
Patch v1

I had a really long and detailed comment ready to submit, but Minefield crashed, so please excuse the terseness of this comment as I try to remember what all I had mentioned.

Why are you doing about:certerror as a separate component? That seems to be excessive. Can't you do what about:robots (bug 417302) and about:rights (bug 456439) do instead? That seems like it would make more sense.

>+# The Original Code is mozilla.org code.
>+#
>+# The Initial Developer of the Original Code is
>+# Netscape Communications Corporation.
>+# Portions created by the Initial Developer are Copyright (C) 1998
>+# the Initial Developer. All Rights Reserved.

I doubt it.

>+ifneq (,$(BUILD_OFFICIAL)$(MOZILLA_OFFICIAL))
>+DEFINES += -DOFFICIAL_BUILD=1
>+endif

Do you need this code? I don't see you using it.

>+  background : url("chrome://browser/content/certerror/section_expanded.png") left 0 no-repeat;
>+  background-image: url("chrome://browser/content/certerror/section_collapsed.png");

Why are these images in certerror's content folder rather than under browser/themes/ where they should be? Having them outside of the themes folder really makes themers unhappy.

>+   - The Original Code is Firefox certificate error page.

Please don't use "Firefox" if you can help it.

>+    <!-- If the location of the favicon is changed here, the FAVICON_ERRORPAGE_URL symbol in
>+         toolkit/components/places/src/nsFaviconService.h should be updated. -->
>+    <link rel="icon" type="image/png" id="favicon" href="chrome://global/skin/icons/warning-16.png"/>

This isn't right on gnomestripe. See bug 432938 for more information and how to fix this.

>+# The Original Code is mozilla.org code.
>+#
>+# The Initial Developer of the Original Code is Google Inc.
>+# Portions created by the Initial Developer are Copyright (C) 2006
>+# the Initial Developer. All Rights Reserved.

I doubt it.

>+ * The Original Code is about:robots
>+ *
>+ * The Initial Developer of the Original Code is Mozilla Foundation.
>+ * Portions created by the Initial Developer are Copyright (C) 2008
>+ * the Initial Developer. All Rights Reserved.

Should that be Mozilla Corporation or Mozilla Foundation for MoCo employees? I've never been 100% sure on that.

>+<!-- These strings are used by Firefox's custom about:certerror page,
>+a replacement for the standard security certificate errors produced
>+by NSS/PSM via netError.xhtml. -->

Please don't use "Firefox" here.

>+<!ENTITY certerror.introPara1 "You have asked Firefox to connect securely to <b>#1</b> but we can't confirm that you are going to the right place.">

Use brandShortName instead of "Firefox" here. Add a comma after "</b>".

>+<!ENTITY certerror.introPara2 "Normally when you try to connect to a secure site, it will present trusted identification, so that you know you're going to the right place, but this site's identity can't be verified.">

Add a comma after "Normally". Remove the comma after "identification". This sentence runs a tad long. How about breaking off the last part into a new sentence ("However, this site's identity can't be verified.").

>+<!ENTITY certerror.whatShouldIDo.heading "What Should I Do?">
>+<!ENTITY certerror.expert.heading "I Know What I'm Doing">

Title Case Really Annoys Me At Times. I note that you didn't use title case in the actual <title>. ;)

>+<!ENTITY certerror.expert.content "If you understand what's going on and want to tell Firefox to start trusting this site's
>+identification, you can add a security exception.  <b>Even if you trust the operators of the 
>+site, this error could mean that someone is impersonating them.</b>  Don't add an exception
>+unless you know there's a good reason why this site doesn't use trusted identification.">

Use brandShortName instead of "Firefox" here. Double spaces are a bit oldschool and outdated, as per current grammar rules. If you're not using them to keep the bolded part more set apart, then please remove them.

Hope this helps!
All participants in this discussion should read bug 460374.
Any new bad-cert UI should protect victims like that AT LEAST as well
as the present stuff, and hopefully better.  

Please continue this discussion in this bug, not in that one.
I really would like to see browser.identity.ssl_domain_display set to 1. People get used to *prominent indicators* and once they are missing, it raises awareness and suspicions. It wouldn't have helped much for bug 460374, but it might help others to distinguish. It also would help prevent cases of obscure domains like www.paypal.com.session.object.phisher.com/login/payaplobject/
I think we should keep some text along the lines of "You should not add an exception if you are using an internet connection that you do not trust completely."  When users hop onto a wireless network that turns out to be hostile, we want to nudge them toward realizing that their choice of network is the cause of the problem.  Otherwise, they're likely to continue browsing http sites and may override https errors under the mistaken belief that Firefox is not working properly.
> "You should not add an exception if you are using an internet connection 
> that you do not trust completely."  

Users trust all their internet connections completely.  Witness bug 460374.

The sentence should specifically call out wireless connections and 
connections in hotels and public places as not to be trusted completely.
We also should disable adding of exceptions at all and only allow it after editing a setting of about:config! It can't be that in order to facilitate the convenience of 0.1% of the user base, the other 99.9% are put on unneeded risks! No matter, how many clicks are put in the way of the user, he will click all the way through. 

Also the current trends confirm, that more and more sites are secured adequately since the introduction of FF3. One more step to go...
(In reply to comment #14)
> Why are you doing about:certerror as a separate component? That seems to be
> excessive. Can't you do what about:robots (bug 417302) and about:rights (bug
> 456439) do instead? That seems like it would make more sense.

Johnathan and I discussed this and agreed on this location for the code, the reasoning being that there were several files related to this single page and that scattering them around the source tree (as with about:robots) didn't make sense. You're probably right that the images and CSS should be under browser/themes, though, which somewhat nullifies that argument.

> >+   - The Original Code is Firefox certificate error page.
> 
> Please don't use "Firefox" if you can help it.

This is silly. Whether or not Firefox continues to exist doesn't change the fact that this code was added for its error page.

> This isn't right on gnomestripe. See bug 432938 for more information and how
> to fix this.

That bug isn't fixed yet, and the changes needed to fix it area also also needed for a fix to this page. This page can be fixed in that bug, or in a followup.
Whatever is done, the text has to be written in the context that 99% of the time, the error will be technical, not an MITM.  So talking about "trust" or higher level things that assume an MITM will just teach people to ignore those words when they have to click through.  If the browser was wrong about trust 99% of the time, the 1% of time it is right is irrelevant.

One thing that helps more is better information.  The user has to make the decision and the only way to make that decision better is with better info.  From this point of view, it would be better if the certificate were not treated like a hot potatoe to be hidden from the user, but instead, presented to the user, and a clearer indication of what was wrong with the cert indicated to the user.

I always read the cert when I hit this error, but I only do that because I am interested to reverse-engineer what the certificate failure is this time.  I'm in the business, as most all of us here are.  Ordinary users will not however do that.  Ordinary users will click through until they get their result, so they will not see anything that helps them unless it is presented clearly.

The only way to slow them down from click-thru syndrome is some sort of info that really does say something useful and accurate.  "Trust" isn't it because it is not accurate.  Nor is "don't be in a hotel."

Which leaves certificates -- those the browser can be accurate about.  E.g., over at bug 460374 there are two certs that could have been compared and contrasted (if KCM had cached the first one like it should have) and some analysis would have presented an obvious switch from a CA-signed cert (good) to a self-signed cert (bad).  Caching CA-signed certs would allow real information to be presented in the case of a downgrade attack.
KCM would have produced exactly the wrong result in bug 460374, because in
that case, the first cert seen by the browser for every web site was the
attacker's cert.   KCM is predicated on the assumption that the first cert
seen for a given remote server is always the right one, which is precisely 
the wrong assumption in the case of bug 460374.
(In reply to comment #21)
> Whatever is done, the text has to be written in the context that 99% of the
> time, the error will be technical, not an MITM.  So talking about "trust" or
> higher level things that assume an MITM will just teach people to ignore those
> words when they have to click through.  If the browser was wrong about trust
> 99% of the time, the 1% of time it is right is irrelevant.

That's absolutely nonsense! The browser is right 100%, it's you who chooses to ignore the browser! An error is an error, no matter what!

(I'm not a fan of the "trust" word either and always proposed and suggested to use different wording, but please stay by the facts. Firefox flags all errors correctly, including domain mismatch, validity, incomplete chain, self-signed certificates, revoked certificates and more. Every time an error occurs, there is a chance that somebody tries to mislead or attack you.)

> Which leaves certificates -- those the browser can be accurate about.  E.g.,
> over at bug 460374 there are two certs that could have been compared and
> contrasted (if KCM had cached the first one like it should have)

Exactly the opposite is true here - as Nelson already indicated.
(In reply to comment #20)
> > >+   - The Original Code is Firefox certificate error page.
> > 
> > Please don't use "Firefox" if you can help it.
> 
> This is silly. Whether or not Firefox continues to exist doesn't change the
> fact that this code was added for its error page.

It appeases the crowds with trademark issues, such as the people wanting rebranding ease in bug 252361. There's no need for the word "Firefox" to be used in the code description, so why use it at all?

> > This isn't right on gnomestripe. See bug 432938 for more information and how
> > to fix this.
> 
> That bug isn't fixed yet, and the changes needed to fix it area also also
> needed for a fix to this page. This page can be fixed in that bug, or in a
> followup.

I've attached a new patch for bug 432938, and depending on which gets first, I can update my patch or not. :)
> KCM would have produced exactly the wrong result in bug 460374,
> because in that case, the first cert seen by the browser for
> every web site was the attacker's cert.

Nelson, you are correct, in this case!  Because of the unusual circumstances of the user re-installing from fresh, this is one case where KCM would not have added value to the user.

> KCM is predicated on the assumption that the first cert
> seen for a given remote server is always the right one,
> which is precisely the wrong assumption in the case of
> bug 460374.

This I find less certain!  KCM is about caching the user's validation, not about declaring the first cert seen as good.  KCM should pass the validation up to the user, and she should do that validation.  If she then clicks-thru, then that is her failure.

In this respect, KCM and PKI bear much analogy.  They both ask the user to validate in certain circumstances, and they both "fail" if she "fails to do as obliged".

Also, note that my proposal above is that KCM works *with* PKI, not either/or.  Validation in this case could have been as simple as taking the recommendation of the PKI side, but again we are hamstrung if she declines to do any validation.  There's only so much that can be done....

Supporting note:  For CA-signed certificates, the user's obligation to validate is found in the RPA or in the CPS.  Snippet from popular and representative RPA:

3. Informed Decision. You acknowledge and agree that: (i) you have sufficient information to make an informed decision as to the extent to which you choose to rely on the information in a Certificate; ... YOU ARE SOLELY RESPONSIBLE FOR DECIDING WHETHER OR NOT TO RELY ON THE INFORMATION IN A CERTIFICATE. .....
5. Your Obligations. As a Relying Party, you are obligated to ensure the reasonableness of your reliance on any [the CA's] Information by: (i) assessing whether the use of a Certificate for any given purpose is appropriate under the circumstances;

(I strongly edited the above to make the point...)  The fact that the user does not validate, properly if at all, is a fact that haunts both classical CA-signed PKI and KCM, and leads to considerable trauma at many levels. However that trauma pans out, in both models the user is obligated to validate.  If she does not, then there is a *limit to how far we can protect her*.

This user found that limit, is all.
(In reply to comment #24)
> It appeases the crowds with trademark issues, such as the people wanting
> rebranding ease in bug 252361. There's no need for the word "Firefox" to be
> used in the code description, so why use it at all?

The code description appears only in the code. This is nonsense.
Attached patch v2 - with tests (obsolete) — — Splinter Review 
This should be basically complete.  Changes include:

 - String changes (thanks to those who commented) 
 - Move the added graphics to the each of the three browser theme directories
 - Add browser chrome tests to ensure that the page is loaded on network errors, and that the expert mode pref works properly
 - Remove some dead code from a couple places that were copy/paste bugs

I didn't change the copyright claims on makefiles that were a straight copy, because I don't really think, in the traditional sense, that I *should* assert novel copyright on a direct copy.  If we have some policy of doing otherwise, I can change it, but I'm content to leave them as-is.

I changed the string references to use brandShortName but left the in-comment references to Firefox in "Original code is..." blocks.  Whatever happens to Firefox, that IS what the original code is, and I think there is precedent...   :)

http://mxr.mozilla.org/mozilla/search?string=original.*firefox&regexp=on&tree=mozilla
Attachment #343646 - Attachment is obsolete: true
Attachment #344179 - Flags: review?(bzbarsky)
Comment on attachment 344179 [details] [diff] [review]
v2 - with tests

Just for the docshell bit.  I sure do wish there was a better way than timers to write tests for error pages, but we still don't have a way to spot those loads, do we?
Attached patch How about some diff context? (obsolete) — — Splinter Review 
No change except adding a civilized amount of context.
Attachment #344179 - Attachment is obsolete: true
Attachment #344186 - Flags: review?(bzbarsky)
Attachment #344179 - Flags: review?(bzbarsky)
Johnathan,
I'm not seeing the forest for the trees.  Would you write a brief summary
of how this patch will change the user experience?  What things must (or
can) the user do differently?  What things will appear differently?
Thanks.
The CSS needs to be under browser/themes/, too.
Attachment #344186 - Flags: review?(bzbarsky) → review+
Comment on attachment 344186 [details] [diff] [review]
How about some diff context?

r=bzbarsky on the docshell bit.
Attached image Screenshots with latest patch (obsolete) — 
(In reply to comment #13)
> Any screenshots?

(In reply to comment #30)
> Johnathan,
> I'm not seeing the forest for the trees.  Would you write a brief summary
> of how this patch will change the user experience?  What things must (or
> can) the user do differently?  What things will appear differently?
> Thanks.

Attached 3 screenshots with the latest patch applied, alongside one screenshot of the old page.  On an implementation level:

 - This creates a hook for implementations to specify their own cert problem handler page, falling back to the current netError.xhtml implementation if an alternate hasn't been provided
 - This creates a component in Firefox which makes use of that hook to create its own about:certerror page
 - It continues to be a non-privileged page, with events bubbling up into privileged chrome, instead of having anything chrome-privileged in the page, or attached to elements thereof in a way that content might exploit.
 - It adds automated testing to ensure the expert pref works as expected, and that the page-override hook behaves as designed, lest it regress at some point in the future.

On a user experience level:

 - This introduces more human text, with a clearer default option
 - It makes it clear that the expert mode is for people who know what they're doing (the old text left it fairly ambiguous - "Or you can add an exception" as a hyperlink was missed by people, and I'm not interesting in "tricking" people into doing what we want)
 - It respects the existing prefs (browser.xul.error_pages.expert_bad_cert and browser.ssl_override_behavior)
 - It preserves the error code and technical details for the purposes of troubleshooting, but stops giving them top billing, since they are imposing (and impenetrable) and do not help our typical user understand what's going on
 - It fixes some subtle cueing (different border colour, proper page title) so that the page looks less like a typical error page, though followups could no doubt be filed to make this distinction more obvious.
 - The workflow to add an exception is presently identical: expand the section, add an exception, pull the cert, confirm.

I'm of the opinion that the disabling of pre-fetch in the dialog for v3.0 is not accomplishing its goal of helping users understand that dialog, and that we should change the preference there to pre-fetch when launched.  It is often a source of complaint not because of the extra step involved (since a pref change can mitigate that) but because it looks like a bug.  That change is not included in this patch, though.
Attachment #342639 - Attachment is obsolete: true
Johnathan, I think we should stick more to the technical, correct meaning of certificates and refrain from using the "Trust" word whenever possible. The title "This Site is Untrusted" isn't technically correct, rather it should say something like "This Site is not verified" or "This Site can't be identified" or something similar..

There is a long history with the "trust" word in relation to certificates which comes from trusting the CA doing the correct job. It's a trust thing...;-)

But the certificates issued to the end-user have not much to do with trust. Obviously one can trust somebody who is willing to publicly disclose his/her identity and/or organization. But the CA validates only various attributes like domain name, holder of the certificate and/or operator of the site. The identified entity may still be very untrustworthy.

Also I'm not sure if "going to the right place" will be understood by the average user. "Yes, I want to go to paypal.com, that's the right place...."

"What should I do" section is dangerous! See bug 460374
(In reply to comment #34)

> "What should I do" section is dangerous! See bug 460374

I'm very aware of bug 460374, but I don't understand how the text:

"If you don't normally see this warning for this site, it may be an attempt to trick you, and you shouldn't continue."

and a "Get me out of here" button counts as dangerous.  Perhaps you were referring to the "I Know What I'm Doing" section?

I do not believe, at a fundamental level, that we can eliminate all MitM threats out there with technology and wording tweaks.  I think the problem we have right now, and what leads to people being victimized, is that the whole model we're working with is not something users have any intuition for, nor any way to develop one.  I think avoiding jargon and giving people a clear "preferred choice" help that, but I am not going to play the game where we keep pushing the secret handshake further down.

It is a sort of tragic absurdity right now that we are making it harder for users to get through to sites with self-signed certs than it is for them to get through to known malware/phishing sites.  The exception mechanism is better for certs - trust it once and be not alerted unless something changes.  I think we can make things even better by making it clearer what's going on, but I'm not going to make it N steps harder in the hopes that finally we will have exhausted our users.
By the way, has anyone considered solving the problem (detection of MITM attacks) by providing a service in the cloud that would independently verify a certificate. If a real MITM attack is taking place then the service would see a different certificate from the one the user is seeing. This wouldn't solve the problems with self-signed certificates, but once we are able to reliably detect MITM attacks (and say "your communication is being intercepted and we cannot proceed") we can perhaps relax the handling of all other cases.
(In reply to comment #35)
> "If you don't normally see this warning for this site, it may be an attempt to
> trick you, and you shouldn't continue."
> 
> and a "Get me out of here" button counts as dangerous

"Get me out of here" is fine ;-)

But what if I've never visited that specific site? Assuming that the key received upon first visit is always the right one might be dangerous. As we all know, nobody is ever going to validate the fingerprint and such - not even admins which install those certs.

> The exception mechanism is better for
> certs - trust it once and be not alerted unless something changes.

We could argue about this one, but that's not the point here.

> I think we
> can make things even better by making it clearer what's going on, but I'm not
> going to make it N steps harder in the hopes that finally we will have
> exhausted our users.

I didn't suggest that - I'm all in favor of explaining to the user in the most simple - most easiest to understand - most correct way. Incidentally I think that the first section beneath the title has too much text. We could reduce this to "You have asked PRODUCT to connect securely to SITE, however this site's identity can't be verified". Than remove "What Should I do" and continue with regular text "This may be an attempt to trick you and you shouldn't continue." (or alternatively "you should continue only if you know the operator of this web site" ...or something like this.)

English isn't really my domain, but it seems to me too much text and the average user isn't going to read all that. Also "the right place" might be misunderstood. Some don't even understand that they tried to connect to a secure site - they followed a link or form. They maybe don't know exactly to which site they connected even...
In reply to comment 36, there is no such thing as "a service in the cloud 
that would independently verify a certificate.".  Services have been 
proposed that can detect SOME MITM attacks, with probability much less than 
100%.  But they CANNOT verify a certificate.  The absence of a detectable 
MITM is NOT the same as verifying a certificate.
(In reply to comment #38)
> In reply to comment 36, there is no such thing as "a service in the cloud 
> that would independently verify a certificate.".  Services have been 
> proposed that can detect SOME MITM attacks, with probability much less than 
> 100%.  But they CANNOT verify a certificate.  The absence of a detectable 
> MITM is NOT the same as verifying a certificate.

Indeed.  And anyone feeling inventive about designing such a serviceprobably wants bug 460627, not this one.
In reply to comment 33, 
Johnathan, thanks for the screen shots.  They make it much clearer.

Several comments.

1) the word "Untrusted" doesn't really convey the essential problem.
On this point, I agree with Eddy.  I might suggest some of these:

"This site may not be who you think it is" 
"This site may not be the site you wanted to visit" 
"This site may be an impostor" 
"This site may be an impostor, even if it looks genuine"

2) Every user always thinks "I know what I'm doing".  Overconfidence is 
the hallmark of the victim.  Any user with any pride at all will always 
choose it.  To not choose it is to say "I don't know what I'm doing", 
and no user will admit that, not even to herself.  

Let me suggest a new litmus test for proposed phrases such as this:
*  Would it have stopped Kayla?  Or even have given her pause?

Let me suggest some alternatives:

- I know the risks and am willing to take them
- I don't care that this site may be an impostor
(In reply to comment #39)
> (In reply to comment #38)
> > In reply to comment 36, there is no such thing as "a service in the cloud 
> > that would independently verify a certificate.".  Services have been 
> > proposed that can detect SOME MITM attacks, with probability much less than 
> > 100%.  But they CANNOT verify a certificate.  The absence of a detectable 
> > MITM is NOT the same as verifying a certificate.
> 
> Indeed.  And anyone feeling inventive about designing such a serviceprobably
> wants bug 460627, not this one.

My idea is to have Firefox ship a site certificate to the service and ask "are
you seeing the same certificate I am seeing?". Seeing the same certificate will
not mean there isn't a MITM attack, but seeing a different certificate will.

Thanks for the tip on 460627, I will now go over there.
(In reply to comment #41)
> Seeing the same certificate will
> not mean there isn't a MITM attack, but seeing a different certificate will.

This would provide a wrong sense of security then...or simply another security theater like self-signed certs?

Initially it seemed to me like a clever idea, but such a service would have to have requirements and controls resembling those of a CA with very stringent security requirements, like access restrictions, logical and physical controls, constant monitoring and perhaps multiple service locations similar to that of DNS or CRLDP (best practices) in order to allow reliance. There might be also a privacy issue with it.
(In reply to comment #42)
> (In reply to comment #41)
> > Seeing the same certificate will
> > not mean there isn't a MITM attack, but seeing a different certificate will.
> 
> This would provide a wrong sense of security then...or simply another security
> theater like self-signed certs?

To bug 460627 with you!

If it's not about the changes to the certificate error page, it's not for here.
I like Ivan's idea of using the word "intercepted".  It's clearer than saying the "site" is "untrusted", or that the user is "not going to the right place".  It's also slightly more likely to get a user thinking about the possibility that their internet connection, rather than Firefox or the real web site, is to blame.

How about this:

"You have asked Firefox to connect securely to johnath.com, but this communication seems to have been intercepted."

"Normally, when you connect to a secure site, it will present trusted identification so that Firefox can verify that the communication has not been intercepted.  However, Firefox cannot verify that you are in fact connecting to the real johnath.com."
This is a great description, hope that people will read all this.

For somebody who submits a form or follows a link, the sentence "You have asked Firefox to connect securely to johnath.com" still sounds somewhat funny...a user might ask, if he really did or what he did. But I don't have something better to suggest which will still keep it short and simple.
Saying the "communication has been intercepted" slips back into the idea that
self-signed SSL certs are somehow invalid. They're not invalid they simply
aren't signed. There are a huge number of uses for self-signed certs that are
100% legitimate and for which the current approach of considering it an error
is very problematic. To me, simply saying the site is "Untrusted" is both
accurate and sufficient to make people think a little about what they're doing
without completely scaring people away from the things that use self-signed
certs legitimately.
"The communication has been intercepted or the site does not present proper identification"?
In terms of interaction and overall user experience, I think these changes are
great.  However, I have a few concerns with more superficial surface stuff: the
visual design, writing tone, and the twisty interactive elements don't really
mesh with other aspects of Firefox's design.  Best case scenario the UI just
feels a little different from what we normally do, and worst case scenario the
user mistakes this for Web content instead of a Firefox message in the content
area.  We can work on this surface stuff in follow up bugs.
(In reply to comment #44)
> 
> "You have asked Firefox to connect securely to johnath.com, but this
> communication seems to have been intercepted."
> 
> "Normally, when you connect to a secure site, it will present trusted
> identification so that Firefox can verify that the communication has not been
> intercepted.  However, Firefox cannot verify that you are in fact connecting to
> the real johnath.com."


I like this, but I wouldn't say
  "seems to have been interecepted"
because we don't know.

I'd prefer:
  "might have been intercepted"
(In reply to comment #46)
> Saying the "communication has been intercepted" slips back into the idea that
> self-signed SSL certs are somehow invalid. They're not invalid they simply
> aren't signed.

Can we have a FAQ entry somewhere to where we can direct upcoming comments like these? For now please read Johnathan's SSL Question Corner: http://blog.johnath.com/2008/08/05/ssl-question-corner/
(In reply to comment #49)
> I'd prefer:
>   "might have been intercepted"

Technically more correct, I'd vote for this +1
FAQ or not, it doesn't change the fact that there are 100% legitimate uses for self-signed certificates for which these changes are causing huge problems and where it is simply impossible to use a proper CA signed certificate. Accessing the admin interface for any appliance or virtual appliance is my particular concern. In those cases the communication has not been intercepted it's just wanting encryption but because the IP isn't known in advance it's impossible to use a properly signed cert. Saying it's untrusted is OK because it is, telling users that their communications "have been intercepted" or even "might have been intercepted" is instilling fear when none is necessary. There is absolutely nothing wrong with self-signed certs when used under these circumstances. It's already inconvenient enough for people to add an exception, additional language that is intended to scare them really isn't going to help that much but it sure does hurt the legitimate uses.
(In reply to comment #52)
> telling users that their communications "have been intercepted" or even 
> "might have been intercepted" is instilling fear when none is necessary. There
> is absolutely nothing wrong with self-signed certs when used under these
> circumstances.

I disagree with this statement - there is plenty wrong with them, there is just not a particularly attractive alternative, and hence...

> additional language that is intended to scare them really isn't going to help
> that much but it sure does hurt the legitimate uses.

I agree with this.  Having fewer cases where self-signed certificates are the only practical option is something we need to keep working on, because they are a real problem for users to become accustomed to.  But in the meantime, we have to equivocate to some extent - we can't make the call on the user's behalf.

(In reply to comment #34)
> Also I'm not sure if "going to the right place" will be understood by the
> average user. "Yes, I want to go to paypal.com, that's the right place...."

Yeah, I'm trying to keep the language very casual, but I agree there is potential for confusion here.  I think I'll change it to "going to the site you intend."  A little stodgy, I think, but less confusing, and I'm really not keen to wordsmith this for another 10 rounds, especially given the upcoming string freeze, and the distinct improvement over what's currently there.

(In reply to comment #40)
> 2) Every user always thinks "I know what I'm doing".  Overconfidence is 
> the hallmark of the victim.  Any user with any pride at all will always 
> choose it.  To not choose it is to say "I don't know what I'm doing", 
> and no user will admit that, not even to herself.

I'm sensitive to the argument that we not basically "tempt" users to click a thing by implying they are un-savvy not to, but as I said in comment 35, I do not believe that we should try to keep our users safe by making it harder for them to exhibit choice here.  I have met lots of self-described noobs who would not go near an "I know what I'm doing" section, or any "custom" or "advanced" option they encounter in software.

I want this page to make the issue and the choice clear. I think the old one made both of those things unclear. I think the dialogs before that were even worse, since most people didn't even MAKE a choice, they just dismissed a dialog and continued. I think this page makes it a clear choice, and I agree that it's more findable than the FF3.0 version but I don't see that as a bad thing, even IF it means more people make a choice I would disagree with.

> Let me suggest a new litmus test for proposed phrases such as this:
> *  Would it have stopped Kayla?  Or even have given her pause?

I understand why you would suggest that litmus test, but I think it biases us much more conservative and restrictive than I would have us go.  People would make fewer mistakes if we just took the exception provision out altogether, but they would also have a worse browsing experience overall.  I understand the desire to put one before the other, but my job description involves keeping them in balance.

> Let me suggest some alternatives:
> 
> - I know the risks and am willing to take them
> - I don't care that this site may be an impostor

I like a simpler variation on your first suggestion,  I've changed it to "I Understand the Risks"

Patch for review incoming shortly
Attached patch Updated, with ui-r=beltzner (obsolete) — — Splinter Review 
Carrying forward bz's review on the docshell bit, requesting gavin's review of the browser parts.  Got over-the-shoulder ui-r from beltzner.  Updated screenshot coming.

Changes:
 - String changes integrating much of the feedback here, as well as a couple rounds with beltzner
 - Sections re-ordered so that technical details comes before "I understand the risks" (thanks again for that language, Nelson) 
 - Focusing more on the integrity of the connection instead of the trustedness of the site, both to avoid casting aspersions on legitimate sites, and also to divorce in the user's mind the trust they feel for the *site* from the trust they feel for the *connection*.
 - This patch also includes the pre-fetch pref change I mentioned in comment 33.
Attachment #344186 - Attachment is obsolete: true
Attachment #344919 - Flags: ui-review+
Attachment #344919 - Flags: review?(gavin.sharp)
Rather than showing every permutation, I'm just expanding all the sections so that people can see the strings.  The default expansion behaviour hasn't changed.
Attachment #344285 - Attachment is obsolete: true
Even though I suggested these alternatives:

> - I know the risks and am willing to take them
> - I don't care that this site may be an impostor

I'm going to now repudiate the first of them.  The problem is that users
mostly have NO IDEA what the risks are, and that statement doesn't inform
them of the risks any.  They will just "click through" without gaining 
any enlightenment.  

The second of those two suggestions is informative, and really explains 
what the risk is and strongly implies what might happen based on the choice,
I think.  Please adopt it.
(In reply to comment #53)
> (In reply to comment #34)
> > Also I'm not sure if "going to the right place" will be understood by the
> > average user. "Yes, I want to go to paypal.com, that's the right place...."
> 
> Yeah, I'm trying to keep the language very casual, but I agree there is
> potential for confusion here.  I think I'll change it to "going to the site you
> intend."  A little stodgy, I think, but less confusing, and I'm really not keen
> to wordsmith this for another 10 rounds, especially given the upcoming string
> freeze, and the distinct improvement over what's currently there.
> 

OK, please implement. Latest screen shot doesn't have the proposed wording.

> Patch for review incoming shortly

Overall very much improved. I think the new descriptions explain the issue at hand much better, also for those against any exception handling for invalid certificates. It makes it clear what it is.
Comment on attachment 344919 [details] [diff] [review]
Updated, with ui-r=beltzner

>diff --git a/browser/components/certerror/Makefile.in b/browser/components/certerror/Makefile.in

>+DIRS      = src

I kinda hate src directories, especially when they only contain one file. Just put it in certerror/ directly?

>diff --git a/browser/components/certerror/src/Makefile.in b/browser/components/certerror/src/Makefile.in

Which means this file is unneeded (it was unneeded anyways, seeing as how it was empty).

>diff --git a/browser/components/certerror/content/aboutCertError.css b/browser/components/certerror/content/aboutCertError.css

>+/* Logical CSS rules belong here, but presentation & theming rules
>+   should live in the CSS of the appropriate theme */

>+#technicalContent > h2, #expertContent > h2 {

>+#technicalContent[collapsed] > h2,
>+#expertContent[collapsed] > h2{

The separation between "logical" and "presentation" is a bit fuzzy here... The real question is whether a theme might want to change the rules, and I think that's the case for the images at least, so perhaps they should be put in the "presentation" file.

>diff --git a/browser/components/certerror/content/aboutCertError.xhtml b/browser/components/certerror/content/aboutCertError.xhtml

This file is based on netError.xhtml, so you should probably preserve its license header.

>+  <!ENTITY % netErrorDTD
>+    SYSTEM "chrome://global/locale/netError.dtd">
>+  %netErrorDTD;

What strings does this use from netError.dtd? Can we avoid the dependency, especially since it might not be obvious to future patchers of netError?

>+<html xmlns="http://www.w3.org/1999/xhtml">

>+    <!-- If the location of the favicon is changed here, the FAVICON_ERRORPAGE_URL symbol in
>+         toolkit/components/places/src/nsFaviconService.h should be updated. -->

This might also mention that netError uses the same icon, because all three need to be in sync. That might be obvious enough, I guess.

>diff --git a/browser/themes/winstripe/browser/jar.mn b/browser/themes/winstripe/browser/jar.mn

> # NOTE: If you add a new file here, you'll need to add it to the aero
> # section at the bottom of this file

Looks like you forgot about this?
Attachment #344919 - Flags: review?(gavin.sharp) → review+
Attached patch with nits — — Splinter Review 
(In reply to comment #58)
> (From update of attachment 344919 [details] [diff] [review])
> >diff --git a/browser/components/certerror/Makefile.in b/browser/components/certerror/Makefile.in
> 
> >+DIRS      = src
> 
> I kinda hate src directories, especially when they only contain one file. Just
> put it in certerror/ directly?

I agree.  Done.

> >diff --git a/browser/components/certerror/src/Makefile.in b/browser/components/certerror/src/Makefile.in
> 
> Which means this file is unneeded (it was unneeded anyways, seeing as how it
> was empty).

Quite.

> >diff --git a/browser/components/certerror/content/aboutCertError.css b/browser/components/certerror/content/aboutCertError.css

> The separation between "logical" and "presentation" is a bit fuzzy here... The
> real question is whether a theme might want to change the rules, and I think
> that's the case for the images at least, so perhaps they should be put in the
> "presentation" file.

Hmm, yeah.  It is fuzzy, but I've moved the background rules specifically.

> 
> >diff --git a/browser/components/certerror/content/aboutCertError.xhtml b/browser/components/certerror/content/aboutCertError.xhtml
> 
> This file is based on netError.xhtml, so you should probably preserve its
> license header.

Done.

> >+  <!ENTITY % netErrorDTD
> >+    SYSTEM "chrome://global/locale/netError.dtd">
> >+  %netErrorDTD;
> 
> What strings does this use from netError.dtd? Can we avoid the dependency,
> especially since it might not be obvious to future patchers of netError?

Heh, actually, the only one it used was brandShortName, via neterror's import of brand.dtd.  I've made that explicit in aboutCertError.dtd (not in aboutCertError.xhtml because the bare brand entity is never used in the xhtml, only in the other dtd entities, so it felt like it made more sense.  Also consistent with how neterror does things.)

> >+    <!-- If the location of the favicon is changed here, the FAVICON_ERRORPAGE_URL symbol in
> >+         toolkit/components/places/src/nsFaviconService.h should be updated. -->
> 
> This might also mention that netError uses the same icon, because all three
> need to be in sync. That might be obvious enough, I guess.

They don't need to be in sync per se, I could see us wanting a different favicon for certerror as a further way to distinguish, but I've put in an elaborated comment to that effect (basically, "either keep these in sync with neterror and nsFaviconService, or let nsFaviconService know if you plan to make changes")

> >diff --git a/browser/themes/winstripe/browser/jar.mn b/browser/themes/winstripe/browser/jar.mn
> 
> > # NOTE: If you add a new file here, you'll need to add it to the aero
> > # section at the bottom of this file
> 
> Looks like you forgot about this?

Hm.. Rather.
Attachment #344919 - Attachment is obsolete: true
Attachment #345295 - Flags: ui-review+
Attachment #345295 - Flags: review+
Landed: http://hg.mozilla.org/mozilla-central/rev/ab6c401333dc

(In reply to comment #56)

> The second of those two suggestions is informative, and really explains 
> what the risk is and strongly implies what might happen based on the choice,
> I think.  Please adopt it.

I appreciate your point here, but your second proposal doesn't work for me as is, and I don't want to hold the rest of the change for another round of wordsmithing.  I hope you will understand that it is not my intent to diminish the importance of communicating clearly, but instead that it is my intent to make forward progress even if it means follow-up bugs.
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Tony, Juan,

I don't think this bug requires new Litmus tests, but may change the workflow and instructions for existing litmus tests.  Flagging in-litmus? just to ensure that you get the heads up.
Flags: in-litmus?
Johnathan, 
>  second proposal doesn't work for me as is, 
How does it not work for you?  What's the issue?
(In reply to comment #62)
> How does it not work for you?  What's the issue?

(In reply to comment #56)
> Even though I suggested these alternatives:
> 
> > - I know the risks and am willing to take them
> > - I don't care that this site may be an impostor
> 
> I'm going to now repudiate the first of them.  The problem is that users
> mostly have NO IDEA what the risks are, and that statement doesn't inform
> them of the risks any.  They will just "click through" without gaining 
> any enlightenment.  
> 
> The second of those two suggestions is informative, and really explains 
> what the risk is and strongly implies what might happen based on the choice,
> I think.  Please adopt it.

I think there's a fair bit of argument by assertion there, but my sense is that you're right that some users will click through without an adequate understanding.  What I don't believe is that changing this text in detail is going to change that situation much.  A user who will agree to "I understand the risks" is either:

a) understanding the risks, in which case I don't think the other text is a helpful improvement.
b) not understanding the risks, but earnestly trying to understand what's happening and reading the text.  This user will read the changed text, but this user would already be reading the error text (we suppose) and have encountered multiple discussions of untrusted connections, impersonation, and tampered connections.
c) not understanding the risks, purely task-focused, not interested in learning.  The change you suggest (or words like it) might give them pause, and I'm not ruling out words to that effect, targeting that user.  However the particular phrasing sounds negative and vaguely insulting to the user.  Obviously users care that it might be an imposter, no one is *intending* to visit a MitM site.  What we really want to say is "I am willing to take the informed risk.  MitM is a prospect that I understand."

As I said, I do think that communicating clearly is important, and that we should file a follow-up bug if we have better text, or even a direction on what better text would be, but discussions like this one we're having right now have a way of going more than a day, and that's all it would take to sink this whole patch, given current scheduling constraints.
Depends on: 462754
No longer depends on: 462754
Blocks: 463504
Target Milestone: --- → mozilla1.9.1b2
Verified the better description (rework) of what's going on with:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081117 Minefield/3.1b2pre ID:20081117110034

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b2pre) Gecko/20081114 Minefield/3.1b2pre ID:20081114034305
Status: RESOLVED → VERIFIED
Having to actually look at the certificate before being able to navigate to the sight is a useless obstacle.  Who cares what's in the certificate?  If it doesn't check, you have to presume the connection is insecure, and the next decision to make is whether you care.  A lot of sites use SSL on ordinary public pages that don't contain anything confidential, just to add a little bit of cheap opportunistic privacy.  The effect of compromising the SSL is that you're effectively looking at those pages by ordinary HTTP, which is how those pages would typically be served on most sites anyway.  I find getting a cert warning in this situation is much more common than hitting a cert prob on a site that actually sends anything confidential.

Example: http://www.earthcam.net is a site that sells webcams.  It redirects to SSL as soon as you visit the front page.  In this instance the cert doesn't have any problems, but in other ones it's common to hit expired certs, selfsigned certs, etc.
Deciding whether you should "care" about a certain site being MITMed is tricky, too.  It doesn't just mean you're "looking" at the page; you're giving those scripts the ability to impersonate the page, possibly in a lasting way (even if your SSL exception is temporary).
Keywords: user-doc-needed
Test case added for the overall look and feel of the error page.
https://litmus.mozilla.org/show_test.cgi?id=7742
Flags: in-litmus? → in-litmus+
Depends on: 675316
Depends on: 687958
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: