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. > 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 ! -- Simone Bordet http://bordet.blogspot.com --- Finally, no matter how good the architecture and design are, to deliver bug-free software with optimal performance and reliability, the implementation technique must be flawless. Victoria Livschitz
