On 9/18/21 10:36 AM, Alex Rousskov wrote: > On 9/17/21 7:10 PM, Amos Jeffries wrote: >> On 18/09/21 8:14 am, Alex Rousskov wrote: >>> On 9/17/21 3:29 PM, Andreas Weigel wrote: >>> >>>> If splicing at step3, however, hostHeaderVerify is not called again with >>>> the SNI >>> >>> I assume that the above statement would still be true if I remove the >>> word "again" from it. This is how I interpreted it (i.e. >>> hostHeaderVerify() is called once with the IP address and never with >>> SNI). >>> >>> There are other ways to interpret that statement (e.g., hostHeaderVerify >>> was called with SNI once, but you expected it to be called with SNI >>> twice). >>> >>> >>>> I was wondering if this could be considered a bug or if there is a >>>> rationale to change the behavior in the "peek at step2, splice at step3" >>>> scenario. >>> >>> If my interpretation above is correct, then this sounds like a bug to >>> me: Squid/hostHeaderVerify() must validate every request target value >>> Squid intends to use for cache lookups and/or connecting. If the request >>> target changes from IP to SNI, then Squid must validate exactly twice. > > >> SSL-Bump step 3 does not need to verify > > That fact is unrelated to the concern being raised in this thread > AFAICT: The concern is _not_ whether Squid verifies the target of the > SNI-based CONNECT during step3. The concern is whether Squid verifies > the target of the SNI-based CONNECT at all. ... after a peek rule matched at step2, of course. We already know from the original email on this thread that Squid verifies the target of the SNI-based CONNECT after a splice rule matched at step2, as expected. Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
