Issues with ALPN implementation in JDK 9

[Simone Bordet]

Hi,

On Tue, Jun 14, 2016 at 5:58 PM, Simone Bordet <simone.bordet at gmail.com> wrote:
> 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.

Just to add more information here.

If the server logic chooses h3 and also restricts the ciphers to only
(ECDSA) to make sure that h3 is chosen, the JDK may find that the
cipher is not good for the certificate, and therefore there are no
ciphers in common and the connection is terminated. There is no
negotiation, although h2 with RSA would have been a valid combination.

If handshaker.started=true is delayed, the server could wait for the
JDK to choose a cipher, and then a suitable protocol for that cipher,
which in the example would be h2, and the negotiation would be
successful.

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