desktop-packages team mailing list archive

[Matthew Paul Thomas <mpt@xxxxxxxxxxxxx>]

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

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