Issues with ALPN implementation in JDK 9

[Jason T. Greene]

> On Jun 14, 2016, at 8:58 AM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> During the unwrap(), the JDK implementation picks a cipher based on
> the JDK logic.
> In particular, in my case, I had a keystore with a certificate that
> was *not* ECDSA.
> If, in the snippet above, I set more than one cipher on the
> SSLParameters, then perhaps a weaker cipher could be negotiated that
> is not good for h3.
> Otherwise, if I set only one cipher, there are no ciphers in common
> and the TLS handshake is terminated with an error.

With H2 all impls are required to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 , so that should be selectable either by your protocol stack or the TLS layer.  If you wanted to be especially lazy you could just exclude any blacklisted cipher list presented in the client hello,  and verify that additional ones are present, and if so set the rest as the available cipher set in SSL params. The TLS stack will pick appropriately at that point. This is future proof, because an H protocol version increase is required to introduce further restrictions. Once you have code that understands the new H version you can add additional blacklisted values for that version, and you are once again future proof.