-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 12/11/2014 5:49 p.m., Jason Haar wrote: > Hi there > > I was reading this list about the issue with google.com and was > playing around - and I used telnet to connect directly to the > intercept ssl-bump port. End result was squid immediately went to > 99% CPU, and the cache.log started reporting > > WARNING! Your cache is running out of filedescriptors WARNING! Your > cache is running out of filedescriptors WARNING! Your cache is > running out of filedescriptors > > The box staggered to it's knees, so I had to kill squid. Restarted > it and everything is fine - until I do that again. If I let the > network redirecting work (ie make outbound port 443 connections), > this doesn't happen - it's only if I directly connect to the > intercept port Otherwise known as a "Forwarding loop" or "Denial of Service" depending on whether it breaks the client request, the server, or your whole network connectivity. Short answer: That being one of the "NAT security vulnerabilities" mentioned as reason for mangle table rules. http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxRedirect http://wiki.squid-cache.org/ConfigExamples/Intercept/LinuxDnat ... and a core reason for using Via header. ... and incidentally why Squid complains about not having a forward-proxy port to use in some configurations. Long answer: What do you think "server-first" means ? (hint step 3 below). 1) Your telnet opened a connection. 2) The TCP packet IPs told Squid the server you were connecting to was itself on port 3126. 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. > > I have my "http_port intercept" and "https_port intercept" set > identically (except for the ssl stuff of course), and yet if I > telnet to the http_port set to intercept, this does NOT happen - it > works fine... No. "works fine" is a wrong conclusion. This could only "work" if you sent Squid a test HTTP message with forward-proxy URL syntax. When you start actually using the port for real traffic with port-80 URL syntax it will break with forwarding loops like above. 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. A proper HTTP client software like squidclient, wget, curl, or even a full browser should be used. Amos -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUYvdMAAoJELJo5wb/XPRjL04H+gKhrYJ20swYkWCOsVrjyRnl /t3up7PhwKSEaguNnbdkCaT9B/5t3uft+hp9VpiEZkEuTub+JYPWn/3Z2ugCSqKf k1uiRjHboex+AEILNc5o5fny1CKyXRdCzOArqXvrrTBLOeWGx+Sc5QL+8tiC3g27 ZJ3ldgWS9O7ewdWhp24ReCjgGufq0oWz0PC6BsCVy0qilLjBK4yk+E/xI0Ht3nVj YTU6lNUzli4Sb0ElMHpJkGbF8lh0e48iEvyIyHdYvTMmbf3gR/lD51mS9XNzrxMu CiDX7Ok4M/ELdadNG7kgWvKzAZVlySb+63Xaix1CyGzJlWHSwISaH2QLnsASbP0= =bnBC -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
