Hi, On Mon, Nov 10, 2014 at 10:36 PM, Bernd Eckenfels <e...@zusammenkunft.net> wrote: > 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).
Well, JEP 110 (http://openjdk.java.net/jeps/110) is about a HTTP client that supports h2. I think it's not too far-fetched to expect jfx/swing widgets, JAX-RS clients, etc. to support h2 in a close future, so I would not rule out h2 support for clients. ALPN would be a prerequisite for h2, since unlikely servers will implement h2 in the clear. > 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). For example for the NPN extension to work, it requires collaboration with the TLS implementation to send a new TLS message at the right moment. A JDK 9 client application would be able to add the NPN extension via the API, but then the JDK would not be able to send the new message at the right time because NPN won't be implemented in JDK 9. There are several ways to handle these cases, but I agree that they may expose an overspecification of the API similar to that of the collections API: throw UnsupportedOperationException if you can't handle it (e.g. Iterator.remove()). Whether there is more advantage for applications to have the API and risk an UOE, or not having the API and be stuck, I don't know (and it's the reason for this email, to discuss it :) A declaration of the impact of an extension on the TLS protocol, akin to Spliterator.characteristics() may help. Some extensions have no impact and may be freely added, others require the TLS implementation cooperation. A couple more callbacks for [Client|Server]Hello received, for applications to interact with the extensions for SSLSocket (similar to HandshakeCompletedListener) would be needed too. Thanks ! -- 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