[squid-users] How to block a https website with squid 3.5.3

Thu Jan 11 12:16:37 UTC 2018

On 11/01/18 23:39, minh hưng đỗ hoàng wrote:
> Dear all, i using squid as a transparent proxy. But i can't deny a https 
> website like
> https://remitano.com
> 

The first step is to upgrade your Squid. TLS hijacking is a very 
volatile area and things are changing often 3.5.3 is a very old Squid 
release now.
  The current Squid-3 version is 3.5.27.

> My squid is compiled on ubuntu14 with this configure option
> Squid Cache: Version 3.5.3
> Service Name: squid
> configure options:  '--prefix=/usr' '--includedir=/usr/include' 
> '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' 
> '--libexecdir=/usr/lib/squid' '--srcdir=.' '--datadir=/usr/share/squid' 
> '--sysconfdir=/etc/squid' '--mandir=/usr/share/man' '--enable-inline' 
> '--enable-async-io=24' '--enable-storeio=ufs,aufs,diskd,rock' 
> '--enable-removal-policies=lru,heap' '--enable-gnuregex' 
> '--enable-cache-digests' '--enable-underscores' '--enable-icap-client' 
> '--enable-follow-x-forwarded-for' '--enable-eui' '--enable-esi' 
> '--enable-icmp' '--enable-zph-qos' '--enable-http-violations' 
> '--enable-ssl-crtd' '--enable-linux-netfilter' '--enable-ltdl-install' 
> '--enable-ltdl-convenience' '--enable-x-accelerator-vary' 
> '--disable-maintainer-mode' '--disable-dependency-tracking' 
> '--disable-silent-rules' '--disable-translation' '--disable-ipv6' 
> '--disable-ident-lookups' '--enable-delay-pools' 
> '--with-swapdir=/var/spool/squid' '--with-logdir=/var/log/squid' 
> '--with-pidfile=/var/run/squid.pid' '--with-aufs-threads=24' 
> '--with-filedescriptors=65536' '--with-large-files' '--with-maxfd=65536' 
> '--with-openssl' '--with-default-user=proxy' '--with-included-ltdl'
> 
> And here is my squid.conf
> 
> acl localnet src 192.168.10.0/24 <http://192.168.10.0/24> #LAN
> acl localnet src 10.10.10.0/24 <http://10.10.10.0/24> #WIFI
> acl localnet src 10.10.20.0/24 <http://10.10.20.0/24> #WIFI
> acl localnet src 172.18.18.0/24 <http://172.18.18.0/24> #WIFI
> acl localnet src 172.17.0.0/16 <http://172.17.0.0/16>
> acl localnet src 10.10.1.0/24 <http://10.10.1.0/24>
> 
> acl Safe_ports port 21 # ftp
> acl Safe_ports port 443 # https
> 
> 
> acl Safe_ports port 70 # gopher
> acl Safe_ports port 210 # wais
> acl Safe_ports port 1025-65535 # unregistered ports
> acl Safe_ports port 280 # http-mgmt
> acl Safe_ports port 488 # gss-http
> acl Safe_ports port 591 # filemaker
> acl Safe_ports port 777 # multiling http
> acl CONNECT method CONNECT
> 
> http_access deny !Safe_ports
> http_access deny CONNECT !SSL_ports
> http_access allow localhost manager
> http_access deny manager
> http_access allow localnet
> http_access allow localhost
> http_access deny all
> 
> 
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump terminate blockregexurl

TLS does not have URLs. So this will never work.

You need to use ssl::server_name ACLs instead of dstdomain for this 
directive.

ALso, maybe ssl::server_name_regex for the regex patterns *if* any are 
relevant after considering how URLs dont exist.

You are doing peek first, which should make the SNI details available 
for ssl::server_name* to use.

> ssl_bump terminate domain
> ssl_bump terminate block_domain
> ssl_bump splice all
> 
> 
> sslproxy_options NO_SSLv2,NO_SSLv3,No_Compression
> sslproxy_cipher  
> ALL:!SSLv2:!SSLv3:!ADH:!DSS:!MD5:!EXP:!DES:!PSK:!SRP:!RC4:!IDEA:!SEED:!aNULL:!eNULL
> sslproxy_cert_error deny all
> sslproxy_flags  DONT_VERIFY_PEER

Remove that DONT_VERIFY_PEER flag. It is only hiding problems from *you* 
the admin - while letting them still be problems for all your clients.

> sslproxy_cafile /etc/squid/intermediate_ca.pem
> 

This is a bit dangerous. Any non-intermediates Ca certs in that PEM file 
will allow remote hijacking of your proxy outbound connections by 
clients of that root CA.

That said,   you already completely disabled *ALL* verify checks on the 
server certs with DONT_VERIFY_PEER - so anyone can already hijack your 
traffic without needing to go to the trouble of even having their certs 
signed. All they need is some garbage bytes that use the correct X.509 
_format_ used by certs.

After you upgrade your Squid, change that to 
sslproxy_foreign_intermediate_certs which will only load intermediate 
certs for use. If your upgraded Squid does not accept that directive it 
is still too old to use safely for SSL-Bump.

> sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/squid/ssl_db -M 4MB
> sslcrtd_children 8 startup=1 idle=1
> 

What are the http_port and https_port lines you are using?

> -----------------------
> First , i can block facebook by use this command :
> acl facebook dstdomain .facebook.com <http://facebook.com>
> http_access deny CONNECT facebook
> 

You can only block domains like that if;
  a) you are using explicit proxy and the client sent a CONNECT with a 
domain name, or
  b) its IP address rDNS points back to the domain you are naming in the 
ACL, or
  c) the client sends TLS SNI details *and* your ssl_bump rules make 
that detail available to Squid (eg. peek).

see 
<https://wiki.squid-cache.org/Features/SslPeekAndSplice#Processing_steps> 
for details on what SSL-Bump actually does at each step of the TLS 
handshake.

Pay particular attention to what info is available at each "step" - and 
also what is *not* available.

> But it is not effect with https://remitano.com
> I try to use these command but it's not work:
> 
> acl blockregexurl url_regex -i ^http[s]?:\/\/.*\.remitano\.com\/(/vn)
> http_access deny blockregexurl
> http_access deny CONNECT blockregexurl

The regex pattern is looking for an absolute-form URL which will never 
exist in any CONNECT messages, since they always use authority-form URL.

That first http_access line might work *if* you already bumped the HTTPS 
traffic. The second never will.

> 
> acl block_domain dstdomain remitano.com <http://remitano.com>
> acl domain dstdomain sso.remitano.com <http://sso.remitano.com> 
> socket.remitano.com <http://socket.remitano.com> cdn.remitano.com 
> <http://cdn.remitano.com>
> http_access deny block_domain
> http_access deny CONNECT block_domain
> http_access deny domain
> http_access deny CONNECT domain
> 

Same issues mentioned above about the facebook dstdomain ACL as to when 
these dstdomain ACLs will match.

Except that here the "deny foo" lines that go first without mentioning 
CONNECT will match all the same things as the CONNECT line would - 
meaning they already block all traffic even stuff not using CONNECT 
tunnels. So the mention of CONNECT in these lines is pointless, and you 
can completely remove the lines which use it without changing the proxy 
behaviour.

Amos