TLS extensions API, ALPN and HTTP 2.0

[Vincent Ryan]

Hello Simone,

Thanks for re-raising this issue. There are indeed plans to add support for ALPN in JDK 9 but they’re still at an
early stage so the timing is good.

We would be interested in examining your implementation to explore how it fits into the current TLS APIs.
Removing the dependency on a boot class path setting is something we should address in JDK 9.

Would you be interested in co-operating on defining a new public API in JDK 9 for ALPN usage in TLS?
Typically, we use the SSLParameters class to support setting the proposed TLS parameters and use the
SSLSession class to support getting the negotiated TLS parameters. We could easily adopt a similar model
for ALPN.

Finally, please confirm that you have already signed the OCA [1]

Thanks.


____
[1] http://www.oracle.com/technetwork/oca-405177.pdf



On 18 Aug 2014, at 21:06, Simone Bordet <simone.bordet at gmail.com> wrote:

> Hi,
> 
> I was suggested to restart the discussion about the topic on this list.
> 
> I would like to reboot a discussion around an improved TLS extensions
> API in order to support ALPN (see http://tools.ietf.org/html/rfc7301), which is
> the mechanism required by HTTP 2.0 to negotiate the new version of the
> HTTP protocol.
> 
> I sent a previous message hoping that such work would have been
> included in JDK 8, but it was too late, see
> http://mail.openjdk.java.net/pipermail/jdk8-dev/2013-March/002197.html.
> 
> I think this needs to be addressed so that a future version of the
> Servlet specification can be implemented without requiring the hacks
> described below.
> 
> Under the Jetty project, we have implemented ALPN as a set of patches
> to OpenJDK classes, producing a jar that must be prepended to the boot
> classpath in order for ALPN to work, see
> https://www.eclipse.org/jetty/documentation/current/alpn-chapter.html.
> The downside of this is that for every JDK release the ALPN jar may
> need to be rebuilt incorporating JDK changes.
> The patches are available at https://github.com/jetty-project/jetty-alpn,
> while the API provided to applications is here:
> http://git.eclipse.org/c/jetty/org.eclipse.jetty.alpn.git/
> 
> While this solution works, it would be great to have a clear API in
> the JDK that would allow to add the required TLS extension without
> requiring patched classes and boot classpath jars.
> 
> This would allow applications to manage easily and in one standardized
> way TLS extensions like SNI, ALPN or NPN, chiper suite negotation,
> renegotiation, etc.
> 
> Most of the classes are already in the sun.ssl.* package, so the effort
> would be to clean them up and move them to a standard package.
> 
> A) Is there any plan to add a generic TLS extensions API to JDK 9 ?
> B) Is there a plan, perhaps in concert with the Servlet EG, to prepare
> to support ALPN in order to support HTTP 2.0 ?
> C) What would be the process to start the effort to add a TLS
> extensions API to the JDK ? Start a new JEP ?
> 
> Note that proprietary TLS Extentions API have been provided by other
> JSSE implementers such as IAIK, see
> http://javadoc.iaik.tugraz.at/isasilk/current/iaik/security/ssl/ExtensionList.html
> and its usage in
> http://javadoc.iaik.tugraz.at/isasilk/current/iaik/security/ssl/SSLSocket.html.
> 
> We are happy to contribute to this effort, but we seek guidance from the
> experts in this list.
> 
> Thanks !
> 
> -- 
> 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