JEP 114: TLS Server Name Indication (SNI) Extension

AuthorXuelei Fan
OwnerXue-Lei Fan
Created2011/01/24 20:00
Updated2014/07/10 20:54
TypeFeature
StatusCompleted
Componentsecurity-libs
ScopeSE
Discussionsecurity dash dev at openjdk dot java dot net
EffortM
DurationM
Priority4
Endorsed byBrian Goetz
Release8
Issue8046104

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