TLS extensions API, ALPN and HTTP 2.0

[Simone Bordet]

Hi,

On Sat, Sep 27, 2014 at 4:23 AM, Xuelei Fan <xuelei.fan at 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.