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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
