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@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
