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.bor...@gmail.com>: > Hi, > > On Mon, Nov 10, 2014 at 2:07 PM, Florian Weimer <fwei...@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 ! >
