On Wed, 2015-11-11 at 18:39 +0000, Mike Bishop wrote: > A question for TLS implementation owners: During the discussion of > the TLS 1.2 portion of https://tools.ietf.org/html/draft-thomson-http > 2-client-certs-00, it was pointed out that HTTP/2 breaks a > simplification of the HTTP-TLS interface that some implementations > may have assumed. > > Since HTTP/1.1 only has one request per connection and that request > is waiting on the client certificate to be retrieved via > renegotiation, you can assume that the client will not send any > application data between the new ClientHello and sending the Finished > message. (“…it is expected that the negotiation will begin before no > more than a few records are received from the client.”) Likewise, > the server will not emit any application data between sending the > HelloRequest and sending its own Finished message. Since HTTP/2 will > have other requests being generated and served in parallel, this is > no longer the case. Per the TLS 1.2 spec, that’s permitted, but if > it’s not been done before, I’m afraid we may be hitting less-tested > code paths.
We may are also introducing a new attack surface by allowing application data during rehandshake and implementations cache the messages until the handshake is complete. There is an interesting part of the triple handshake attack which can take advantage of applications which cache application data during rehandshake. Quoting: https://www.secure-resumption.com/ "... Consequently, A cannot read or send messages on these connections any more. However, its prior [to rehandshake] messages on both connections may well be prefixed to the messages sent after renegotiation." So an attacker could ensure that his messages are prefixed to the next session if he simply sends his application data during rehandshake. That was not possible with most implementations until now. So we are hitting less-tested protocol paths as well, not only code paths. regards, Nikos _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
