Next Protocol Negotiation TLS Extension

[Simone Bordet]

Hi all,

[cross-posted to jdk8-dev and security-dev]

I am a member of the Jetty servlet container
(http://eclipse.org/jetty) team and the implementor of the Next
Protocol Negotiation (NPN) TLS Extension used by Jetty to support the
SPDY protocol (API at
http://git.eclipse.org/c/jetty/org.eclipse.jetty.npn.git/ and
implementation at https://github.com/jetty-project/jetty-npn).
The SPDY protocol has been chosen as the basis for HTTP 2.0.

I would like to ask for suggestions for what would be the best way to
have NPN support in OpenJDK 8 rather than via the Jetty NPN
implementation.

Currently, the Jetty implementation is kind of "hacky" in that it is
the smallest possible hack (in a positive meaning) to make NPN work in
OpenJDK. It modifies 5 sun.security.ssl.* classes and introduces 5 new
classes. These modifies classes must be put in the bootclasspath.
The API of public classes like SSLEngine is not modified; instead the
current implementation relies on a static class that maps SSLEngine
(or SSLSocket) with application code that is invoked at the right time
during the TLS handshake when NPN data is detected.

Currently, the Jetty project maintains the NPN implementation locked
with OpenJDK "releases": every time the sun.security.ssl.* classes are
modified, we pull in the changes from OpenJDK, re-patch these classes
with NPN support and make a new release of the NPN jar.

The NPN TLS extension requires an API exposed to applications (usually
web servers, but they are "applications" for the Java runtime). In
this sense, JEP 114 (http://openjdk.java.net/jeps/114, SNI TLS
extension) is similar: I am guessing it also has to expose an API to
applications.
It seems to me that both NPN and SNI would require a standard way to
access TLS extensions at the proper time during the TLS handshake.
In light of this, it would be great if NPN could be piggybacked on JEP
114, exposing a standard TLS extensions API provided by OpenJDK that
application can use to plug in their code for NPN and/or SNI.

Now, I understand that designing a TLS extensions API is not as simple
as including the current Jetty NPN implementation in OpenJDK, but I
would rather see a generic solution in OpenJDK rather than a "hacky"
solution like current Jetty NPN's included in OpenJDK.
A "private" TLS extensions API already exists in the
sun.security.ssl.* classes, but it's mostly package private and of
course under sun.* packages. So perhaps the work to be done is not a
from-scratch effort.

I would like to get a discussion started on how NPN can be supported
in OpenJDK 8.

Ideally, my best plan would be:

* NPN included in JEP 114.
* JEP 114 designing a standard TLS extensions API that can serve for
both NPN and SNI (and, generically, others TLS extensions)
* JEP 114 shipped in OpenJDK 8.

We're happy to keep Jetty NPN up-to-date for OpenJDK 7 "releases", but
we will really like to see NPN in OpenJDK 8.

We are open to comply with any legal papers that needs to be in place
for this contribution.

I will be more than happy to provide detailed information about the
implementation of Jetty NPN and have it discussed (or even reviewed)
by security experts.

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