Issues with ALPN implementation in JDK 9

[Simone Bordet]

Hi,

On Tue, Jun 14, 2016 at 8:11 PM, Jason Greene <jason.greene at redhat.com> wrote:
> If the case is that H3 blacks all RSA, then thats an easy test right? Just verify that keystore has an ECDSA key.

I don't think it is that easy.

The server logic has to mimic exactly what the JDK logic is, that is
to verify the cipher and certificate compatibility.
Not only, the server has to run the logic for SNI, the same logic that
the JDK runs to get the right certificate. This logic would now run
twice.

As I said, it is doable as long as the server logic duplicates and
keeps in sync with the JDK logic so that it is guaranteed that the
application protocol chosen by the server ends up with a cipher,
chosen by the JDK, valid for that protocol.
The moment the logic is different, there is a problem.

Every time the JDK updates, you and me have to go and look inside the
JDK to check whether the logic is changed, and if so, update our
servers.
And then we have to say that version X of our server only works with
JDKs up to version Y, and that version X+1 of our server only works
with JDK version Y+1.
Been there, done that. I'd like to move to a better model that is future proof.
I don't control which JDK people use to run Jetty.

I would rather not duplicate all the JDK logic into an application.

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