Issues with ALPN implementation in JDK 9

[David M. Lloyd]

On 06/15/2016 03:35 AM, Simone Bordet wrote:
> Hi,
>
> On Wed, Jun 15, 2016 at 10:15 AM, Andrew Haley <aph at redhat.com> wrote:
>> The problem I have with reading posts about JDK9 problems is that I
>> can't tell the *severity* of the problems.  I don't know if something
>> is a total blocker or an inconvenience.  When someone uses an internal
>> sun.* class they may be doing something which must be done in order to
>> get access which would be impossible otherwise.
>
> I don't understand this comment.
>
> The main issue of this thread is the current impossibility to have a
> clean and precise ALPN implementation with minimal code.

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

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

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.

> Sure we can fallback to less optimal solutions that won't work in all cases.
> Sure we can duplicate the JDK logic and keep it up-to-date, invoke SNI
> twice, etc.
> But I don't see the point of settling for a less than optimal solution
> when there is room to make it better, and the effort is minimal.
>
> Is this issue a blocker ? Surely not, it is possible to rewrite from
> scratch a JSSE provider.
> Would I do that ? No, thanks.
>
> I am proposing 3 simple changes to be done:
>
> 1) Introduce a TLSProtocolNames class that can convert from TLS
> protocol bytes to TLS protocol names.
> 2) Introduce a TLSCipherSuiteNames class that can convert from TLS
> cipher suite bytes to TLS cipher suite names.
> 3) Delay handshaker.started=true so that it would simpler and more
> precise for an application to handle ALPN.

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.

> I think these changes will benefit all the people involved in network
> servers having to play with ALPN.
>
> We *are* still in time, according to Mark Reinhold.
> The changes are simple.
>
> We have not heard from Oracle yet, but I can prepare a webrev if that helps.
>

-- 
- DML