Issues with ALPN implementation in JDK 9

[Simone Bordet]

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.

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

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz