Hello Willy, Thank you for your answer,
On Wed, Sep 9, 2020 at 4:39 PM Willy Tarreau <w...@1wt.eu> wrote: > If I remember well, the principle consists in detecting whether or not > the request was received using TLS early data (0-rtt) before the handshake > was completed. The problem is that early data may trivially be captured > and replayed, so you don't necessarily want to accept all of them, only > replay-safe requests. Typically a login page that is limited to 3 > attempts before blocking should not be allowed, but fetching a favicon > is totally safe. > > Once the handshake ends you'll know whether it was safe or not, so you > can actually decide to wait on this function to return false to indicate > that the request is complete and not replayed, or just use it to return > a "425 too early" response for certain sensitive resources. > > I think it's not easy to reproduce these tests, you need a high enough > latency between haproxy and the client so that the handshake is not > already completed when you evaluate the rule, and of course you need > to make sure the client sends using early data. I don't remember how > Olivier used to run his tests but I remember that it was a bit tricky, > so it's very possible that you never fall into the situation where you > can see the unvalidated early data yet. It means my understanding of this fetcher was wrong indeed. For me the protection was here: http-request wait-for-handshake if ! METH_GET and the fetcher here to log whether it was a 0rtt request or not. In reality, it means all our requests have completed the handshake when the rule is evaluated (which is surprising looking at the number we have). So maybe we can possibly work on an alternative fetcher to know whether this was a 0rtt request? Or is there another way? Thanks, -- William
