[squid-users] How to setup a secure(!) squid proxy

[Amos Jeffries]

On 15/01/2016 3:38 p.m., startrekfan wrote:
> Hello,
> 
> thank you for your answer. I'm using the debian stable version(3.4.8) at
> the moment. The squid server is working very well.
> 
> But I have a different question: How to secure/hardening my squid _https_
> proxy?
> 

I'm a lot confused why you keep saying "HTTPS proxy", talking about
being "secure" ... while everything you are doing is making it less and
less secure.


Take a read through <http://wiki.squid-cache.org/Features/HTTPS> to see
the different types of "HTTPS proxy".

 Firstly, notice how there are multiple completely different topologies
involved. So saying you have a "HTTPS proxy" is not informative.


 Secondly, the most secure type of proxying that can be done for HTTPS
is to just blindly relay the TLS part. That is what a CONNECT request
does. All Squid are capable of that whether built with OpenSSL or not.

In other words; For security hardened *proxy* the build Debian packages
and supplies already, using normal forward-proxy configuration, is the
most secure you can achieve.


So why exactly (beyond "being secure") are you trying to do anything
different?


> I used the following page to configure my https proxy:
> http://wiki.squid-cache.org/ConfigExamples/Intercept/SslBumpExplicit
> 

SSL-Bump feature is about hijacking and decrypting traffic. By
definition any traffic that can be hijacked is not very secure. The
traffic which actually was secure will break when Squid older than 3.5
try to touch it.

By actually doing the decrypt you increase the size of the risk
footprint by the size of Squid code.

Yes there are things Squid can do to improve the crypto used for that
traffic on the *outbound* side of Squid. But we need the answer to the
above question to know if this is even a reasonable approach to take in
the first place. The same things could be done directly on the client
without affecting the risk footprint.

HTH
Amos