TLS ALPN Proposal

[Simone Bordet]

Hi,

On Fri, May 22, 2015 at 8:54 PM, Sean Mullan <sean.mullan at oracle.com> wrote:
> There's actually a bunch of methods in common, so one possibility is to
> create a new interface containing the common methods (say SSLBase for now
> for lack of a better name). Then you could change SSLEngine and SSLSocket to
> implement SSLBase (which should be a compatible change), and then have a
> single method on ApplicationProtocolSelector. Question is if there are
> enough common methods to do what you want? I don't know enough about ALPN to
> answer that question.

There are 2 things that conflate here: one is to provide the mechanism
to support ALPN, and the second is to make sure that it is possible to
support HTTP/2.

ALPN per se, for example, does not need any information about
SSLEngine or TLS protocol versions or ciphers.
It just needs the protocol strings, so the ApplicationProtocolSelector
would just need select(List<String>).

For HTTP/2, however, the choice of the protocol will depend on the TLS
version and the cipher, so we will need a way to obtain that
information.

Typically, in the code where you pass the ApplicationProtocolSelector
you have the SSLEngine available, e.g.:

sslEngine.getSSLParameters().setApplicationProtocolSelector(new
ApplicationProtocolSelector()
{
    public String select(List<String> clientProtocols)
    {
        // Here sslEngine will be in lexical scope
    }
});

In this way, ApplicationProtocolSelector won't depend on SSLEngine or
SSLSocket, and can be reduced to a FunctionalInterface.

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