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. ** Bug watch added: Mozilla Bugzilla #945961 https://bugzilla.mozilla.org/show_bug.cgi?id=945961 -- 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 -- Mailing list: https://launchpad.net/~desktop-packages Post to : desktop-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
