On 11/05/2013 11:35 a.m., Warner Moore wrote:
I've been using SQUID for years to terminate inbound client connections to externally facing web sites. With SQUID 2.6, I specified transparent in the https_port, setup some acls, and it worked seamlessly.
Really? "seamlessly"? I think you did not have it working at all then.
This same exact configuration will work identically in in all squid-2.6+
and squid-3.0+, even the 3.2/3.2 versions. Traffic will be terminated by
Squid using the *single* static certificate you configured Squid with.
All clients will get a popup on *every* HTTPS site they visit warning
about a hijack by your proxy unless you have configured them to trust
your self-signing CA.
If you see anything different you have either *not* intercepted the
traffic like you thought. Or the SSL on your network is fundamentally
broken beyond repair.
I have been trying to get a similar configuration working with SQUID 3.3. Changing the 'transparent' to intercept, adding ssl-bump, and then setting ssl_bump client-first to the appropriate domains. Unfortunately, I'm receiving these errors:
2013/05/10 18:33:11 kid1| NF getsockopt(SO_ORIGINAL_DST) failed on local=192.168.123.123:443 remote=4.4.4.4:11034 FD 12 flags=33: (92) Protocol not available
Ah, *NAT* is not working on the Squid box. This is unrelated to the
HTTPS parts.
Will this configuration still work with modern SQUID or must a different approach be taken? I appreciate any help, this is starting to frustrate me.
The NAT operations _must_ be done on the Squid box. Use policy routing
to move packets between machines without NAT to get them to the Squid box.
Amos
