[squid-users] Squid appears to be ignoring url_rewrite_program

[Alex Rousskov]

On 2024-09-17 09:34, Martin A. Brooks wrote:
> Proxied HTTPS requests use 
> CONNECT and, for whatever reason, this appears to bypass the url 
> rewriter.

What makes you think that CONNECT requests are not sent to the rewriter? 
In my quick-and-dirty tests, Squid does send CONNECT request targets to 
the URL rewriter program and honors rewriter's rewrite-url=... response. 
For example, I see the new target logged to access.log.

Please keep in mind that changing CONNECT target has no effect on the 
received origin server response if the new target resolves to the same 
or equivalent IP address as the original target (and the port is 
unchanged): The origin server does not get a CONNECT request. It gets a 
TCP connection from Squid. The bytes on that connection come from the 
client (e.g., browser) rather than Squid! Those bytes contain original 
(not rewritten) TLS and HTTP details. By default, Squid works as a blind 
TCP tunnel when handling CONNECT requests.


> I'm looking in to it some more but, given that a very large 
> part of the world is HTTPS these days, it may be that I need to look at 
> another option for this requirement.

If your rewriter helper is using url=... instead of rewrite-url=... 
responses, then please note that popular browsers do not honor redirect 
responses to their HTTP CONNECT requests -- they have chosen not to 
trust the proxy to make those kind of decisions.

Most likely, if you need to redirect https traffic, you have to bump(*) 
it; if you cannot bump in your environment, then you cannot redirect 
https using an HTTP proxy.

(*) See ssl_bump directive and the following URL, but keep in mind that 
bumping is naturally full of bad side effects and corner cases:
https://wiki.squid-cache.org/Features/SslPeekAndSplice


HTH,

Alex.