JEP 244: TLS Application-Layer Protocol Negotiation ExtensionJEP 244: TLS Application-Layer Protocol Negotiation ExtensionAuthorVincent RyanOwnerBradford WetmoreTypeFeatureScopeSEStatusClosed / DeliveredRelease9Componentsecurity-libs / javax.net.sslDiscussionsecurity dash dev at openjdk dot java dot netEffortSDepends8144093: JEP 244/8051498 - TLS Application-Layer Protocol Negotiation Extension Relates toJEP 110: HTTP/2 Client (Incubator)8230977: JEP 244: TLS Application-Layer Protocol Negotiation Extension (Java SE 8)Reviewed byBrian Goetz, Sean MullanEndorsed byBrian GoetzCreated2014/01/08 14:49Updated2022/08/10 21:16Issue8051498Summary
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.

InstallingContributingSponsoringDevelopers' GuideVulnerabilitiesJDK GA/EA BuildsMailing listsWiki
                      · IRCBylaws · CensusLegalWorkshopJEP ProcessSource codeMercurialGitHubToolsGitjtreg harnessGroups(overview)AdoptionBuildClient LibrariesCompatibility & Specification ReviewCompilerConformanceCore LibrariesGoverning BoardHotSpotIDE Tooling & SupportInternationalizationJMXMembersNetworkingPortersQualitySecurityServiceabilityVulnerabilityWebProjects(overview,
      archive)AmberBabylonCRaCCaciocavalloClosuresCode ToolsCoinCommon VM InterfaceCompiler GrammarDetroitDevelopers' GuideDevice I/ODukeGalahadGraalIcedTeaJDK 7JDK 8JDK 8 UpdatesJDK 9JDK
      (…,
       21,
       22,
       23)JDK UpdatesJavaDoc.NextJigsawKonaKullaLambdaLanaiLeydenLilliputLocale EnhancementLoomMemory Model UpdateMetropolisMission ControlMulti-Language VMNashornNew I/OOpenJFXPanamaPenrosePort: AArch32Port: AArch64Port: BSDPort: HaikuPort: Mac OS XPort: MIPSPort: MobilePort: PowerPC/AIXPort: RISC-VPort: s390xPortolaSCTPShenandoahSkaraSumatraTiered AttributionTsanType AnnotationsValhallaVeronaVisualVMWakefieldZeroZGC

        © 2024 Oracle Corporation and/or its affiliates
        Terms of Use
        ·
        
            License: GPLv2
        · Privacy
        · Trademarks
