[squid-users] connecting directly to ssl-bump intercept port causes runaway CPU

[Amos Jeffries]

-----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-----