[squid-users] hostHeaderVerify with SNI in interception environments

[Alex Rousskov]

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.

Alex.