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. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx https://lists.squid-cache.org/listinfo/squid-users
