Hi, this could be an interface for such an Callback. It allow hello extensions as well as handshake extensions. If it would be really clean we would have an handler for: - NPN - ALPN - Channel ID - ZertificateSignature - OCSP-Stapling - ServerName - Session Ticket
The handler could be also used for handling: - TLS_FALLBACK_SCSV The current way is that all these extensions are in the sun Private package space and to make it even worse each extension is written in another way. Also i am missing an API defined way to extend the list in sun.security.ssl.CipherSuite. Gruß Thomas public interface HelloHandler { /** * Allow to add extesions to Server/Client Hello * based on the Client/Server hello */ public void handleHelloMessage(ClientHello clientHello, ServerHello serverHello); /** Allow to add new Handshake Messages based on * the Client/Server Hello */ public void sendHandshakeMessage(HandshakeOutStream handshakeOutStream, ClientHello clientHello, ServerHello serverHello); /** * define an order of the extensions */ Class<? extends HelloHandler > runBefore(); /** * define an order of the extensions */ Class<? extends HelloHandler > runAfter(); } > Hi, > > On Mon, Apr 13, 2015 at 6:22 PM, David M. Lloyd <david.ll...@redhat.com> > 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. >