Issues with ALPN implementation in JDK 9

[Jason Greene]

> On Jun 15, 2016, at 7:07 AM, David M. Lloyd <david.lloyd at redhat.com> wrote:
> 
> On 06/14/2016 09:28 PM, Greg Wilkins wrote:
>> 
>> 
>> On 15 June 2016 at 11:40, Jason T. Greene <jason.greene at redhat.com
>> <mailto:jason.greene at redhat.com>> wrote:
>> 
>> 
>>    > On Jun 14, 2016, at 7:04 PM, Greg Wilkins <gregw at webtide.com <mailto:gregw at webtide.com>> wrote:
>>    >
>>    > If SslEngine is changed to allow the negotiated application protocol to be set up until the time the hello response was wrapped, that would fix the problem.  Would it create any others?
>> 
>>    Well the fundamental issue is that the application protocol isn't a
>>    direct function of a cipher, rather the application protocol has a
>>    policy of allowed ciphers and optimal selection is finding the most
>>    recent protocol with a matching allowed cipher.
>> 
>> 
>> So doesn't that make application protocol a function of the negotiated
>> cipher?     Isn't working out which of the acceptable protocols allows
>> the negotiated cipher a function?
> 
> No, you can't take the ciphers and spit out a protocol during handshake.  You also have to consider the host name(s) and available key(s) for each, and in addition you might have separate (possibly pre-existing) SSL contexts for different protocols (after all, protocols aren't just limited to two flavors of HTTP), or you might even want to proxy the connection instead of handling it locally in certain cases.
> 
> But leaving the multiple-SSLContext case aside, the pieces of information that are relevant are:

-snip-

Here is an H2 example:

The ClientHello expressing interest in both h2, and h1, and lists the ciphers:
    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

So in this case the client is expressing a preference for a CBC cipher using stronger keys, but is blacklisted by h2 due to not being GCM, but this is allowed by h1. The JDK will follow the client hello as the TLS spec describes, and so it will select TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384, and the protocol stack will incorrectly select h1.

Now technically H2 clients can avoid this by ordering h2 compliant ciphers on top, but they might not do so.

The flaw really starts to show when you have multiple alternative protocols with completely different requirements. As an example, if you have a hypothetical protocol which does not perform certificate based authentication, and instead utilizes pre-shared keys or anonymous ciphers, that protocol can never be selected unless those algs are on the top of the list, if they are on the top of the list then h2 can’t be selected.

-Jason