Issues with ALPN implementation in JDK 9

[Jason Greene]

> On Jun 14, 2016, at 10:58 AM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 
> Hi,
> 
> On Tue, Jun 14, 2016 at 5:26 PM, Jason T. Greene
> <jason.greene at redhat.com> wrote:
>> With H2 all impls are required to support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
> 
> Unless it is discovered vulnerable.

Sure, but in that case we have to rev the H2 protocol to fix it (h2.1 or something), and users will probably have to deploy intermediate solutions (like JSSE configs) to address it. 

> 
>> 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.
> 
> Not in general, see my example.
> The server could choose an ECDSA cipher for h3, the mandatory cipher
> for h2, so the list of cipher is (ECDSA, RSA). If, at this point, the
> server chooses the protocol *before* the JDK chooses the cipher, it
> may think that h3 is a good choice, but the TLS stack chooses the RSA
> cipher.
> At this point, you have the h3 protocol with the RSA cipher, which may
> be an invalid combination.

In the case that the client doesn’t present a valid H3 cipher, that can be determined by removing all blacklisted ciphers (and unsupported ciphers), and ultimately wind up with an empty set. 

If the case is that H3 blacks all RSA, then thats an easy test right? Just verify that keystore has an ECDSA key.


-Jason