desktop-packages team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

On Sun, Oct 04, 2015 at 04:38:46PM -0000, Matthew Paul Thomas wrote:
> (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/>

This is a reasonable thing for the RFC to specify, because HSTS is a
declaration by the server that plaintext connections are disallowed, and any
plaintext connection represents an actual, active MITM attack.  The others
are not server declarations, they're the browser (accurately) interpreting
that a connection is not secure despite being https.  The user should have
some discretion in these cases about whether to connect to a server that
/may be/ MITMed, in the absence of a server declaration.

> 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.")

And yet, the browser does provide the user with a UI for overriding
certificate verification failures.  Connecting to a server that's vulnerable
to Logjam is *not more dangerous* than connecting to a server with an
untrusted certificate.  It is this inconsistency that is the problem.

To put it another way: not only could the hypothetical attacker who wants to
resell the airport wifi for $4.95 a pop do so by frontrunning their own
AP, they could also do so by just using a self-signed certificate and
MITMing the actual server on the same network.  Because apparently those
users that we're trying to protect from themselves will still click through
*that* warning dialog, even if we've prevented them from being able to click
through *this* warning dialog.

Also of concern:  the suggested workaround is to toggle the values of
security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_256_sha to false
in about:config.  After some confusion about what these settings do and why
setting them to 'false' fixes something, it appears that what this does is
is drop these weak ciphers from the list that firefox negotiates:

  http://techdows.com/2015/05/how-to-make-firefox-browser-safe-against-
logjam-attack.html

If these values are still set to 'true' by default, then as far as I can
tell that means firefox 39+ is still allowing these ciphers in the SSL
negotiation, and then, *if these are chosen by the SSL negotiation*, firefox
refuses to talk any further to this server.

If setting these config options to 'false' lets firefox talk to these
servers, that means they had other cipher options that firefox and the
server could agree on, and so firefox should have negotiated those in the
first place instead of negotiating in bad faith.

-- 
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