[squid-users] cannot intercept "https://www.elastic.co/"

[Amos Jeffries]

On 18/02/2016 10:58 p.m., Murat K wrote:
> Hi Amos,
> as you said I upgraded to squid-3.5.14-1.el6.src.rpm and my problems below are gone, however can you explain me what is wrong with my config please? this is my config:
> 
> 
> shutdown_lifetime 1 seconds
> 
> icp_port 0
> 
> workers 2
> 
> http_port 0.0.0.0:8080 ssl-bump cert=/var/ngf/proxy/https_cert generate-host-certificates=on
> 
> http_port 0.0.0.0:18080 intercept ssl-bump cert=/var/ngf/proxy/https_cert generate-host-certificates=on
> 
> https_port 0.0.0.0:18081 intercept ssl-bump cert=/var/ngf/proxy/https_cert generate-host-certificates=on
> 
> acl no_ssl_interception dstdom_regex  "/etc/squid/https_exceptions"
> 

Problem #1:
  dstdom* ACLs do not work properly in ssl_bump. The dstdom* is taken
from HTTP message URL - but ssl_bump is operating before there is any
HTTP message decrypted for that detail to come from.

The correct ACL type to be using here is ssl::server_name_regex.
Assuming that list is actually a set of regex patterns and not just a
list of domain names (which is another common misconfiguration).


> ssl_bump none localhost
> 
> ssl_bump none no_ssl_interception 
> 
> ssl_bump server-first all
> 

Problem #2:
 none and server-first are deprecated actions for bumping. You need to
upgrade it to peek, splice, stare, bump, terminate actions.

The equivalent to what you have above is:
  ssl_bump splice localhost
  ssl_bump splice no_ssl_interception

  acl step2 at_step SslBumpStep1
  ssl_bump step2 bump


> acl https_proto proto https
> 
> always_direct allow https_proto
> 

You dont have any cache_peer that I can see. So this is not necessary.

> sslproxy_cert_error allow all

Bad idea. This makes Squid treat any TLS errors (security or syntax
alike) as if nothing had gone wrong.

This directive is supposed to be used to specify a small set of errors
which are known to be safe but for some reason unavoidable on your
server connections. There are some for which that is true. MOST errors
in TLS are actually bad and need to be handled.

> 
> sslproxy_flags DONT_VERIFY_PEER


Very bad idea. This disables *all* security that TLS offers beyond very
basic TLS syntax errors. It was only ever intended for debugging broken
installations. Never for production use.

So you are not checking (verifying) that the other end of the connection
is the server you tried to connect to, AND ignoring all errors that
occur in the protocol or crypto. Think about what that means.

This TLS thing is a security protocol, I mean like - its supposed to do
security. Be secure and all that jazz.


> cache_effective_user squid
> 
> cache_effective_group squid
>

Check your squid -v output. If it contains "--with-default-user=squid"
then you can drop both of those.

If it contains another username, you should consider changing your file
permissions to be that default username instead of "squid". Then
dropping the two above directives.


> cache_mem 60 MB
> 
> cache_dir rock /var/spool/squid 200 max-size=32768
> error_directory /usr/share/squid/errors/tr
> icon_directory /usr/share/squid/icons
> max_filedesc 96751
> server_persistent_connections off

This prevents Squid using one of the major performance features of
HTTP/1.1 protocol (persistent connections / keep-alive). You should
seriously re-enable it unless it causes grief directly attributable to
the HTTP keep-alive feature.

If you are doing this to reduce upstream server connections hogging
sockets too long, then tune the server_idle_pconn_timeout directive and
your systems TCP wait periods instead.

Amos