Issues with ALPN implementation in JDK 9

[David M. Lloyd]

On 06/14/2016 09:28 PM, Greg Wilkins wrote:
>
>
> On 15 June 2016 at 11:40, Jason T. Greene <jason.greene at redhat.com
> <mailto:jason.greene at redhat.com>> wrote:
>
>
>     > On Jun 14, 2016, at 7:04 PM, Greg Wilkins <gregw at webtide.com <mailto:gregw at 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:

* The requested cipher suites and TLS protocol version
* The requested ALPN protocol names (the name, BTW, is all that appears 
in the ClientHello)
* The requested SNI server names
* The SSL context's supported TLS protocol and cipher suite lists
* The available server key(s) (and possibly client key(s) as well), 
which may vary by host as well as by ALPN protocol
* A way to determine which cipher suites can use which key types
* A way to determine which cipher suites can/should be used with which 
TLS protocol versions
* Information about which cipher suites are supported by various ALPN 
protocols

Some of these bits of information are already an existing part of the 
handshake but are done too late in the process to be useful to protocol 
or host selection (for example, choosing a key by key type or trimming 
the cipher suite list by TLS protocol version).  Some of this 
information varies by ALPN protocol, and thus (IMO) has no place in the 
JDK, rather belonging in the protocol server code (for example, the 
policy as to which cipher suites are blacklisted by the ALPN protocol).

You can definitely encapsulate some of this in a general "SSL connection 
information" structure, which is in fact what we (JBoss) are doing now. 
  But the fact remains that you have to do all of this analysis before 
handshake starts for it to work.  And you can't avoid duplicating some 
of the decisions that the target SSL engine has to make.

> [...]
> In short, either the cipher/SNI logic of SslEngine has to be duplicated
> or the selection of the protocol needs to be deferred until after the
> cipher is negotiated - either by allowing the setter to be called after
> negotiation or by giving the SslEngine the information to know what
> protocols are acceptable for which ciphers.

But, you can't negotiate the cipher without considering the ALPN 
protocol.  It's not a one-way decision where the protocol decides the 
cipher suite.  You have to choose a protocol which has a chance to 
succeed because the corresponding cipher suites and key, but also you 
choose the cipher suites based on the policy of the protocol and 
available keys.  The decision has to be made all at once, otherwise you 
risk choosing a protocol and cipher suite for which you have no key, or 
a protocol and key for which there is no matching cipher suite, etc.

> I believe that duplication is unacceptable for a new feature like ALPN.
>    Does anybody really believe that it is acceptable?
> Are there any other alternatives other than the ones I've outlined above?

Well, I agree it's not ideal.  But I do not think a better (and also 
achievable) option has yet been proposed which does not exclude 
important use cases.  The current approach has the distinct advantage of 
being workable, imperfect though it may seem.

-- 
- DML