On 16/02/2023 10:56 am, squid wrote:
I have a reverse proxy that that does the following: acl example_www url_regex -i ^https?:\/\/example-www?.example.com.* http_access allow internal_IPs example_www deny_info https://other-www.other.com%R example_www http_access deny example_www When a tool or a browser goes to http://example-www.example.com it immediately sends them to https://other-www.other.com as expected.
When opening an http:// URL Browsers etc send a message with the full URL including path to Squid. That provides the %R information your rules use to redirect them.
Browser: GET http://example-www.example.com/path HTTP/1.1 ... Squid: HTTP/1.1 304 ... Location: https://other-www.other.com/path Browser: ... initiates request for https://other-www.other.com/path
When a tool or a browser goes to https://example-www.example.com it brings up in chrome the Your connection is not private page and when you hit Advanced and hit the allow to proceed it is then redirected to the site.
When opening an https:// URL Browsers etc send a CONNECT message requesting Squid open a tunnel to the server. That lacks the %R information your rules use.
Browser: CONNECT example-www.example.com:443 HTTP/1.1 ... Squid: HTTP/1.1 304 ... Location: https://other-www.other.com/ Browser: ... initiate request for https://other-www.other.com/
This is causing us come compliance issues due to the tool thinking we are running a non-compliant https page since user interaction is required to get to the other page. Is there a way to send to the other page earlier so the tool or user doesn't even see the Your connection is not private page? I just want to only aloow the internal IPs and cut everyone else off.
As you noticed the Browser displays that warning dialog when it receives a 304. AFAIK, the only response status that Browser permit to do anything at all on a CONNECT request are the 200 and 304 ones. Everything else gets replaced by a Browsers error page. The non-Browser tools may display an error from Squid, YMMV based on tool.
Squid contains the SSL-Bump feature to decrypt the TLS inside the tunnel. If you have the clients trusting Squid CA certificate you can decrypt the TLS and redirect those messages instead of the CONNECT tunnel.
I've tried taking out the deny_info, but that sends the user and tool to a squid error page which basically fails the test as well since it's on the same site. I've also tried doing a TCP_RESET instead, but for some reason the squid actually send the word reset back to the client the first time and again would fail the test.
That is a bug. It should be delivering only a TCP RST packet, not any text words. Which Squid version are you using?
If you end up using SSL-Bump it has a "terminate" action which does the same/equivalent for TLS protocol.
HTH Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
