On 12/11/14 18:59, Amos Jeffries wrote: > > That being one of the "NAT security vulnerabilities" mentioned as > reason for mangle table rules. Sorry, I should have said that if I remove the iptables 443 redirect rule, it still occurs! > > 3) Squid connected there to fetch the SSL certificate details. > > 4) The TCP connection from Squid to Squid:3126 was opened. > > 5) go back to #2 > > > HTTP has the Via header mechanism to restrict the loop to protect > against the DoS becoming a wide problem. But notice how no HTTP is > taking place, Squid is still trying to perform the TLS/SSL operations. > There is no protection at the TCP layer. > Ah! Yeah - nasty > > Please stop using telnet and manual data entry to test HTTP services. > If you knew enough about the protocol to type it into telnet correctly > the above loop problems would not be surprising you. > So you're saying this is expected behaviour? Squid with HTTPS intercept enabled is vulnerable to DoS attacks with a simple 3-way? Now that you have explained it to me, I can see the issue, but I think squid needs to do something about it. eg when squid starts it could make a note of all it's own IP addresses:ports, then if someone asks squid to connect to those combinations, reject it. There is no valid case where squid should ever be used to connect to itself that I can think of I just made the following changes acl localSquidServer src 127.0.0.1 proxy.ip.address deny_info ERR_LOCALSQUID localSquidServer http_access deny localSquidServer Now when I connect to the HTTP (not https!) intercept port, I see the html error page ERR_LOCALSQUID - great - works like it says on the box. However, that deny doesn't trigger for https (it's the first http_access entry BTW). Shouldn't that be a mechanism to filter this DoS out? If not, shouldn't there be "https_access" to achieve the same thing? I also tried using iptables to exclude such connections, but my proxy is my default gateway and I couldn't come up with a rule that worked without breaking redirection all together. > A proper HTTP client software like squidclient, wget, curl, or even a > full browser should be used. I explicit mentioned telnet (nc is the same) because it means it triggers on any successful TCP 3-way handshake - no data needs to flow for the fault to trigger. If I call "curl http://proxy.server:3127"; it also triggers the runaway CPU (3127 being my https intercept port of course). Thanks -- Cheers Jason Haar Corporate Information Security Manager, Trimble Navigation Ltd. Phone: +1 408 481 8171 PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
