TLS ALPN Proposal v3

[Simone Bordet]

Hi,

On Thu, Jul 9, 2015 at 1:42 AM, Bradford Wetmore
<bradford.wetmore at oracle.com> wrote:
> SSLParameters is a configuration class which is used to configure
> SSLSockets/SSLEngines.  SSLSession/ExtendedSSLSession is a class which holds
> negotiated Session values.  getReceivedApplicationProtocols() represents the
> Application Protocol values received from the peer, thus belongs in the
> SSLSession.

I suggest to rename

ExtendedSSLSession.getRequestedApplicationProtocols()

to

ExtendedSSLSession.getPeerApplicationProtocols()

The protocols are not really "requested", they are more "offered", but
IIUC the reason to add "Requested" to this method is to distinguish it
from SSLParameters.getApplicationProtocols() which returns the local
protocols, and in that spirit I think "Peer" is better for
ExtendedSSLSession.

> Xuelei/Simone wrote:
>>> Per my understanding, application protocol should be negotiated before
>>> cipher suite and protocol version negotiated.
>>
>> This is not possible for HTTP/2.
>> Application protocol negotiation MUST happen *after* the TLS protocol
>> and the TLS cipher are negotiated.
>
> Yes, that's my understanding as well.

Well, to be precise, either the application protocol is negotiated
after the cipher (and you need cipher sorting to influence the cipher
selection towards the application protocol you would like to choose),
or it must happen at the same time - that is, cipher and application
protocol must be chosen at the same time - but this implies that the
action of choosing that tuple may be invoked multiple times with the
current OpenJDK implementation.

Note that I don't know if the fact that cipher selection is an
iterative process is an OpenJDK implementation detail.
If other implementations are not iterative, then perhaps they have a
single moment where the tuple is chosen.

I support Xuelei in that you should ask confirmation to the HTTP/2 editor.
Also, remember that Firefox, Chrome, OpenSSL, nghttp2, etc. are all
open source and their code is available to verify the behavior.

> IIUC, the HTTP/2 blacklist is just strongly recommended ("...SHOULD NOT use
> any of the cipher suites...black list"), but not required.  Such potential
> peers must also support such a configuration, but in general, it will not.
> See section 9.2.2.  I think it's still considered compliant to the spec tho.

>From experience, if a server breaks this SHOULD NOT, it won't work
with any browser.
We had our share of pain trying to figure out interoperability with
browsers for Jetty :)
Sure, it's a SHOULD NOT, but it's like a MUST NOT if you want a
browser to talk to a Java server (or a Java client to talk to a
current HTTP/2 server).

> Simone wrote two different ways to do selection:
>
>> 1) ... so that TLS protocol, cipher (possibly the alias too) and
>> application protocol are chosen together, or
>> 2) we separate the TLS protocol and
>> cipher negotiation (and alias) in one step, and we perform application
>> protocol selection afterwards.
>
> Rather than completely redo the JSSE selection mechanism with the
> (version/ciphersuite/ALPN)-tuple idea (which would be a much more involved
> API and behavior change), I think the more straightforward solution (2) is
> better.

That's what we do in Jetty's ALPN implementation too.
Be aware that it rules out some possibility such as those mentioned by
Michael from RFC 7301.

>> Also, it is critical to detail how the mechanism work.
>>
>> Example implementations for SSLFunction would be great to have: the
>> typical HTTP/2 case is to select the application protocol based on the
>> TLS protocol and the already negotiated cipher.
>
> I have a "working" test example which shows how the ALPN APIs can be used
> for HTTP/2 clients and servers. It is a minor configuration tweak to the
> jdk/test/javax/net/ssl/templates/SSLEngineTemplate.java test that we use as
> the basis for JSSE SSLEngine testing.

Do you have a Java 9 server that can negotiate h2 with current browsers ?

> http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/SSLEngineAlpnHttp2.java.html
>
> See the configuration in createSSLEngines() around line 265 and 280.
>
>
> http://cr.openjdk.java.net/~wetmore/8051498/webrev.04/test/javax/net/ssl/ALPN/Http2ApplicationSelector.java.html
>
> Note the HTTP/2 blacklist and reordering code.
>
> The code is not actually "working" yet (haven't merged API/impl repos yet),
> but shows how to configure/use this API.

Just a reminder that the cipher blacklist is only valid for TLS 1.2.
For example, if the negotiated TLS protocol is 1.3, there is no need
to look at the ciphers (nor to sort them).

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