On Sun, Oct 04, 2015 at 04:38:46PM -0000, Matthew Paul Thomas wrote:
> (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/>

This is a reasonable thing for the RFC to specify, because HSTS is a
declaration by the server that plaintext connections are disallowed, and any
plaintext connection represents an actual, active MITM attack.  The others
are not server declarations, they're the browser (accurately) interpreting
that a connection is not secure despite being https.  The user should have
some discretion in these cases about whether to connect to a server that
/may be/ MITMed, in the absence of a server declaration.

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

And yet, the browser does provide the user with a UI for overriding
certificate verification failures.  Connecting to a server that's vulnerable
to Logjam is *not more dangerous* than connecting to a server with an
untrusted certificate.  It is this inconsistency that is the problem.

To put it another way: not only could the hypothetical attacker who wants to
resell the airport wifi for $4.95 a pop do so by frontrunning their own
AP, they could also do so by just using a self-signed certificate and
MITMing the actual server on the same network.  Because apparently those
users that we're trying to protect from themselves will still click through
*that* warning dialog, even if we've prevented them from being able to click
through *this* warning dialog.

Also of concern:  the suggested workaround is to toggle the values of
security.ssl3.dhe_rsa_aes_128_sha and security.ssl3.dhe_rsa_256_sha to false
in about:config.  After some confusion about what these settings do and why
setting them to 'false' fixes something, it appears that what this does is
is drop these weak ciphers from the list that firefox negotiates:

  http://techdows.com/2015/05/how-to-make-firefox-browser-safe-against-logjam-attack.html

If these values are still set to 'true' by default, then as far as I can
tell that means firefox 39+ is still allowing these ciphers in the SSL
negotiation, and then, *if these are chosen by the SSL negotiation*, firefox
refuses to talk any further to this server.

If setting these config options to 'false' lets firefox talk to these
servers, that means they had other cipher options that firefox and the
server could agree on, and so firefox should have negotiated those in the
first place instead of negotiating in bad faith.