On 6/4/2015 8:19 PM, 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. > Why? Is it a spec of HTTP/2? It is a point I don't understand now. Please help with more details.
>> And the connection may be >> rerouted (even to different machines) for further operation. The >> requested application protocols list should be the only information for >> the selection of a suitable application protocol. > > Not sure what you exactly mean here, Here is an example to explain the "rerouting". For example, there a four entities, an TLS client, a router, an http/2 over TLS server, and an http/1.1 over TLS server. 1. the client request a connection to the http/2 server, the TCP connection is established between the client the router at first. 2. the router analysis the ClientHello message, and reroute the connection to the http/2 server. 3. the client and http/2 server negotiate the TLS connection, including the SSL protocol and cipher suite. The router should not be able to play man-in-the-middle negotiation if it does not know the server credentials. > but you can't pick the HTTP/2 > protocol unless you have the TLS protocol and TLS cipher available. > So *only* the list of protocol sent by the client is not enough for > HTTP/2, we would need additional contextual information. > See my question above. > What a HTTP/2 aware load balancer written in Java that offloads TLS > would need to do is to negotiate the TLS protocol, negotiate the TLS > cipher, *then* negotiate the application protocol (whether "h2" or > "http/1.1"), and with the last information pick a backend server, > typically forwarding clear text bytes to the backend. > See my question above. Thanks, Xuelei
