TLS ALPN Proposal v5

[David M. Lloyd]

On 09/25/2015 11:37 AM, Simone Bordet wrote:
> David,
>
> sorry, but I don't understand your proposal.
>
> Can you please write it down in pseudo code what a server application
> should do and what the JDK should do to negotiate HTTP/2 with a client
> ?

Sure.

A: receive raw SSL packet on Socket or SocketChannel
A: examine SSL ClientHello, extract SNI, ALPN, cipher suite info
A: use whatever algorithm(s) you want to analyze SNI/ALPN/cipher suite info
A: either proxy the connection, or obtain or create the relevant 
SSLContext from the desired provider
A: construct server-side SSLSocket/SSLEngine from SSLContext
A: setApplicationProtocol(H2)
A: setEnabledCipherSuites(only allowed suites in desired order)
A: start handshake
J: receive ClientHello (buffered from A)
J: verify SNI is matched, fail otherwise (as today)
J: verify ALPN is matched, fail otherwise (new)
J: send ServerHello (with the single, user-selected protocol)
...

This is very simple from the JDK perspective, and also much more flexible.

> I don't see how it is even possible for a user to decide anything
> *before* the handshaking is even initiated, like you say.
> It obviously does not have enough information.

It has the ClientHello, which should be more than enough.

> This is the current algorithm (A=app code, J=JDK code):
>
> A: sslParameters.setApplicationProtocols(H2, H1);
> A: (optional, only needed for H2) sort ciphers to favor H2
> A: start handshake
> J: receive ClientHello
> J: ciphers = intersect client/server ciphers
> J: aps = intersect client/server application protocols
> J: for each cipher in ciphers
> J:    for each ap in aps
> J:        if (ap.matches(cipher & other info)) break
> J     end // aps
> [A: ap.matches() calls into application code to return whether ap is
> good for the given info]
> J:    if (ap was not selected) continue; // to next cipher
> J:    if (trySetCipherSuite(cipher)) break; // success
> J: end // ciphers
> J: send ServerHello
> J: terminate handshake
> A: sslEngine/sslSocket.getApplicationProtocol()

So complex!  What if this algorithm is not adequate for new protocols? 
Is there not a danger associated with assuming HTTP/2 is your only use 
case?  What if the application wants to make a decision that this scheme 
cannot support?

> Note that the JDK provides default implementations for H1 and H2 for
> ap.matches(), but in general these will be implemented by application
> code.
>
> For an application that wants to support H2, this boils down to the
> first 2 lines, the rest is in the JDK.

-- 
- DML