TLS ALPN Proposal v6

[Bradford Wetmore]

You guys (David/Simone/Bernd/Jason) are more on the front lines in 
server development and how functional this API will be, so I'll trust 
your judgement here.  If you are ok with:

1. potentially being blind during renegotiations in the existing 
TLSv1/v1.1/v1.2, and,

2. not having an SSLExplorer as part of the JDK (i.e. you parsing the 
ClientHellos ala SSLExplorer),

3. requiring all ALPN logic be in the application and none in the JDK,

I'm willing to go with this approach. It doesn't seem optimal for what I 
would call casual users, but it does solve the ugly issues with the 
matches() API.

(BTW, I did consider adding a 
ClientHelloCallback/ClientHello/ServerHelloCallback/ServerHello class 
that would handle callbacks, but that was getting complicated also.)

For current renegotiations, the big use case is adding client 
authentication, so it seems likely that the same ciphersuite will be 
offered/chosen, so it's likely moot.


For the existing URL code, do you think we need:

1. to provide a "https.alpn" System Property for the existing 
URLConnections?

2. a getApplicationProtocol() for HttpsURLConnection?

Michael (net-dev) says H2 will not be backported into the URL mechanism 
and doesn't see a need for it yet, so I'm inclined to say no.

More inline:

On 9/29/2015 8:07 AM, David M. Lloyd wrote:
> Hi Brad, thanks for replying; comments are inline:
> On 09/28/2015 08:40 PM, Bradford Wetmore wrote:
>> 1. Only the initial ClientHellos are parsable.
>> ===============================================
>> The biggest problem I have with an Explorer-based design is that only
>> the initial ClientHello on a connection is passed in the clear.
>> Subsequent negotiations on this connection will be completely missed, as
>> the ClientHellos are now encrypted.
>>
>> This seems like a deal breaker for me.
>
> You are right, I cannot come up with a good solution for this, so that
> might mean the idea is shot - *however* - I would point out that the
> latest draft of TLS 1.3 [1] completely kills off the capability of the
> client to renegotiate a connection, meaning that this will no longer be
> possible anyway, and given it's a 1% kind of use case, that might be
> enough to let it slide.  Combine this with what I consider to be the
> unlikelihood of this working with HTTP/2.0, and I would feel very safe
> assuming that nobody will ever actually do this.

Thanks for pointing this out, I thought PSK+tickets were a replacement 
for a renegotiation (Section 6.2.3), but it's apparently only for 
session resumption.

BTW, the WG is up to a Sept 29, 2015 version (draft-09).

     [1] https://tlswg.github.io/tls13-spec/

> I would also note that, as you state later on, it would be possible to
> combine this solution with any other solution (including the proposed
> one) to cover both cases.  And given that this is still (in my
> estimation) a "99%" solution, in my opinion it is still a viable
> candidate for adding this functionality to Java 8 as a first pass or
> stopgap as I described in my emails, particularly if the method(s) to
> establish/query the protocol names are a strict subset of the proposed
> Java 9 API (given that we cannot really overhaul the Java SE 8 API at
> this point).
>
>> [...]
>> 2.  "SSLExplorer" or something similar is needed.
>> =================================================
>> This approach depends on "examining SSLClientHello"s, but there isn't a
>> class for this other than some sample code from a previous attempt.  I
>> am assuming that this approach would make such an external API a
>> necessity?  Being able to parse possible ClientHello formats is not a
>> straightforward/easy job.  This will add a fair amount of complexity,
>> and likely not an easy job in the remaining few weeks.  It could be
>> added later for JDK 10 but that means apps would likely need to roll
>> their own for 9.
>
> And 8, yes, you definitely would need to roll your own, though Xuelei
> Fan already has a nice example up on his blog that was built for SNI
> (but uses the same principle).

If you are referring to:

 
http://simsmi.blogspot.com/2014/01/jep-114-tls-sni-extension-virtual.html

This is just describing the general approach for the sample 
SSLExplorer/SSLCapabilities code in the JSSE Reference Guide.  The 
actual code can be found here:

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

My hope is to expand it to include parsing the ciphersuites and ALPN 
extensions.  I've moved/added some helper functions from 
ApplicationProtocol to StandardConstants.

>  If it were me, I wouldn't even bother
> adding it even in JDK 10, since (a) it applies only to the server side
> and (b) there are a plethora of third-party server-side network I/O and
> security libraries which are natural candidates to host this type of logic.

Ok.

>> 3.  "no_application_protocol"
>> =============================
>> If the server doesn't support the protocols that the client advertises,
>> the "no_application_protocol" must be thrown.   We could add a
>> "no_application_protocol" protocol String that would flag such a
>> condition internally.
>
> Sure, though if you use the same method on both the client and server to
> specify the matched protocol, then the method necessarily accepts an
> array, in which case a null/unset could mean "no ALPN response" and an
> empty array could mean "no acceptable protocols".  But yeah I agree
> otherwise.

I meant if this value is set, then when the ALPN extensions are 
selected, it will send the alert to the peer and return an Exception to 
the local code.

The latest webrev is at:

     http://cr.openjdk.java.net/~wetmore/8051498/webrev.16

This will be the final version as far as major architectural design 
goes, but minor things like parameter types/wording can still be tweaked.

Major changes:

1.  ApplicationProtocols is gone.  The H2 black list and comparator were 
moved to StandardConstants.

2.  StandardConstants.  Strings for "h2" and "http/1.1" are back.  And 
now that you are parsing the raw network bytes, I added a convenience 
mapping between the two byte ciphersuite IANA-assigned value and the 
Java Standard Name.

3.  SSLParameter (set/get) are moved to SSLSocket/SSLEngine.  Even 
though these could go into SSLParameters, this change makes backporting 
much easier.  The helper code simply has to reflectively look for the 
four methods in the implementation classes, and call if they are there.

Otherwise, there would have to be reflection both in the user code 
(above) and implementation (to see if the passed SSLParameters had the 
new methods via a subclass).

Thanks,

Brad