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
Received on Sat May 11 2013 - 10:01:04 MDT
This archive was generated by hypermail 2.2.0 : Mon May 13 2013 - 12:00:05 MDT