TLS extensions API, ALPN and HTTP 2.0

Simone Bordet simone.bordet at
Mon Aug 18 20:06:58 UTC 2014


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

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
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,
while the API provided to applications is here:

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
and its usage in

We are happy to contribute to this effort, but we seek guidance from the
experts in this list.

Thanks !

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