TLS ALPN Update

[Bradford Wetmore]

On 10/6/2015 7:42 AM, David M. Lloyd wrote:
> I didn't reply on this last week, but this looks workable to me.  Thanks!

Thanks to you guys for all the discussion!

During the architectural review, it was pointed out that the 
SSLParameters.setApplicationProtocols() API proposal with the 
server-side single array element restriction (i.e. a pre-chosen ALPN 
value) was unnecessarily limiting, and that we could achieve exactly the 
same result by removing the single element restriction.

For the advanced application cases like those that David/Simone/H2 are 
concerned about, you still have full control over your environment 
configuration and eventual ALPN selection.  Nothing has changed from 
earlier:

     1.  "SSLExplore" the ClientHello

     2.  obtain specialized SSLContext (if desired)

     3.  set the enabled protocols, enable/order the ciphersuites, etc.

     4.  select/set the *single* ALPN value

     5.  start the handshake

     6.  X509KeyManagers can look at the selected ALPN value
         mid-handshake using
         SSLSocket/SSLEngine.getHandshakeApplicationProtocol().

However, for less-restrictive situations or cases that don't require any 
connection setup, we follow the ordering language in RFC 7301/3.2:

    It is expected that a server will have a list of protocols that it
    supports, in preference order, and will only select a protocol if the
    client supports it.  In that case, the server SHOULD select the most
    highly preferred protocol that it supports and that is also
    advertised by the client.

The JSSE implementation is just a simple loop in the server side to 
select the ALPN value if both sides have values set.  Meaning:

     select TLS protocol
     select alpn value  (loop using server's order)
     select ciphersuite

Changes to the APIs:

SSLParameters.setApplicationProtocols():  Removed 
"no_application_protocol" as a reserved string, and removed the first 
element restriction.

Updated ServerHandshaker as per above.

Return value on 
SSLSocket/SSLEngine.getApplicationProtocol()/getHandshakeApplicationProtocol() 
is a tri-state:  null (not set yet), empty string ("" if no ALPN value 
is set), or non-empty string (if ALPN was negotiated).

wordsmithing/cleanups


We have done successful testing with our primary internal consumer:

https://bugs.openjdk.java.net/browse/JDK-8042950
JEP 110: HTTP/2.

Vinnie will be publishing a full webrev of the API and implementation in 
the next day or so.

Thanks again for everyone's comments and feedback during this process. 
Except for any bugs found in this webrev, this is what we expect for the 
initial JEP integration for Feature Complete next week.

Cheers,

Brad