Comment 5 for bug 1485020

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.