[9] RFR 8170282: Enable ALPN parameters to be supplied during the TLS handshake

[Bradford Wetmore]

Hi,

Vinnie wrote:
 > We understood when we examined these issues last year that the
 > existing ALPN API would be sufficient. However it transpired,
 > following HTTP2 server implementation efforts, that a particular
 > use-case was difficult to address without sacrificing performance.

A few more details.

The discussion/decisions we had last year ended with requiring servers 
to inspect ClientHellos for the client's max TLS 
protocol/ciphersuites/SNI/ALPNs/etc, and then do any necessary 
configuration before actually starting the SSL/TLS/DTLS handshake on the 
server side.  That included enabling specific SSL/TLS/DTLS protocols, 
ordering the ciphersuites (calling 
SSLParameters.setUseCipherSuitesOrder()) and ordering the ALPN values. 
If it turned out that the resulting selected combination was incorrect, 
and if you were using a SSLEngine, you could throw away the outbound 
handshake bytes and retry the same ClientHello with a completely new 
SSLEngine that is configured differently.  Very awkward and would 
duplicate a lot of JSSE code in the application.  And unfortunately, 
SSLSocket doesn't allow for intercept/retry, you'd have to retry using a 
brand new connection.

The approach was ok at the time, but the Servlet folks really had a hard 
time when it came to actually using the API.  This came up in the 
discussion last June, and it's been something we've been wanting to 
address for JDK 9.

You can use the existing API as before, or if you want to examine the 
SSLEngine/SSLSocket mid-handshake, you can use the new one.

Thanks,

Brad


On 12/8/2016 4:29 PM, Vincent Ryan wrote:
> We understood when we examined these issues last year that the existing ALPN API would be sufficient.
> However it transpired, following HTTP2 server implementation efforts, that a particular use-case was
> difficult to address without sacrificing performance.
>
> This new API fixes that specific problem and the existing API is still available for the common case.
>
>
>> On 8 Dec 2016, at 23:13, David M. Lloyd <david.lloyd at redhat.com> wrote:
>>
>> On 12/08/2016 04:18 PM, Vincent Ryan wrote:
>>> The Java Servlet Expect Group reported that they have identified a specific HTTP2 server use-case that cannot
>>> be easily addressed using the existing ALPN APIs.
>>>
>>> This changeset fixes that problem. It supports a new callback mechanism to allow TLS server applications
>>> to set an application protocol during the TLS handshake. Specifically it allows the cipher suite chosen by the
>>> TLS protocol implementation to be examined by the TLS server application before it sets the application protocol.
>>> Additional TLS parameters are also available for inspection in the callback function.
>>>
>>> This new mechanism is available only to TLS server applications. TLS clients will continue to use the existing ALPN APIs.
>>
>> Wasn't the entire point of the chosen ALPN solution to make this kind of thing unnecessary?
>>
>> --
>> - DML
>