A fully fledged TLS Extensions API ?

[Bernd Eckenfels]

Hello,

the question is, what is a extension API actually helping with: the JSSE
implementation is slow to adopt to typical advances in TLS browser
"wars". While this is not so bad as nobody implements a Web Browser in
Java anyway, it does make it harder for server vendors to offer a full
stack (without native libraries or reverse proxies).

Having an API to handle extensions could help with this a bit, however
a lot of the extensions cannot be bolted on, they alter the handshake
sequence, introduce new messages or alter interpretatrion of existing
enums. So while ALPN can be handled pretty easily, it would be harder
for things like eliptic_curves or supported_signatures or SRP (or Poly
authenticator) - or TLS_FALLBACK_SCSV (or simple things like rate
limiting the renegotiations).

The other question is, if advances in SSL/TLS protocol really need to
be bound with major java versions. It would do the world a favor to
have a backport of a system property allowing TLS1.2 to be used by
default. Having the JSSE implementation beeing its own sub project
under the openjdk could help with that. Especially if providers become
more plugable. And optimizations like intrinsic are not bound to the
providers, but to the actual primitive needed (like AES GCM).

Gruss
Bernd

Am Mon, 10 Nov 2014 14:28:44 +0100
schrieb Simone Bordet <simone.bordet at gmail.com>:

> Hi,
> 
> On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer <fweimer at redhat.com>
> wrote:
> > On 11/07/2014 02:06 PM, Simone Bordet wrote:
> >
> >> This email is about the idea to introduce in JDK 9 a fully fledged
> >> TLS Extensions API.
> >>
> >> Adding ALPN [0] support to JDK 9 requires, differently from other
> >> TLS extensions, to provide application code that will be run in the
> >> context of the TLS implementation, rather than just values such as
> >> booleans or strings.
> >
> >
> > That's going to be interesting if you need to support non-blocking
> > operation for use with SSLEngine.
> 
> In the case where you have to load the configuration from a place
> where it may take a lot of time, you can easily change the ALPN API to
> something like:
> 
> For the client:
> void selected(String protocol, CompletableFuture<Void> callback)
> 
> For the server:
> void select(List<String> protocols, CompletableFuture<String>
> callback)
> 
> and when you're done call callback.complete() or
> callback.completeExceptionally().
> 
> This would mean that the TLS implementation has to wait for those
> callbacks to be completed before proceeding.
> 
> On one side, having application code to complete the callbacks is, in
> our experience, error prone (i.e. applications forget it)
> On the other side, applications that make use of this API are
> typically on the implementer side rather than on the developer side
> (here I mean people that implement a server, rather than a developer
> of a webapp), so I guess a callback, albeit more complex, may give
> implementers more room for different implementations.
> 
> >> IMHO this chance can be lifted to provide a full TLS Extensions
> >> API.
> >
> > I don't think this is possible because TLS extensions can alter the
> > TLS handshake, result in additional messages being exchanged, and
> > generally alter the protocol in unforeseeable ways.  On top of
> > that, the concrete TLS implementation is not fixed, it can be
> > swapped out, so tying the extension API to the existing OpenJDK
> > internals will not work for everyone.
> 
> Can you expand what you mean here ?
> If a TLS extensions API is provided by JDK 9, would it not be
> implemented by providers like they do with the other APIs they have to
> implement to be a compliant provider ?
> It's a little more effort for providers, but with a public API should
> be implementable by any provider and an application would be portable
> across providers.
> 
> Thanks !
>