Re: `ssl_fc_has_early` fetcher and 0rtt
> > That seems strange indeed but looking at the code that's what I'm > > seeing. Was your access to ssl_fc_has_early placed before or after the > > rule above ? If it's after it must indeed report false. fetcher is placed before the rule > > I seem to remember there was one but can't find it, so I may have been > > confused. With this said, it doesn't provide a big information since > > once the handshake is completed, it's exactly identical to a regular > > one. But it can be nice for statistics at least. > > > > Pretty sure the original version always returned 1 if there were early > data, but we changed it so that it would return 0 once the handshake was > done, as we thought it was more useful, that may be what you're thinking > about. Yes I indeed found the commit which changed the behaviour. In fact I probably mixed the true meaning of the definition in the doc and the old blog post about it which is vague. Now everything is clear. >From our point of view, it's interesting to check some behavioural changes we can make on the L4 layer (e.g. hash including source port or not). > That indeed tells me something. However I checked if CO_FL_EARLY_DATA > persists, and apparently we kill it very early once we have everything > so it's not as if we could trivially add a new sample fetch function to > report its past status. > > Also I seem to remember that we concluded that depending on the timing > and how data were aggregated and processed in the SSL lib, we couldn't > reliably report the use of early data if those were converted very early. At some point I was asking myself whether this could be done but simply to give a signal without any guarantee, but you seemed to conclude that it's not reliable enough to become a new fetcher. -- William
Re: `ssl_fc_has_early` fetcher and 0rtt
On Wed, Sep 09, 2020 at 05:43:08PM +0200, Olivier Houchard wrote: > > I seem to remember there was one but can't find it, so I may have been > > confused. With this said, it doesn't provide a big information since > > once the handshake is completed, it's exactly identical to a regular > > one. But it can be nice for statistics at least. > > > > Pretty sure the original version always returned 1 if there were early > data, but we changed it so that it would return 0 once the handshake was > done, as we thought it was more useful, that may be what you're thinking > about. That indeed tells me something. However I checked if CO_FL_EARLY_DATA persists, and apparently we kill it very early once we have everything so it's not as if we could trivially add a new sample fetch function to report its past status. Also I seem to remember that we concluded that depending on the timing and how data were aggregated and processed in the SSL lib, we couldn't reliably report the use of early data if those were converted very early. Willy
Re: `ssl_fc_has_early` fetcher and 0rtt
On Wed, Sep 09, 2020 at 05:35:28PM +0200, Willy Tarreau wrote: > On Wed, Sep 09, 2020 at 04:57:58PM +0200, William Dauchy wrote: > > > 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). > > That seems strange indeed but looking at the code that's what I'm > seeing. Was your access to ssl_fc_has_early placed before or after the > rule above ? If it's after it must indeed report false. > > > So maybe we can possibly work on an alternative fetcher to know > > whether this was a 0rtt request? Or is there another way? > > I seem to remember there was one but can't find it, so I may have been > confused. With this said, it doesn't provide a big information since > once the handshake is completed, it's exactly identical to a regular > one. But it can be nice for statistics at least. > Pretty sure the original version always returned 1 if there were early data, but we changed it so that it would return 0 once the handshake was done, as we thought it was more useful, that may be what you're thinking about. Olivier
Re: `ssl_fc_has_early` fetcher and 0rtt
On Wed, Sep 09, 2020 at 04:57:58PM +0200, William Dauchy wrote: > > 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). That seems strange indeed but looking at the code that's what I'm seeing. Was your access to ssl_fc_has_early placed before or after the rule above ? If it's after it must indeed report false. > So maybe we can possibly work on an alternative fetcher to know > whether this was a 0rtt request? Or is there another way? I seem to remember there was one but can't find it, so I may have been confused. With this said, it doesn't provide a big information since once the handshake is completed, it's exactly identical to a regular one. But it can be nice for statistics at least. Willy
Re: `ssl_fc_has_early` fetcher and 0rtt
Hello Willy, Thank you for your answer, On Wed, Sep 9, 2020 at 4:39 PM Willy Tarreau 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
Re: `ssl_fc_has_early` fetcher and 0rtt
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 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
Re: `ssl_fc_has_early` fetcher and 0rtt
On Wed, Sep 9, 2020 at 10:48 AM William Dauchy 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) -- William
