Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8051498

JEP 244: TLS Application-Layer Protocol Negotiation Extension

    Details

    • Author:
      Vincent Ryan
    • JEP Type:
      Feature
    • Exposure:
      Open
    • Subcomponent:
    • Scope:
      SE
    • Discussion:
      security dash dev at openjdk dot java dot net
    • Effort:
      S
    • Alert Status:
       Green
    • JEP Number:
      244

      Description

      Summary

      Extend the javax.net.ssl package to support the TLS Application Layer Protocol Negotiation (ALPN) Extension, which provides the means to negotiate an application protocol for a TLS connection.

      Motivation

      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), which will implement HTTP/2.

      Description

      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 handshake.

      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 connection.

      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), introduced in JDK 8, but differs in that ALPN values are tied to the connection, not the SSLSession.

      Testing

      • 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.

        Issue Links

          Activity

          Hide
          xuelei Xue-Lei Fan added a comment -
          Red Hat Product Security is considering contribute their patch:

          http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html
          Show
          xuelei Xue-Lei Fan added a comment - Red Hat Product Security is considering contribute their patch: http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html
          Hide
          ejburns Ed Burns added a comment -
          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.
          Show
          ejburns Ed Burns added a comment - 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.
          Show
          wetmore Bradford Wetmore added a comment - ALPN API v3 proposed:      http://mail.openjdk.java.net/pipermail/security-dev/2015-July/012526.html
          Hide
          wetmore Bradford Wetmore added a comment -
          ALPN API v7 proposed:

              http://mail.openjdk.java.net/pipermail/security-dev/2015-October/012916.html

          This is close to the final API.
          Show
          wetmore Bradford Wetmore added a comment - ALPN API v7 proposed:      http://mail.openjdk.java.net/pipermail/security-dev/2015-October/012916.html This is close to the final API.
          Hide
          wetmore Bradford Wetmore added a comment - - edited
          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.
          Show
          wetmore Bradford Wetmore added a comment - - edited 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.

            People

            • Assignee:
              wetmore Bradford Wetmore
              Reporter:
              michaelm Michael McMahon
              Owner:
              Bradford Wetmore
              Reviewed By:
              Brian Goetz, Sean Mullan
              Endorsed By:
              Brian Goetz
            • Votes:
              1 Vote for this issue
              Watchers:
              14 Start watching this issue

              Dates

              • Due:
                Created:
                Updated:
                Resolved:
                Integration Due: