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

[Jason Haar]

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