JEP 244: TLS Application-Layer Protocol Negotiation Extension
Simone Bordet
simone.bordet at gmail.com
Mon Apr 13 16:44:12 UTC 2015
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.
--
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
More information about the security-dev
mailing list