[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