JDK-8051498 : JEP 244: TLS Application-Layer Protocol Negotiation Extension
  • Type: JEP
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P1
  • Status: Closed
  • Resolution: Delivered
  • Fix Versions: 9
  • Submitted: 2014-01-08
  • Updated: 2022-08-10
  • Resolved: 2017-08-07
Related Reports
Blocks :  
Blocks :  
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8062848 :  
JDK-8076355 :  
JDK-8076356 :  
JDK-8144093 :  
JDK-8242783 :  

Extend the `javax.net.ssl` package to support the TLS
[Application Layer Protocol Negotiation (ALPN) Extension](http://www.rfc-editor.org/rfc/rfc7301.txt),
which provides the means to negotiate an application protocol for a TLS connection.


In order to support TLS clients and servers wishing to use multiple
application-layer protocols over the same transport-layer port, the ALPN
extension allows a client to provide a list of the application-layer
protocols it supports, in order of preference.  A server can then select
one of the advertised client protocols and tell the client which protocol
will be used in the TLS connection.

One important consumer of this TLS extension will be the
[HTTP/2 client (JEP 110)](http://openjdk.java.net/jeps/110), which will
implement [HTTP/2](http://www.rfc-editor.org/info/rfc7540).


This feature defines a public API to negotiate the application-layer
protocols that can be transmitted over a given TLS connection.  Protocol
names are conveyed between client and server during the initial TLS

A TLS application can use an
extended `SSLParameters` class to get and set the list of
application-layer protocols that it can support on a given connection.
The TLS implementation also uses this class to retrieve the protocol
names declared by the application.

The default behavior is to select the server's most-preferred intersection value
of the enabled application protocol values.

Server applications can also externally scan the initial plaintext ClientHellos to select an
appropriate ALPN protocol value for this connection. 
This decision might be made based on offered 
TLS protocols, ciphersuites, Server Name Indication values, etc.  The server
application can then:

 - select one of the offered protocols if it will support it,
 - decide the remotely offered and locally supported ALPN values are mutually exclusive, or  
 - ignore the extension completely.

A server may alter connection parameters, such as the server certificate
it advertises, based on which application protocols are available during the

After the SSL/TLS handshake has started, there are new methods on `SSLSocket/SSLEngine`
that allow the application to query if an ALPN value has been selected yet (`getHandshakeApplicationProtocol()`).  
Once the TLS handshake has completed, an application can then
examine which protocol has been negotiated using the
`getApplicationProtocol()` method.

The proposed design follows a similar API methodology used for the
[Server Name Indication Extension (JEP 114)](http://openjdk.java.net/jeps/114),
introduced in JDK 8, but differs in that ALPN values are tied to the connection, 
not the `SSLSession`.


 - Client-side implementations should be able to work with HTTP/2 and SPDY-capable
   web servers (_e.g._, Apache/mod_spdy, Jetty, and possibly others).  SPDY is becoming
   less important, as HTTP/2 is its very public replacement.  SPDY implementations should 
   become scarce very soon.  We will certainly test using the new HTTP/2 client from JEP 110.
 - Server-side implementations should be tested against well-known TLS
   client implementations capable of using ALPN (_e.g._, GnuTLS, NSS,
   OpenSSL(beta), and Microsoft SChannel 8.1).  We do not currently
   plan on introducing any server-side ALPN-enabled applications.
   Most testing here will be some simple TLS handshakes and checking
   the negotiated values.

Added a "blocked by" link for the actual integration bug. This JEP only has JCK/Docs tasks remaining, which are not required for marking as complete. Will likely resolve this soon.

ALPN API v7 proposed: http://mail.openjdk.java.net/pipermail/security-dev/2015-October/012916.html This is close to the final API.

ALPN API v3 proposed: http://mail.openjdk.java.net/pipermail/security-dev/2015-July/012526.html

I thought Simone Bordet worked for Webtide? Anyhow... SB> I think this needs to be addressed so that a future version of the SB> Servlet specification can be implemented without requiring the hacks SB> described below. As co-spec lead for Servlet, I agree it needs to be addressed, but I don't know if Mr. Bordet's solution is the right one. I'll leave that up to the JDK team.

Red Hat Product Security is considering contribute their patch: http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html

Per RFC 7258 TLS will very likely be the default for HTTP/2. Therefore, the HTTP/2 client needs to use ALPN.

One thing to consider is how both client and server will be able to select certificates based on ALPN. Some association between ALPN String and cert will be required.

How does this relate to the work that Xuelei Fan is doing? >>>>> On Fri, 20 Jun 2014 06:31:01 +0800, Xuelei Fan <xuelei.fan@oracle.com> said: XF> Hi Edward, XF> Thanks for the additional information about the requirements and status XF> update of NPN/ALPN. I would increase the priority of the enhancement in XF> JDK 9. XF> I have not read the HTTP 2.0 specification. What application protocol XF> names need to support in TLS for HTTP 2.0? As Java SE 8 had released, XF> we cannot update public APIs to Java SE 8 any more. May need XF> alternative approach (hard-coded or system property) to configure the XF> advertised protocols for Java SE 8.

Now a standards track RFC: http://www.rfc-editor.org/rfc/rfc7301.txt

Requested for the Jetty project (http://en.wikipedia.org/wiki/Jetty_%28web_server%29) on the jdk9-dev list: http://mail.openjdk.java.net/pipermail/jdk9-dev/2014-June/000877.html

The latest draft is: http://tools.ietf.org/html/draft-ietf-tls-applayerprotoneg-05