Hi William! On Wed, Sep 09, 2020 at 12:02:03PM +0200, William Dauchy wrote: > On Wed, Sep 9, 2020 at 10:48 AM William Dauchy <wdau...@gmail.com> wrote: > > I'm trying to understand `ssl_fc_has_early` fetcher behavior as I'm > > unable to find a single request where it returns 1. > > (sorry, forgot to mention, all of these tests were done on v2.2.x)
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. Hoping this helps, Willy
