Issues with ALPN implementation in JDK 9

[David M. Lloyd]

On 06/15/2016 07:36 AM, Simone Bordet wrote:
> Hi,
>
> On Wed, Jun 15, 2016 at 1:31 PM, David M. Lloyd <david.lloyd at redhat.com> wrote:
>> The problem is that this is quite subjective.  In my opinion the current
>> solution is both clean and precise:
>>
>> 1) Read the hello packet
>> 2) Examine the protocols, host names, and cipher suites
>> 3) Apply arbitrary user policy to select the enabled cipher suites and even
>> possibly the SSL context to use based on:
>>     * The above information
>>     * The supported cipher suites (for each SSL context, if multiple)
>>     * The available host key types for each host and/or protocol
>>     * Any user-driven factor that goes beyond *just* HTTP 2
>
> Sure, that's the duplication of what the JDK does.
> Change logic in the JDK, change logic above.

Sure, the JDK has the same logic but does it go beyond matching the key 
type with the cipher suite?  You can't avoid doing this in the user 
handler AFAICT, so yes that duplication stands.  What kind of change in 
the JDK logic are you thinking of?

> How do you avoid to run the application SNI logic twice, once by you,
> and once by the JDK ?

You can't avoid it.  But this is different logic: the user chooses which 
host to use (and what SSL context, key, etc.) and the JDK simply 
verifies that choice.

> What if that SNI logic, provided by an external application, has side effects ?
>
> Your bullets above are "precise" only under the assumption that those
> bullets are exactly what the JDK does.
> If it's not the case, then they're broken.
>
> I understand for you is not a big deal to replicate the JDK logic and
> keeping it up to date, and banning certain versions of your code to
> run with certain versions of the JDK.
> I hope you understand it's not the case for others; for example, we
> don't control with what JDK versions people run Jetty.
>
> If JDK 10 changes the logic, we will have to say: "Oh, sorry, you
> cannot run Jetty 9 (the current version) with JDK 10".
> And we won't be able to change the logic in Jetty 9, because we would
> break previous JDKs.
> We will be back to sniffing what JDK it is. Yuck.
>
>> No matter what the JDK does, it will not be able to encapsulate a completely
>> arbitrary user policy - certainly not precisely - during handshake, nor will
>> it be able to allow for the selection of different SSLContexts based on that
>> policy (let alone proxying the connection).
>
> Can you detail a case ?

A very simple case: you have two completely different protocols 
multiplexed on port 443.  Each of these protocols has its own 
SSLContext.  You read the client hello and dispatch to the appropriate 
downstream service based on protocol (and possibly other factors).

Another case is that you have a service running on a separate system. 
If the protocol and/or host matches, the network connection is proxied 
to the downstream system, otherwise it is handled locally.

>> The best that can be done in the
>> JDK, in my opinion, is to provide various utilities to simplify implementing
>> the above: a helpful SSL explorer style class, which includes mapping the
>> protocol and cipher suite list (which I believe we agree on) and perhaps
>> providing information about the key type(s) supported by each cipher suite,
>> so the user can compare this against the available key types.
>
> Unfortunately this SSL Explorer class has not yet been provided.
> If it was, it would be helpful. But I think it will just hit the same
> problems I hit: logic duplication and running SNI twice.
>
>> Once you know what cipher suites are offered, and you have selected the
>> protocol, host, and enabled cipher suites, there isn't a great deal of
>> mystery left in the JDK: it simply carries out the negotiation that you
>> specified.
>
> IFF your logic is the same as the JDK.
>
> I don't want to check this every time a JDK release is made.
> Why you enjoy doing this this check, it's a mystery to me :)
>
>> I agree with 1 and 2, at least in concept if not in specifics, but I think 3 is a mistake:
>> if you've committed to an SSL context then it's already too late to make some
>> possibly important decisions, and SNI can play a factor here too.
>> We can make this easier but I think that trying to do this all inside of the
>> handshake process is going to cut off some important use cases.
>
> Which use cases ?

Multiple SSLContext, network proxying.

> BTW, the delay of handshaker.started=true would be irrelevant to the
> TLS mechanism, it's just an implementation detail.
> The information that needs to be reported in the ServerHello is only
> needed when the ServerHello is being constructed.
>
> Had the JDK implementation been written with a delayed
> handshaker.started=true we would have the best of both worlds.
> You could write your own solution, we could write our own.
> Yours will have some restrictions, and so will ours (just different ones).

Fair enough.

-- 
- DML