跳到主要内容

JEP 114: TLS Server Name Indication (SNI) Extension

Summary​

Add support for the TLS Server Name Indication (SNI) Extension to allow more flexible secure virtual hosting and virtual-machine infrastructure based on SSL/TLS protocols.

Motivation​

Because of limitations of the TLS protocols, without the SNI extension an HTTPS server cannot be hosted in a virtual hosting infrastructure and virtual machine infrastructure where multiple domains share the same IP address. This becomes even more of a problem in the age of cloud computing.

SunJSSE has enabled SNI extension in client by default from JDK 7. We need to support the SNI extension in server side in JDK 8, to support virtual hosting and the cloud computing market.

Nearly all the major browsers support the SNI extension (from Wikipedia):

  • Internet Explorer 7 (Vista or higher, not XP) or later
  • Mozilla Firefox 2.0 or later
  • Opera 8.0 or later (the TLS 1.1 protocol must be enabled)
  • Opera Mobile at least version 10.1 beta on Android
  • Google Chrome (Vista or higher. XP on Chrome 6 or newer OS X 10.5.7 or higher on Chrome 5.0.342.1 or newer)
  • Safari 2.1 or later (Mac OS X 10.5.6 or higher and Windows Vista or higher)
  • MobileSafar in Apple iOS 4.0 or later
  • Windows Phone 7
  • Maemo

The following web servers support the SNI extension (from Wikipedia):

  • Apache 2.2.12 or later using mod_ssl (or alternatively with experimental mod_gnutls)
  • Cherokee if compiled with TLS support
  • Lighttpd 1.4.x and 1.5.x
  • Nginx

Description​

  1. Define interfaces to choose the specific key manager and trust manager for a specific server name indication.

    For virtual hosting infrastructure, i.e., multiple servers hosted in the same platform with the same IP address and different hostname, different servers should use different key managers and trust managers.

  2. Add the ability to delegate the connection to a virtual machine according to a specific server name indication.

    For virtual machine infrastructure, i.e., different servers hosted in different virtual machine with different hopstnames but with the same host IP address, the host should be able to delegate the SSL/TLS connection to the target virtual machine according to the specific server name indication.

Alternatives​

In order to solve the TLS problems in a Java computing environment, many ISPs have to assign a new IP address individually for each TLS/HTTPS server, or switch to use other TLS implementations as the proxy.

Testing​

  1. Need to verify that the new interfaces behave as expected.
  2. Need to verify that the implementation doesn't break backward compatibility in unexpected ways.
  3. Need to verify that the implementation doesn't bring new interoperability issues in unexpected ways.
  4. Need to verify that there no significant performance impact, even the server works in delegation mode to support virtual machines.

Impact​

  • JCP: no impact on JCP
  • Other JDK components: no impact on other JDK components
  • Compatibility: minimal
  • Security: no impact on security
  • Portability: limit impact on portability
  • User Interface: no graphic user interface
  • Documentation: need to doc the new interfaces
  • Internationalization: minimal impact, likely to add new error messages
  • Localization: minimal impact, likely to add new error messages
  • Legal: no legal issue
  • Other: no known other impact