Issues with ALPN implementation in JDK 9

[Simone Bordet]

Hi,

On Tue, Jun 14, 2016 at 4:31 PM, David M. Lloyd <david.lloyd at redhat.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.
>
> Could you not use the available keys as an input into your own protocol
> selection?  Granted you have to know what kind of key works with what
> algorithm, but if you already have a table of cipher suites, you might as
> well just add it on there...

By "keys" here you mean, exactly ?

>> However, this means duplicating all the JDK logic to make sure that
>> the server logic *before* calling unwrap() is the same of the JDK so
>> that when unwrap() is called there will be no failures.
>
> I don't think you have to duplicate the exact logic though.  It's not really
> a "black box": if you know the cipher suites supported by your available
> key(s) then you should have enough information to know, based on the client
> cipher suites and the per-protocol suites, and the cipher suites available
> in the SSL context(s), which protocols can complete.

Well, perhaps.

My point is that I implement some logic in the server, say version 10.
Server 10 works with JDK 9.1.0.
Time passes, JDK gets updated to 9.1.173, which has now a different
logic, for whatever reason.
Try to run server 10 with JDK 9.1.173 does not negotiate the right protocol.

>> I don't think this is maintainable; the JDK is entitled to change the
>> logic following CVEs, optimizations and what not, and each such change
>> risks to break existing server code.
>
>
> What kind of change do you anticipate being a breaking change?  Are you
> thinking of e.g. blacklisting some known-bad cipher suite or something?

Well, take ECDSA for instance. Before that, my logic on server version
10 was not caring about ECDSA.
My server version 10 was working with JDK 5, but not with JDK 9
(assuming that JDK 5 did not have support for ECDSA).
That is a breaking change to me.

I imagine in the future ECDSA be replaced by something else, or a
different DSA being used, I have to change the server code.
I would like to avoid that, and keep the server logic independent of
how the JDK chooses the cipher.

Makes sense ?

Thanks !

-- 
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.