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