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

Reply via email to