TLS ALPN Proposal
simone.bordet at gmail.com
Fri May 22 19:16:54 UTC 2015
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
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.
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