[squid-users] Validation of IP address for SSL spliced connections

[Rik Theys]

Hi,

On 5/29/24 11:31 PM, Alex Rousskov wrote:
> On 2024-05-29 17:06, Rik Theys wrote:
>> On 5/29/24 5:29 PM, Alex Rousskov wrote:
>>> On 2024-05-29 05:01, Rik Theys wrote:
>
>
>>>> squid doesn't seem to validate that the IP address we're connecting 
>>>> to is valid for the specified name in the SNI header?
>>>
>>> That observation matches my reading of Squid Host header forgery 
>>> detection code which says "we do not yet handle CONNECT tunnels 
>>> well, so ignore for them". To validate that theory, use 
>>> "debug_options ALL,3" and look for "SECURITY ALERT: Host header 
>>> forgery detected" messages in cache.log.
>
>> I've enabled this debug option, but I never see the security alert in 
>> the logs. Maybe it was introduced in more recent versions? I'm 
>> currently using Squid 5.5 that comes with Rocky Linux 9.4.
>
> The code logging "SECURITY ALERT: Host header forgery detected" 
> messages is present in v5.5, but perhaps it is not triggered in that 
> version (or even in modern/supported Squids) when I expect it to be 
> triggered. Unfortunately, there are too many variables for me to 
> predict what exactly went wrong in your particular test case without 
> doing a lot more work (and I cannot volunteer to do that work right now).

Looking at https://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery, 
it always seems to mention the Host header. It has no mention of 
performing the same checks for the SNI value. Since we're peeking at the 
request, we can't see the actual Host header being sent.

And indeed: if I perform the same test for HTTP traffic, I do see the 
error message:

curl http://wordpress.org --connect-to wordpress.org:80:8.8.8.8:80


I believe that for my use-case (only splice certain domains and prevent 
connecting to a wrong IP address), there's currently no solution then. 
Squid would also have to perform a similar check as the Host check for 
the SNI information. Maybe I can perform the same function with an 
external acl as you've mentioned. I will look into that later. Thanks 
for your time.

>
>
>> Looking at the logs, I'm also having problems determining where each 
>> ssl-bump step is started.
>
> Yes, it is a known problem (even for developers). There are also bugs 
> related to step boundaries.
>
>
>>> Peeking at the server certificates happens at step3. In many modern 
>>> use cases, server certificates are encrypted, so a _peeking_ Squid 
>>> cannot see them. To validate, Squid has to bump the tunnel 
>>> (supported today but problematic for other reasons) or be enhanced 
>>> to use out-of-band validation tricks (that come with their own set 
>>> of problems).
>
>> I guess that explains why if I add "%ssl::<cert_subject" to my 
>> logformat for the access log, the field is always "-"?
>
> It may explain that, but other problems may lead to the same "no 
> certificate" result as well, of course. You can kind of check by using 
> stare/bump instead of peek/splice -- if you see certificate details 
> logged in that bumping test, then it is more likely that Squid just 
> does not get a plain text certificate in peeking configurations.

I've updated the configuration to use stare/bump instead. The field is 
then indeed added to the log file. A curl request that forces the 
connection to a different IP address then also fails because the 
certificate isn't valid for the name. There's no mention of the Host 
header not matching the IP address, but I assume that check comes after 
the certificate check then.

Regards,

Rik