desktop-packages team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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 Desktop
Packages, 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

Status in firefox package in Ubuntu:
  New

Bug description:
  When trying to connect to the airport wifi at the Portland Airport
  (https://flypdxconnect.portofportland.com:8443/guestportal/gateway?sessionId=eb0a3d0a003315a2c104ce55&portal=LOC1&action=cwa),
  firefox presents me with a non-overrideable security error:

  Secure Connection Failed

  An error occurred during a connection to
  flypdxconnect.portofportland.com:8443. SSL received a weak ephemeral
  Diffie-Hellman key in Server Key Exchange handshake message. (Error
  code: ssl_error_weak_server_ephemeral_dh_key)

      The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
      Please contact the website owners to inform them of this problem.

  When the user is behind a captive portal and talking to that portal is
  the only way to get Internet access, it is not acceptable to enforce
  an SSL security policy where the user has no way of overriding it, no
  way of fixing the server, and no reason to care about the security of
  the connection to this server.

  As a workaround for this issue, I ran chrome.

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