JEP 114: TLS Server Name Indication (SNI) Extension

AuthorXuelei Fan
OrganizationOracle
Created2011/1/24
Updated2013/1/14
TypeFeature
StateFunded
Componentcore/sec
ScopeSE
RFE7068321
Discussionsecurity dash dev at openjdk dot java dot net
Start2011/Q4
EffortM
DurationM
Endorsed-byBrian Goetz
Funded-byOracle
Release8
TargetM5

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):

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

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