Hi, On Sat, Sep 27, 2014 at 4:23 AM, Xuelei Fan <xuelei....@oracle.com> wrote: > I used to think it is better to have SSLExplorer as a public utility but > not a part of JSSE, because the extract is not involved in TLS > transactions.
I am not sure I understand this. Can you expand ? A number of TLS Extensions are designed to be consumed by applications: SNI, ALPN, NPN, renegotiation, etc. Eventually these features crop up in the API (e.g. SSLParameters.setServerNames()), or even applications need to have control on whether these extensions have to be added or not (e.g. ALPN) in a dynamic way that cannot be expressed via system properties. So I would rather prefer a full fledged extensions API exposed by the JDK (also to cope with future extensions). > Please let me know if the SSLExplorer cannot meet your > requirements. Definitely not :) It has too many assumptions on how many bytes have been read, it does not work for async reads that may read only part of TLS frames, it parses again the TLS bytes, etc. Sure we can do all that in the application in order to fullfill SSLExplorer requirements, but I really hope that is not the way to solve this problem. Every application out there would have its own tweaked version of SSLExplorer, tweaks may introduce vulnerabilities, etc. The whole point is to have a standard API to rely on. Internally OpenJDK already does the parsing of the SNI extension, so I see no point in forcing application to do it again: just expose what's already been read. I think we should go the extra mile and just expose in the right way what's already in the JDK: there already is a ServerNameExtension class, hopefully there will be NPNExtension, ALPNExtension classes, etc, all part of the same API, which is available to applications. As I said before, it seems that ALPN is only one piece required to support HTTP/2. The HTTP/2 spec editors are being adamant on cipher requirements, so for example an application would need to know the type of cipher as defined by RFC 5246 section 6.2.3: something like cipher.isStream(), cipher.isBlock(), etc, along with whether the cipher supports forward secrecy (currently ephemeral key exchange). I will try to come up with the list of necessary things for HTTP/2, but I would appreciate any thought on introducing a full fledged TLS extensions API available to applications to the JDK. I'd like to know in advance if this is not possible at all. Thanks ! -- Simone Bordet ---- http://cometd.org http://webtide.com http://intalio.com Developer advice, training, services and support from the Jetty & CometD experts. Intalio, the modern way to build business applications.
