[squid-users] hostHeaderVerify with SNI in interception environments

[Alex Rousskov]

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.