Comment 3 for bug 1485020

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