Re: 9.2.2 Cipher fallback and FF<->Jetty interop problem

[Martin Thomson <[e-mail]>]

On 4 September 2014 19:12, Greg Wilkins <[e-mail]> wrote:
> Thus I don't have the information available to exclude h2-14 from the
> protocol list on the basis of negotiated cipher.

The server selects both ALPN and cipher suite.

If ALPN is picked first of those two in the OpenJDK implementation,
that's fine, as long as the cipher suite selection is OK.

A client offering "h2" should be including valid choices, so the only
problem is tweaking the suite selection process somehow.  In NSS,
there's a list of supported and enabled suites from which the server
picks the first available.  Ensuring that valid choices appear before
invalid ones will make software like that produce the right outcome.

It looks like OpenJDK does the same based on the order of
preferLocalCipherSuites and getActiveCipherSuites():
  http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/security/ssl/ServerHandshaker.java#l980

If you have preferLocalCipherSuites off, you should be OK with Firefox
as long as the necessary suites are enabled, but I'd want to turn it
on to avoid problems.  There might need to be some other tweaks to
enable ECDHE, I know that Chromium had some issues when in the server
role for DTLS because it's not on by default in OpenSSL/BoringSSL.

INADEQUATE_SECURITY is there as a backstop, should this process fail.
I don't see any reason why it should be necessary if you are correctly
configured.