Comment 4 for bug 1485020

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!