A fully fledged TLS Extensions API ?

[Bradford Wetmore]

Simone,

Your note was good timing.  ALPN and HTTP/2 is on our radar for 9, and 
we're starting to look at options now, maybe even using some type of 
general extension API.  ALPN is pretty straightforward and can be done 
easily, but there are advantages to having a full extensions API.

We're also looking at the older threads for additional context.

Brad

PS.  Just a quick note, the reason for SSLSocket/SSLEngine/SSLParameters 
having duplicate methods is purely historical.  Up to JDK 1.5 we added 
new methods to SSLEngine/SSLSocket for each new configuration option, 
but in JDK 6 a parameter group seemed a better way to go, so the 
"duplicate" APIs were added.  The group allowed for a single call, which 
made for easier config of multiple sockets.

     sslp = sslSocket1.getSSLParameters();
or
     sslp = new SSLParameters();
     sslp.set...();
     sslp.set...();
     sslp.set...();

     sslSocket2.setSSLParameters(sslp);
     sslSocket3.setSSLParameters(sslp);




On 11/7/2014 5:06 AM, Simone Bordet wrote:
> Hi,
>
> I was writing the email about the ALPN API proposal when I realized
> that it would have been better to split the arguments in different
> emails.
>
> This email is about the idea to introduce in JDK 9 a fully fledged TLS
> Extensions API.
>
> Adding ALPN [0] support to JDK 9 requires, differently from other TLS
> extensions, to provide application code that will be run in the
> context of the TLS implementation, rather than just values such as
> booleans or strings.
>
> IMHO this chance can be lifted to provide a full TLS Extensions API.
> Alternative providers such as IAIK offer a private API such as [1]:
>
> SSLSocket.getActiveExtensions()
> SSLSocket.getPeerExtensions()
>
> Similarly, BouncyCastle offers [2]:
>
> DefaultTlsClient.getClientExtensions()
>
> In the JDK there is a class named SSLParameters that contains some of
> the configuration values for TLS.
> Some of those are duplicated in SSLSocket and SSLEngine (e.g.
> wantClientAuth, needClientAuth, etc), with some temporal dependency
> (call this before the other, if I have to trust the comments of
> SSLSocketImpl.setHost()).
> Eventually all values get forwarded to the handshaker, but from the
> API point of view it's not very clear what API one should call (the
> one on SSLEngine or the one on SSLParameters), nor where the ALPN
> setup should be done.
>
> The idea would then be to introduce a fully fledged TLS extensions API
> to handle all the TLS extensions related things, such as
> renegotiation, SNI, elliptic curves, NPN, ALPN, session tickets etc.
> Both applications and the JDK implementation would be able to leverage
> this new API.
>
> Note that the bulk of this API already exists in sun.security.ssl.
>
> My question is really whether JDK 9 could take in consideration such
> TLS Extension API be exposed publicly for applications to use it.
>
> See the other emails about ALPN and the interaction between ALPN and
> HTTP 2 for further examples of where this TLS Extension API would come
> handy.
>
> Thanks !
>
> [0] http://tools.ietf.org/html/rfc7301
> [1] http://javadoc.iaik.tugraz.at/isasilk/current/iaik/security/ssl/SSLSocket.html
> [2] https://www.bouncycastle.org/docs/docs1.5on/org/bouncycastle/crypto/tls/DefaultTlsClient.html
>