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

[David M. Lloyd]

On 12/08/2016 07:34 PM, Bradford Wetmore wrote:
> 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,

How could it turn out to be incorrect, when you know in advance what 
credentials you have, what cipher suites are available, and what 
protocols support which cipher suites?  I'm just curious because I'm 
pretty sure we haven't encountered this (I'll ask our web server folks 
to be sure though).  Also I'd hate to see a worst-case situation where a 
this API was introduced (which is very reminiscent of ideas which were 
rejected for good reasons), and it turns out that in the end it's not 
quite sufficient after all, leaving a bit of dead code around.

I'm just wondering in case there are edge cases that we have not 
encountered but are lurking in a dark corner, waiting to surprise us later.

> 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
>>

-- 
- DML