On 04/06/15 15:18, Simone Bordet wrote:
Hi,
On Thu, Jun 4, 2015 at 3:08 PM, Michael McMahon
<michael.x.mcma...@oracle.com> wrote:
On 04/06/15 13:19, Simone Bordet wrote:
Hi,
On Wed, Jun 3, 2015 at 8:23 AM, Xuelei Fan <xuelei....@oracle.com> wrote:
Per section 4, RFC 7301:
"... The
"application_layer_protocol_negotiation" ServerHello extension is
intended to be definitive for the connection (until the connection is
renegotiated) and is sent in plaintext to permit network elements to
provide differentiated service for the connection when the TCP or UDP
port number is not definitive for the application-layer protocol to
be used in the connection. By placing ownership of protocol
selection on the server, ALPN facilitates scenarios in which
certificate selection or connection rerouting may be based on the
negotiated protocol."
Per my understanding, application protocol should be negotiated before
cipher suite and protocol version negotiated.
This is not possible for HTTP/2.
Application protocol negotiation MUST happen *after* the TLS protocol
and the TLS cipher are negotiated.
What do you mean by "after"? As far as TLS is concerned, all of this
negotiation happens in one negotiation. The client proposes a list of
ciphers and application protocols. The server chooses a cipher
and application protocol and sends back its choices.
Currently, IIUC, the cipher selection is an iterative process where a
cipher is attempted until one is negotiated.
In this process, there is no looking at the application protocol.
Here we're trying to find a solution for ALPN, and either we 1) look
the application protocol in this iterative process (and therefore the
SSLFunction is invoked multiple times), so that TLS protocol, cipher
(possibly the alias too) and application protocol are chosen together,
at once (for each iteration); or 2) we separate the TLS protocol and
cipher negotiation (and alias) in one step, and we perform application
protocol selection afterwards.
The latter is how Jetty's ALPN works, and that's what I mean with *after*.
For HTTP/2 it won't work to pick the application protocol before the
cipher. Either at the same time, or after.
That is why I asked to specify how the mechanism worked.
Okay. I've been looking at it from the client point of view, and
as far as I understand it, all of the information is available to the client
at the right time.
The HTTP/2 RFC specifically warns against splitting this negotiation
with the example that a client could propose a mandatory TLS 1.2 cipher,
but which is black-listed by HTTP/2. If (internally) the server chooses that
cipher first,
without knowing the application protocol is going to be HTTP/2
then you end up with a non-compliant connection that will probably have
to be closed for reason of insufficient security.
If the server chooses a blacklisted cipher, and then "h2" as protocol,
it's a non compliant server.
Communication of clients with compliant (and properly configured)
servers is guaranteed if the application protocol is chosen after (or
at the same time of) the cipher.
If I understand you correctly, you are proposing to rework the
internal JDK code to perform TLS protocol, cipher, alias and
application protocol in one point, which is then possibly iterated
multiple times until a satisfactory tuple is selected ?
I am fine with this approach too, but I guess the API will be very
different from Jetty's ALPN and this current proposal (which is fine
as well - does not have to be similar to Jetty's).
I don't know enough about the TLS implementation to say how much work it is.
Thanks !
Actually, I'm not proposing anything at this stage. But, I wonder if
it might be simpler to just make all relevant information available
to the existing negotiation API, rather than splitting it into separate
calls
- Michael.
