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

[Alex Rousskov]

On 5/5/20 5:38 AM, Amos Jeffries wrote:
> On 5/05/20 4:31 am, Alex Rousskov wrote:
>> On 5/3/20 10:41 PM, Scott wrote:
>>> 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.

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

I do not know what you mean by "CONNECT tunnel message objects" and "TLS
handshake state objects" exactly but HttpRequest with the (real or fake)
CONNECT request should exist and be available to ssl_bump and
http_access ACLs during SslBump steps. The dstdomain ACL uses
HttpRequest AFAICT.

Most deployed http_access configurations allow those CONNECT requests
while peeking at TLS; and many broken configurations deny them (too
soon), triggering support queries on this mailing list.


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

For intercepted connections, the fake CONNECT request carries
information extracted from the TCP connection and the TLS handshake.

For other cases, there is a real CONNECT request to carry that
information (and more). It is adjusted with SNI info if possible.

At least that is the way SslBump should work in modern Squids. I agree
that many SslBump bugs have been fixed since the quoted wiki paragraph
was written, but the presence of the CONNECT HttpRequest is rather
fundamental since the beginning of Peek and Splice approach because
http_access rules are difficult to write without it, especially because
we did not want to make "step" ACLs officially available for the
http_access rules.


HTH,

Alex.