Issues with ALPN implementation in JDK 9

Jason Greene jason.greene at
Wed Jun 15 18:12:08 UTC 2016

> On Jun 15, 2016, at 7:07 AM, David M. Lloyd <david.lloyd at> wrote:
> On 06/14/2016 09:28 PM, Greg Wilkins wrote:
>> On 15 June 2016 at 11:40, Jason T. Greene <jason.greene at
>> <mailto:jason.greene at>> wrote:
>>    > On Jun 14, 2016, at 7:04 PM, Greg Wilkins <gregw at <mailto:gregw at>> 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:


Here is an H2 example:

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

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.


More information about the security-dev mailing list