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

[Alex Rousskov]

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:
>>> acl allowed_clients src "/etc/squid/allowed_clients"
>>> acl allowed_domains dstdomain "/etc/squid/allowed_domains"
>>
>>> http_access allow allowed_clients allowed_domains
>>> http_access allow allowed_clients CONNECT
>>> http_access deny all
>>
>> Please note that the second http_access rule in the above 
>> configuration allows CONNECT tunnels to prohibited domains (i.e. 
>> domains that do not match allowed_domains). Consider restricting your 
>> "allow...CONNECT" rule to step1. For example:
>>
>>     http_access allow allowed_clients step1 CONNECT
> Thanks, I've updated my configuration.


Please do test any suggested changes. There are too many variables here 
for me to guarantee that a particular set of http_access and ssl_bump 
rules works as expected.


>>> 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 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.


>>> Is there a way to configure squid to validate that the server 
>>> certificate is valid for the host specified in the SNI header?
>>
>> IIRC, that validation happens automatically in modern Squid versions 
>> when Squid receives an (unencrypted) server certificate.
>>
> Do you happen to known which version of Squid introduced that check?

IIRC, Squid v5.5 has that code.


HTH,

Alex.