JEP 244: TLS Application-Layer Protocol Negotiation Extension

[Thomas Lußnig]

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.lloyd at 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.
>