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

Wed Feb 6 14:52:26 UTC 2019

Thanks, I appreciate your detailed answer.

 > > 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 wish I could too ! Unfortunately, we use some third party libraries that do not support proxies (or not well). What a shame : (

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

I have not hardened Squid yet, but you mean default `acl localnet src [...]` rules ? I'm not sure about this.

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

Another read was indeed interesting, I think I corrected ssl_bump directives. However I still can't make it work.
Just for the record, I would like to block everything but some HTTPS websites for particular URLs. The ssl::server_name acl is not enough for me, I would like to use url_regex or similar.
Ant that's where it gets wrong, I can't make Squid make the link between `ssl_bump bump` and url_regex.

# --
# General
shutdown_lifetime 1 seconds 

# 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

# Misc, TODO 
http_port 3128
host_verify_strict off 

# 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/lib/squid/security_file_certgen -s /var/cache/squid/ssl_db -M 4MB
sslcrtd_children 8 startup=1 idle=1
acl SSL_port port 443
http_access allow SSL_port

# 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

# SSL bump
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
ssl_bump stare step1 all
ssl_bump stare step2 all
ssl_bump bump whitelist-regex
ssl_bump terminate all

# Deny the rest
http_access deny all
# --

 > > Should I use squid 4 for this ?
 > 
 > TL;DR : Yes.

I did that, thanks !
Easy to install and migrate on arch but I think I will need to compile it for Amazon Linux.

 ---- On Tue, 05 Feb 2019 16:35:52 +0100 Amos Jeffries <squid3 at treenet.co.nz> wrote ---- 
 > 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
 > _______________________________________________
 > squid-users mailing list
 > squid-users at lists.squid-cache.org
 > http://lists.squid-cache.org/listinfo/squid-users
 > 