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

[Rik Theys]

Hi,

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

Looking at the logs, I'm also having problems determining where each 
ssl-bump step is started.

> Please note that in many environments forgery detection does not work 
> well (for cases where it is performed) due to clients and Squid seeing 
> different sets of IP addresses for the same host name. There are 
> numerous complains about that in squid-users archives.
>
>
>> For example, if I add "wordpress.org" to my allowed_domains list, the 
>> following request is allowed:
>>
>> curl -v https://wordpress.org --connect-to wordpress.org:443:8.8.8.8:443
>>
>> 8.8.8.8 is not a valid IP address for wordpress.org. This could be 
>> used to bypass the restrictions.
>
> Agreed.
>
>
>> Is there an option in squid to make it perform a forward DNS lookup 
>> for the domain from the SNI information from step1
>
> FYI: SNI comes from step2. step1 looks at TCP/IP client info.
>
>
>> to validate that the IP address we're trying to connect to is 
>> actually valid for that host? In the example above, a DNS lookup for 
>> wordpress.org would return 198.143.164.252 as the IP address. This is 
>> not the IP address we're trying to connect to, so squid should block 
>> the request.
>
> AFAICT, there is no built-in support for that in current Squid code. 
> One could enhance Squid or write an external ACL to perform that kind 
> of validation. See above for details/caveats.
>
>
>> Similar question for the server certificate: I've configured the 
>> 'ssl_bump peek step2 https_domains' line so squid can peek at the 
>> server certificate.
>
> 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 "-"?

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

Regards,

Rik