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.ll...@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
