Hi, On Wed, Sep 17, 2014 at 5:41 PM, Michael McMahon <michael.x.mcma...@oracle.com> wrote: > No, I was thinking something like the following: > > foo.domain.com:443 supports two different server applications - "h2" > and something else (say some proprietary application "fooapp"). > They require two different certificates and we want > TLS to choose the right cert for the right application. > > Or it could be a client trying to connect to either of the two applications > above on port 443, and where the client wishes to use two different > client certs. > > It is analogous to SNI because the choice of the cert has to occur > during the TLS handshake, which is why it needs to be built into TLS. > But, I assume that SNI is able to choose a cert based on the domain > name and doesn't need any additional help from the API.
SNI is a property of the connection, AFAIK, therefore clients that want to connect to the same server with different SNIs would need to open different connections, right ? If there are different connections, then ALPN can be negotiated differently on each connection. For the server to differentiate between those 2 connections he would need the SNI information, which I don't think it's currently available in JDK 8, right ? That is why I was proposing for a review of the whole TLS extensions API: I would like a server to be able to do something like: TLSExtension sni = sslEngine.findTLSExtension(SNITLSExtension.class) rather than http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/samples/sni/SSLExplorer.java (yuck :) -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
