[squid-users] Best way to prevent squid from bumping CONNECTs

Amos Jeffries squid3 at treenet.co.nz
Tue May 5 09:38:39 UTC 2020


On 5/05/20 4:31 am, Alex Rousskov wrote:
> On 5/3/20 10:41 PM, Scott wrote:
> 
>> acl tcp_open_connect_sslbump at_step SslBump1
>> acl ssl_splice_sni ssl::server_name "/usr/local/etc/squid/acls/splice_sni"
>> acl guest_net_src src x.y.z.0/24
>>
>> ssl_bump peek tcp_open_connect_sslbump
>> ssl_bump splice ssl_splice_sni
>> ssl_bump bump guest_net_src
>> ssl_bump splice
> 
> 
>> where I splice instead of bump for destinations that are often used with 
>> certificate pinning software (.apple.com with iOS for example).
> 
> 
>> https://wiki.squid-cache.org/Features/SslPeekAndSplice says "At no point 
>> during ssl_bump processing will dstdomain ACL work".
> 
> I have not tested this, but I would expect the dstdomain ACL to work
> during SslBump steps using the destination address from the (real or
> fake) CONNECT request URI. It is possible that, for the author of that
> wiki statement, that kind of functionality is equivalent to "not work",
> but I personally would not phrase it that way.
> 

We do not save the CONNECT tunnel message objects in the TLS handshake
state objects. As such the state needed by dstdomain is not available
during ssl_bump ACL processing.

Only state from the TCP connection and the underway TLS handshake are
guaranteed to be available to the ssl_bump ACLs. Anything else is
best-effort.

 At least that was the situation when that documentation was written.
The bugs we have about other CONNECT state not being available are still
open so I doubt the situation has changed even with the more recent
refactoring.

Amos


More information about the squid-users mailing list