On Thu, Nov 30, 2017 at 03:32:20PM +0100, Emmanuel Hocdet wrote: > > > Le 30 nov. 2017 à 13:34, Olivier Houchard <ohouch...@haproxy.com> a écrit : > > > > Hi Emmanuel, > > > > On Thu, Nov 30, 2017 at 12:15:37PM +0100, Emmanuel Hocdet wrote: > >> Hi Olivier, > >> > >>> Le 29 nov. 2017 à 19:57, Olivier Houchard <ohouch...@haproxy.com> a écrit > >>> : > >>> > >>> On Mon, Nov 27, 2017 at 06:19:41PM +0100, Emmanuel Hocdet wrote: > >>>>> Maybe the best is to add a new flag per conn_stream, > >>>>> CS_FL_WAITING_FOR_HS or > >>>>> something, instead of relying on CO_FL_EARLY_DATA. > >>>>> I think I'm going to do something like that. > >>>> > >>>> I think it's a good idea, two different things to deal with one tag. > >>>> > >>>>> That still doesn't help with your problem with TCP mode, though. I > >>>>> still want > >>>>> the CO_FL_EARLY_DATA to be removed after the handshake, so that we don't > >>>>> add the "Early-Data: 1" header if it is not needed. But it just occured > >>>>> to me that I can easily fix that by adding the header, not only if > >>>>> CO_FL_EARLY_DATA is set, but if CO_FL_EARLY_SSL_HS or CO_FL_SSL_WAIT_HS > >>>>> is set. > >>>>> That way we will both be happy :) > >>>> > >>> > >>> So, this if my first cut at it. It basically does as I said. > >>> Only thing you may be unhappy with, I made the sample fetch > >>> ssl_fc_has_early > >>> return 0 if we had early data but the handshake happened, because the main > >>> use case is to know if there are early data and if they're a potential > >>> security risk. > >>> If you can give me a case where we have a need a sample fetch to know > >>> there > >>> were early data, even after the handshake, maybe we can introduce a new > >>> sample fetch, ssl_fc_has_insecure_early, or something ? > >>> > >> > >> In this case, i don’t understand the interest of ssl_fc_has_early. > >> > >> looking at the documentation > >> ssl_fc_has_early : boolean > >> Returns true if early data were sent, and the handshake didn't happen > >> yet. As > >> it has security implications, it is useful to be able to refuse those, or > >> wait until the handshake happened. > >> > >> ssl_fc_* can be used after the front connection at ssl level: handshake > >> will be finished at this time. > >> ssl_fc_has_early should be: returns true if early data were sent and > >> accepted in ssl level. (425 return is http level) > >> > >> What the description makes me think, and understand what you said, is that > >> it could be a « ssl_hs_has_early ». > >> I’m very interesting to have acl on hs negotiation, i don't know how to do > >> that now in haproxy. > >> > > > > No, sls_fc_has_early can be used before the handshake happened. If we > > received early data, the request will be treated before the handshake (and > > potentially the answer from the server will be sent before the handshake is > > done). So ssl_fc_has_early is there to be able to stop any "dangerous" > > request. > > > > My fault, i don’t read the doc of ssl_fc_has_early: as user it confused me on > the meaning > and usage. > What i mean is about the name of the prefix ssl_fc* ssl front connection. > All ssl_fc_* can be used in log-format because is valid after the end of HS. > ssl_fc_has_early is the first _fc_ with a different behavior and is not PoLA : > ssl_fc_has_early can be used in http mode but it can false report in > log-format, and is useless in tcp mode? but it’s ssl_fc_* ... > > Technically, with early HS, we have new informations who can changed after > the HS. > I think such informations deserves a new prefix for sample. ( ssl_fhs_* ?) > For exemple, it could be used for acl in early HS (of course in http mode and > perhaps one day in tcp mode). >
Oh ok you're right, I picked up fc without much thought, I wasn't sure what to use, and didn't bother ask, maybe indeed a new prefix would be wise. Regards, Olivier
