https://issues.apache.org/bugzilla/show_bug.cgi?id=57108

            Bug ID: 57108
           Summary: Implement multiple sslcontext SNI (server name
                    indication) dispatch
           Product: Tomcat Connectors
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common
          Assignee: dev@tomcat.apache.org
          Reporter: quartz...@yahoo.com

SSL/TLS defines a mechanism for virtual host names on the same ip/port to have
distinct server certs (and protocols, and else), avoiding the use of wildcard
certs.

With jdk8, a TLS server can prefetch the ClientHello's server name indication
(SNI) extension from the tcp accepted socket inputstream, then create an
sslsocket with the new SSLSocketFactory.createSocket(socket, inputstream,
autoclose) method (the the inputstream arg is just the replay of the prefetched
bytes).

Unfortunately, all socket factories come from a SSLContext already initialized
on keymanagers/trustmanagers on key/trust stores. Once a sslsocket is accepted
from an sslsocketfactory, the sslcontext/server cert is already chosen.

To implement this under tomcat, the SSL connectors must only accept tcp
connetions, detect the intended hostname, choose the proper sslcontext and then
forward to the sslsocketfactory to handshake correctly. This means defining
more than one keystore/truststore/params on the unique ssl connector.

One way to express this potentially large configuration would be to point to a
mapping file outside the server.xml, but it should be possible to inline this
data section too (some new tag element under the connector, perhaps a
collection).

Ultimately, the admin should be able to map a hostname to an sslcontext
descriptor (which is more than just keystore/truststore, but also versions,
protocols, etc...)

Backward compatibility is desirable, so the previous attributes would only be
assimilated as a single mapping of all hostnames. In fact, these mapping will
require a default when no hostname pattern matches, so it is probably good to
plan for a collection of sslcontext mappings plus 1 default sslcontext.

The jdk8 docs are giving complete examples on the prefectching mecanism and how
to use SNI.

http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#SNIExamples

Particularly the section "Working with Virtual Infrastructures".

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to