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
