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