Issues with ALPN implementation in JDK 9

[David M. Lloyd]

On 06/14/2016 09:47 AM, Simone Bordet wrote:
> 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 ?

I'm referring to where you point out that when you read your server key 
from the key store, it didn't work with the cipher(s) that was/were 
associated with the protocol that was selected.

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

Yes.  Basically the server logic always has to be up to date with the 
latest cipher suites and that sort of thing.  Our solution to this is to 
have a security framework that is responsible for this (among other 
things).  It's not ideal but it seems to work OK so far.

-- 
- DML