Next Protocol Negotiation TLS Extension

[Brad Wetmore]

Hi Simone,

I haven't looked at the proposal yet, but just from a scheduling point 
of view, unfortunately we're finishing up the implementation of the last 
of the planned features for JDK 8, so getting this into 8 is likely not 
possible.

We have an open bug for this (JDK-8007785) and it's on the radar for JDK 
9.  I'll put in a link to your email in that bug.

I know Xuelei will want to look at this more closely, and I hope to also.

Brad



On 3/21/2013 9:01 AM, Simone Bordet wrote:
> 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
>