desktop-packages team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

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!

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