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

[Steve Langasek]

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.

[Kyle Fazzari (kyrofa)]

Try visiting about:config and temporarily toggle security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_aes_256_sha to false-- that got me to a portal that was causing the same issue. Then after you get online you can set them back to true.

[Kyle Fazzari (kyrofa)]

I like that Firefox tells you about this, but I don't think this should be a non-overrideable error. This type of error should fall into the same bucket as self-signed certificates: "Hey, we don't trust this because of X. Are you sure you want to continue?"

I think that would be a decent fix for this without A) disabling this feature all together or B) making Firefox figure out if its behind a captive portal. I don't know if that would be a config change or a code change, though. Thoughts?

[Matthew Paul Thomas (mpt)]

SSL Labs provides an example of a server with the same Logjam vulnerability that Firefox reported here.[1] Like Firefox, Chromium 45 blocks the page and doesn't let me override it: "Chromium won't use insecure connections in order to protect your privacy." v45 was the first Chrome version to block it,[2] and was released 17 days after this bug was reported,[3] so it's highly likely that "run Chrome" is not a workaround any more. Firefox was just a couple of months faster[4] at blocking this particular vulnerability.
[1] https://www.ssllabs.com:10445/
[2] http://crbug.com/490240
[3] http://googlechromereleases.blogspot.co.uk/2015/09/stable-channel-update.html
[4] http://www.eweek.com/enterprise-apps/mozilla-fixes-flaws-with-firefox-39-previews-firefox-40.html

Now, the original report and the previous comment imply a common argument about the design of browser security error pages:
1. Misconfigured/vulnerable HTTPS is no less secure than HTTP.
2. Browsers let you use HTTP pages without complaint.
3. Therefore, browsers should let you use misconfigured/vulnerable HTTPS pages.

The problem is with the premise. Misconfigured/vulnerable HTTPS is no less secure than HTTP technically, but it is less secure given the way it's likely to be used. Quite often, the reason the site operator tried to use HTTPS at all was that they're doing something that really does need security, something they would never dream of using HTTP for. So without the browser knowing what a site is for, letting you use misconfigured/vulnerable HTTPS is, on average, much riskier than letting you use HTTP.

When this portal was set up, it would have been secure as far as anyone knew. It was only later that the vulnerability was discovered. So even if the padlock in the address bar was on fire and flashing alternated with a skull and crossbones, the "everything is normal" appearance of the site itself -- combined with its presence as a bookmark, browser history entry, and/or captive portal for a large organization -- would give regular visitors a very strong impression that it was still secure, and a strong desire to continue using it.

I don't think it's relevant that this particular vulnerable site happened to be a captive portal, and one that didn't ask for any sensitive info. Without the browser preventing you from using it altogether, a middler attack could have replaced the genuine portal with a fake one that says, “Due to increasing costs, we now charge $4.95 for 24 hours wi-fi, we accept all major credit cards, click here to sign up..."

[Steve Langasek (vorlon)]

On Fri, Oct 02, 2015 at 02:39:40PM -0000, Matthew Paul Thomas wrote:
> Now, the original report and the previous comment imply a common argument about the design of browser security error pages:
> 1. Misconfigured/vulnerable HTTPS is no less secure than HTTP.
> 2. Browsers let you use HTTP pages without complaint.
> 3. Therefore, browsers should let you use misconfigured/vulnerable HTTPS pages.

> The problem is with the premise. Misconfigured/vulnerable HTTPS is no
> less secure than HTTP technically, but it is less secure given the way
> it's likely to be used. Quite often, the reason the site operator tried
> to use HTTPS at all was that they're doing something that really does
> need security, something they would never dream of using HTTP for. So
> without the browser knowing what a site is for, letting you use
> misconfigured/vulnerable HTTPS is, on average, much riskier than letting
> you use HTTP.

For other SSL security issues this has always been handled by refusing to
load the page and presenting the user with an error page instead, which
includes the option to override the security problem if the user knows what
they're doing.

I know what I'm doing - I don't give a damn about the security of the
captive portal - and the browser is not giving me the option to bypass the
security exception. This security problem is NOT more severe than the class
of SSL vulnerabilities resulting from trusting SSL certificates with no CA
path.

> When this portal was set up, it would have been secure as far as anyone
> knew. It was only later that the vulnerability was discovered. So even
> if the padlock in the address bar was on fire and flashing alternated
> with a skull and crossbones, the "everything is normal" appearance of
> the site itself -- combined with its presence as a bookmark, browser
> history entry, and/or captive portal for a large organization -- would
> give regular visitors a very strong impression that it was still secure,
> and a strong desire to continue using it.

The above *existing flow already supported by the browser* provides a
mechanism to avoid this situation.

The bug is not that the browser tries to stop the user from inadvertently
communicating with an insecure site. The bug is that the browser provides
no apparent mechanism by which the user can make an informed decision to
accept the security trade-offs.

> I don't think it's relevant that this particular vulnerable site
> happened to be a captive portal, and one that didn't ask for any
> sensitive info. Without the browser preventing you from using it
> altogether, a middler attack could have replaced the genuine portal with
> a fake one that says, “Due to increasing costs, we now charge $4.95 for
> 24 hours wi-fi, we accept all major credit cards, click here to sign
> up..."

Anyone could do this *anyway* in this context by setting up their own AP and
bridging it to the real one on the backend.

In fact, $4.95 for the service of getting the user out of the middle of a
fight between their browser and an archaic captive portal doesn't seem like
a bad deal!

[Matthew Paul Thomas (mpt)]

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.

[Steve Langasek (vorlon)]

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

[Joachim R. (jro)]

I don't know if this is the right place to discuss things that are part of browser security policy. As @mpt stated, browser devs are evaluating the risk for people not aware of the issue. I doubt Ubuntu dev teams could do anything with that, this is not a technical failure that they could resolve, so we could close this bug. And be sure the day Ubuntu will loosen browsers security policies, it will make a big "bad buzz", and the all distro will be reported as "less protecting people" than distro XXX.

IMHO, even if this case (that happened to me too) is annoying, I prefer blaming the service provider rather than the browser. And once all browsers have been updated, the service provider will obviously become aware of the problem.

[Matthew Paul Thomas (mpt)]

> Quite often, the reason the site operator tried to use HTTPS at all
> was that they're doing something that really does need security,
> something they would never dream of using HTTP for. So without the
> browser knowing what a site is for, letting you use misconfigured/
> vulnerable HTTPS is, on average, much riskier than letting you use
> HTTP.

FWIW, in the three years since I wrote this, the situation has changed hugely. Browser vendors have encouraged sites in general to adopt HTTPS (both by offering new abilities only to HTTPS sites, and by showing increasingly-scary UI for HTTP), and pages loaded over HTTPS worldwide have increased from 38% to 76%. <https://letsencrypt.org/stats/#percent-pageloads> So it’s no longer the case that most HTTPS sites are “something they would never dream of using HTTP for”.

So, it might now be more justified to let people override HTTPS misconfiguration/vulnerability blockages than it was before. But maybe other factors have changed too, such as the frequency of misconfiguration or the frequency of attacks.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.