JEP 244: TLS Application-Layer Protocol Negotiation Extension

Thomas Lußnig openjdk at
Mon Apr 13 17:14:06 UTC 2015


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:
- Channel ID
- ZertificateSignature
- OCSP-Stapling
- ServerName
- Session Ticket

The handler could be also used for handling:

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

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> 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:
> (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.

More information about the security-dev mailing list