Issues with ALPN implementation in JDK 9

[Simone Bordet]

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.

How do you avoid to run the application SNI logic twice, once by you,
and once by the JDK ?
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 ?

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

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).

Thanks !

-- 
Simone Bordet
http://bordet.blogspot.com
---
Finally, no matter how good the architecture and design are,
to deliver bug-free software with optimal performance and reliability,
the implementation technique must be flawless.   Victoria Livschitz