Hi, On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd <[email protected]> wrote: > Do you know of a Java TLS implementation that has APIs like this already? I > am also interested in this for the ability to implement authentication > mechanisms (GSSAPI and SASL) that rely on channel binding, so I would like > to see such an API materialize as well.
I posted a while back such APIs from 3rd party JSSE implementations: http://mail.openjdk.java.net/pipermail/security-dev/2014-August/011014.html (at the end). The problem that has been raised is that if you offer a generic TLS extensions API, then the extension may have a semantic that it's not implemented. Imagine this TLS extensions API already existed, to add extensions to SSLEngine. Now, ALPN comes along as a new TLS extension. An application could create their own ALPNExtension subclass (extending a standard one provided by the TLS extensions API), and add it to the ClientHello. But there is no code in the JDK that calls the application, asking (on the server) to select one of the protocols, for then send back the chosen protocol to the client. This could be solved by a callback API at the moment the ClientHello is received by the server (and the ServerHello by the client), so the application can examine the ALPN protocols. The NPN extension was doing something even more complicated, creating an additional TLS message that needed to be sent at the right time. It may be that a TLS extensions API (to add/remove/query TLS extensions) *and* a callback API to analyze "hello" messages when they are received is enough to cover a lot of cases, perhaps even all currently existing ones. I asked for feedback some time ago about the status of the ALPN implementation; would be great if the security team could update the current status. -- 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
