-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey Jason, Indeed it is nasty. I do not remember now how I advised in the past to defend against this issue. There is a "risk" in every system operation and this is one of them. You indeed found this "bug" or security vulnerability! Specially on linux the main way to handle this issue is disabling direct access to the intercepting port. The options on linux are basically iptables mangle table rules. There is however the specific case that iptables do not cover and it's the case is:(sysadmin R rated knowledge ahead) using a remote ip with a specific address such as localhost which is defined on the proxy. practical example: # nc -v 8.8.8.8 80 > GET http://localhost/ HTTP/1.1 Host: localhost ... ##END of example The above example was tested in the past on too many systems and was and still on some there. Some will call it a bug and others will call it a feature. I would say something similar to what I have seen in the old movie "3 ninjas": "with power comes responsibility" Squid has the means to defend against such vulnerability but only a good admin will be able to use them. All The Bests, Eliezer * 3 ninjas(PG) - http://www.imdb.com/title/tt0103596/ On 11/12/2014 09:15 PM, Jason Haar wrote: > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUY8agAAoJENxnfXtQ8ZQUVZwIAIYMgkYvUwvBG346VIeTFso5 b5qyzM9iTk6M/xWKO9Ml3ZfNh2EE4yFcdSyj3du+dRwXYadqRmOOn+FOskEWHIrd 4S5K/7wF3fsXFXJbie54QwY1o32rS8R4ZA/3NANrJt+n5/kHTccp/7UtQm5rCL/8 9eKAvQPBqvx/hfB1nfZkRpbMn5bHJKG0LUQDigmCIKBMkgjFoBRfpiFz5TNHcohS /n7JZAUalCLqpfI9n1TSZ43wfvzKj+/f0ToEEdyxXH7K6+/QfjKeQYhAkhmNNpky T1/ceT4/QQGzcClxnv4Lm/ZOLk37s+UWHCevvvJGlfGjUIO/5D9JAtLSfY6gG4E= =AiTp -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
