[Bug 1485020] Re: firefox 40 shows a non-overrideable security error when talking to a captive portal

Matthew Paul Thomas mpt at canonical.com
Sun Oct 4 16:38:46 UTC 2015


It's not the case that "this has always been handled ... with an error
page ... which includes the option to override the security problem if
the user knows what they're doing". That might have been the category of
TLS error that you've noticed most. But both Firefox and Chromium have
four broad categories of TLS error, two of which do not allow override:

(A) The page is displayed, perhaps with bits omitted, with a complaining
padlock. Example: mixed content. <https://mixed.badssl.com/>

(B) "This Connection is Untrusted" (Firefox) or "Your connection is not
private" (Chromium), *with* the option to override. Examples: a self-
signed or expired cert. <https://self-signed.badssl.com/>
<https://expired.badssl.com/>

(C) The same error design, but *without* the option to override.
Example: misconfigured with HSTS registered, where ability to override
is proscribed by RFC 6797 ("the user should not be presented with a
dialog giving her the option to proceed").
<https://pinningtest.appspot.com/>

(D) "Secure Connection Failed" (Firefox) or "This web page is not
available" (Chromium), *without* the option to override. Examples:
SSLv3, OSCP errors, Freak, and the particular vulnerability here,
Logjam. <https://www.ssllabs.com:10444/>
<https://www.ssllabs.com:10445/>

I haven't been able to find the reason that C and D have different
designs. But I know two reasons that A and B aren't the only approaches
used. First, the browser may (as with SSLv3) not even contain code for
using the vulnerable protocol any more. Second, which I think is the
issue here, the easier it is for someone to override an error when they
know there's no risk in their particular case, the more likely it is
that someone *who is actually on the verge of being attacked* will
override the error too. <https://nakedsecurity.sophos.com/2015/02/03
/google-redesigns-security-warnings-after-70-of-chrome-users-ignore-
them/> ("Syrian Internet users saw SSL warnings when the Syrian Telecom
Ministry allegedly attacked Facebook users.")

Apart from RFC proscriptions, which errors belong in which category is a
subjective judgement and not immutable. For example, there's a request
to move OSCP connection failures from category D to category B.
<https://bugzilla.mozilla.org/show_bug.cgi?id=945961> So, you could
lobby the Firefox developers to move the Logjam vulnerability from D to
B too. (And Freak too?) Since Chrome now treats Logjam the same way,
you'd want to lobby the Chrome developers too.

But to convince them, it probably wouldn't be enough just to say "I know
what I'm doing". It wouldn't even be good enough to say "I know what I'm
doing AND I happen to know that the vulnerability poses no risk to this
particular site". You'd have to make the case that the total benefit, to
the proportion of people who would know what they're doing and who would
happen to know that the vulnerability poses no risk to a particular
site, would be greater than the total risk to the proportion of people
who would think that it isn't a problem in the cases when really it is.

** Bug watch added: Mozilla Bugzilla #945961
   https://bugzilla.mozilla.org/show_bug.cgi?id=945961

-- 
You received this bug notification because you are a member of Mozilla
Bugs, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1485020

Title:
  firefox 40 shows a non-overrideable security error when talking to a
  captive portal

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1485020/+subscriptions



More information about the Ubuntu-mozillateam-bugs mailing list