Hi, On Fri, Sep 25, 2015 at 2:46 PM, David M. Lloyd <david.ll...@redhat.com> wrote: > Well, SNI already basically works this way, so it's not so great a stretch.
I don't follow ? SNI has APIs in JDK 8, you don't use SSLExplorer at all. Also, SNI is a client-to-server information only, while with ALPN you have to reply to the client, so you have to modify the ServerHello. I don't see how you can do this without support from the JDK via APIs ? > I imagine the client code simply specifying a list of protocols along with > today's list of cipher suites. > > The user-space server side logic would go like this: > > * Receive SSL ServerHello > * Examine the packet for ALPN and SNI information > * Read the list of cipher suites > * Evaluate > * Select an SSLContext based on protocol and/or server name > * Construct an SSLSocket or SSLEngine as appropriate > * Set a property on the SSLSocket/SSLEngine to indicate ALPN protocol name > * (optional) Change/sort the cipher suite list on the SSLSocket/SSLEngine as > appropriate > * Resume negotation by passing the ServerHello in to the SSLSocket/SSLEngine > as initial data > > It's not super elegant but it should work just as well as SNI works, and it > would cover 100% of use cases since the user has complete flexibility to > make a decision based on any combination of cipher suite selection, protocol > name, and host name, even potentially with the option to pretend that ALPN > wasn't recognized. Are you saying that every application has to write its own TLS parser ? Would not that be overkill and full of potential security issues if one does not get the implementation strictly correct ? Also, what if the JDK implementation refuses to use the cipher you chose along with the application protocol, for whatever reason ? Thanks ! -- 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
