TLS ALPN Proposal

Simone Bordet simone.bordet at
Fri May 22 19:16:54 UTC 2015


On Fri, May 22, 2015 at 8:54 PM, Sean Mullan <sean.mullan at> 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

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

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

More information about the security-dev mailing list