[squid-users] Filering HTTPS URLs - A complete configuration

[Amos Jeffries]

On 6/02/19 3:33 am, Paul Doignon wrote:
> Hi,
> 
> I'm struggling a lot to configure Squid. To improve the security of my app in my AWS private subnet,

If it is indeed *your* app; then please alter it not to require the
interception we see below. Ability to connect to a TLS explicit proxy or
just sending regular proxy CONNECT tunnel is a leap up in security.


> I would like to build a HTTPS proxy to whitelist *only* some URLs.
> My wish is to *not* rely on SNI filtering but bump HTTPS traffic in order to filter the URLs (path) of HTTPS requests. I know that means to install a custom CA.
> The thing is... I have a hard compiling a working configuration file for Squid 3.5, most examples are outdated or incomplete.

It looks below like you are of the mistaken belief that "HTTPS requests"
are actually a distinct thing that can be manipulated and tested.

"HTTPS" is just a moniker used to describe a multi-layer system for
delivering HTTP messages securely. This has a major impact on what can
be done at any particular time, especially regarding the URLs from those
HTTP messages.


> 
> My current config is :
> 
> # ---
> # General
> cache_effective_user squid
> cache_effective_group squid
> shutdown_lifetime 1 seconds 
> visible_hostname squid
> 

Note 1) 'squid' is not a unique hostname. Ideally it should be a FQDN.
At the very least an internally resolvable name so the URLs Squid
generates with this string as the domain name will be valid for clients
needing to download objects with those URLs from Squid. Either way it
has to be unique across all proxies the traffic *might* travel -
otherwise the messages will be dropped in transit. So definitely do not
use something this simple and often-repeated as "squid" or "proxy".


> # Hide some reavealing or useless headers
> forwarded_for delete
> httpd_suppress_version_string off
> reply_header_access X-Cache deny all
> reply_header_access X-Cache-Lookup deny all
> via off
> 
> # Tuning
> max_filedesc 10000
> 
> # Disable access to manager
> http_access deny manager
> 

2) you are missing the security protections from the default squid.conf...


> # Handling HTTPS requests
> https_port 8080 ssl-bump generate-host-certificates=on dynamic_cert_mem_cache_size=4MB cert=/etc/squid/ssl/squid.pem options=NO_SSLv3,NO_TLSv1,NO_TLSv1_1,SINGLE_DH_USE,SINGLE_ECDH_USE intercept
> sslcrtd_program /usr/lib64/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
> sslcrtd_children 8 startup=1 idle=1
> acl SSL_port port 443
> http_access allow SSL_port
> 

3) Not a good idea. I see a lot of admin get this far and stop looking
for the proper solution when "things work".

Since you are intercepting traffic to reach this point it should be
somewhat reasonable to limit the allowed traffic to some IP range. eg.
the subnet of IPs you are intercepting and sending into the proxy.


> # Whitelist
> acl whitelist-regex url_regex -i thirdparty.com/upload/stuff/
> acl whitelist-regex url_regex -i otherthirdparty.com/specific-path/
> http_access allow whitelist-regex

Okay.

> 
> # SSL bump
> acl step1 at_step SslBump1
> ssl_bump peek step1

 ... if the client is allowed to connect to the proxy, fetch its
clientHello details...


> ssl_bump bump whitelist-regex

... then try to do the impossible. We only have TLS details at this
point. There is no HTTP message - therefore no URL to match against.
 -> result: skip this line, never do this "bump" action.


> ssl_bump terminate step2 !whitelist-regex

... regex still cannot match.
... but a non-match (aka false) with '!' means true.

So at step2 always terminate the connection.


Notice how there has still not been anything even remotely HTTP from the
client/app and they are now disconnected.

> 
> # Deny the rest
> http_access deny all
> # --- 
> 
> What I am missing ?

It seems understanding of what ssl_bump is doing is lacking.

Please see <https://wiki.squid-cache.org/Features/SslPeekAndSplice> for
details on the TLS handshake process and what SSL-Bump does during that.


> Should I use squid 4 for this ?

TL;DR : Yes.


Long version:

TLS is a volatile environment these days and each Squid release has
large improvements to cope with that change. You will find that v4 works
okay in a lot of TLS situations where v3 would the throwing up errors
and needing extra config workarounds.

Also, v3.x are all officially deprecated / no longer supported. v4 is
the current stable release.


Amos