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