TLS extensions API, ALPN and HTTP 2.0

[Xuelei Fan]

> 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.

;-) Impossible is nothing.  Thanks for the list of necessary things.
Please let me know the requirements and the user scenarios if the list
is ready, especially these things that java cannot support.  Thanks for
that in advance.

>> 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?

SSLExplorer is only needed for virtual server dispatcher, for which the
virtual servers are not hosted in the same JVM.  SSLExplorer can be
easily implemented in application layer.  The virtual server dispatcher
is not really a part of SSL/TLS handshaking.  It just redirects the
stream to the right virtual server.  Application may have more effective
implementation than the sample SSLExplorer.  It's OK to me to have it in
JDK if customers really want to see it in JDK.

> 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'm not sure I understand this point.  SSLExplorer is expected to be
used in different circumstance than the SSL/TLS handshaking.  Please
read more scenarios in the JSSE reference guide:

http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#SNIExamples

Or would you mind describe the scenarios in details?

Thanks,
Xuelei

On 9/29/2014 5:30 PM, Simone Bordet wrote:
> 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 !
>