Re: New Version Notification for draft-thomson-http-replay-00.txt

Hi Ben,

On Thu, Jul 20, 2017 at 01:12:23PM -0500, Benjamin Kaduk wrote:
> On 07/20/2017 03:22 AM, Willy Tarreau wrote:
> > On Thu, Jul 20, 2017 at 09:59:39AM +0200, Martin Thomson wrote:
> >> On 20 July 2017 at 06:25, Willy Tarreau <> wrote:
> >>>>      * There is no special API to handle 0-rtt data by the TLS terminator, i.e. it is treated as a part of the same 1-rtt stream of data
> >>> Does such an implementation really exist ? I mean, for openssl, it's clearly
> >>> different :
> >> There's a split in the community on this point.  NSS merges the
> >> streams and 0-RTT reads and writes are not different from other reads
> >> and writes.
> > OK then I agree it's important to take care of this. One could say that
> > NSS transparently merging safe and unsafe data could cause trouble over
> > the long term and should possibly be adapted, but I don't know if that's
> > still possible.
> >
> >> I think that
> >> we should take the conservative approach here.
> > I agree on being conservative, which is also why I'm trying to check if
> > instead we could suggest not to implement it if the underlying layer
> > doesn't provide the necessary guarantees regarding received data. Do you
> > have contacts with the people working on NSS to know if that would be
> > something making sense for them, based on this example ?
> >
> The debate in the TLS WG over the question of needing separate APIs for
> a (potentially) ideologically separate data stream was ... quite
> heated.  So I was hoping to not reopen it here, given that we seem to
> have ended up at a consensus that it is possible to reason correctly and
> obtain correct results using either philosophical picture.
> Perhaps there would only need to be a new API for "did any data on this
> stream arrive as early data" (in addition to the "is the handshake
> finished" API already known about).

I'm fine with not reopening the debate, but at least we need to know what
grounds we're basing our design on. I understood during discussions at the
workshop that if the server receives the final handshake, it's a guarantee
that the client is the one we expect. But your example shows that it's not
sufficient to distinguish between really safe data and possibly replayed
ones (though my understanding is that the request could only be replayed
once, on the originally established connection).

If we push the concept a bit further, the issue is more widely related to
retries in general, because the same principle could be used to force a
client to retry upon any timeout by holding on its data. Even a plain
regular HTTPS request (you just have to hold the last part containing
the request, delay it for a while and wait for the client to retry, or
even the user to press F5).

Thus what I'm seeing is that the root of the problem is not at all related
to the way we map HTTP on top of TLS, but to the fact that whenever there
is a possibility of retry, there can be a duplicate request. And in fact
it's a well known problem for those of us having to implement persistent
connections to servers.

The draft suggests that the client may only retry after seeing the 4NN
status code, it doesn't suggest it's allowed before. The intercepting
proxy trying to replay the request in your case will not be able to
deliver this 4NN status code as it would require to spoof the server's
connection. So in such a case there's no reason for the client to retry.

Probably that we should make it clearer in the draft that the client must
not retry on other situations ? But then I fear that we'd be walking on
the feet of existing implementations.

Your attack should probably be documented as an example of how/why blind
retries can be dangerous though, in case some implementers would like to
go too far.


Received on Friday, 21 July 2017 07:08:28 UTC