For starters 3.3 is not quite in beta yet, which means all questions
need to be sent to squid-dev mailing list. This is a users list.
Amos
On 17.10.2012 06:04, Jesse Smith wrote:
I am having a problem where, when visiting a secure URL, the browser
just hangs when using Squid. There is nothing in the logs that
indicate
why. The configuration is set up to use dynamic ssl certs.
Can anyone see anything wrong with the configuration below, or why
this
may be occurring? It seems as if it cannot resolve the URL, though it
works fine with a general ssl-bump configuration. Thanks in advance.
My configuration is below:
=======================================================================
sslproxy_cert_error allow all
You are bypassing / erasing / ignoring all server errors. This is BAD.
Any attacker can forge a fully broken certificate on an HTTPS server and
your users will get "green light" fully-secure messages from their
browsers.
... and then you are using it on intercepted HTTPS traffic. I hope you
have 8really* good lawyers.
ssl_bump server-first
NOTE: the whole point of server-first bumping is that the server errors
are to be passed to the client browser for the appropriate security
checks. Passing *them* responsibility when things go wrong.
sslproxy_flags DONT_VERIFY_PEER
sslcrtd_program /usr/local/squid3/libexec/ssl_crtd -s
/usr/local/squid3/var/lib/ssl_db -M 4MB
sslcrtd_children 5
#http_port 10.1.10.136:3128 intercept ssl-bump
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
cert=/usr/local/squid/certs/star_primepublicsafety_com.crt
key=/usr/local/squid/certs/star_primepublicsafety_com.cer
https_port 10.1.10.136:443 intercept ssl-bump
generate-host-certificates=on dynamic_cert_mem_cache_size=4MB
cert=/usr/local/squid/certs/star_primepublicsafety_com.crt
key=/usr/local/squid/certs/star_primepublicsafety_com.cer
cache_peer 127.0.0.1 parent 443 0 no-query ssl
sslflags=DONT_VERIFY_PEER
originserver name=prod
cache_peer 127.0.0.1 parent 8447 0 no-query ssl
sslflags=DONT_VERIFY_PEER originserver name=test
acl USallow src "/etc/httpd/uszone/us.zone"
acl localallow src "/etc/httpd/uszone/local.zone"
acl sites_prod dstdomain ks.ibarsbudget.com
http_access allow sites_prod
cache_peer_access prod allow sites_prod
cache_peer_access prod deny all
acl sites_test dstdomain kstest.ibarsbudget.com
http_access allow sites_test
cache_peer_access test allow sites_test
cache_peer_access test deny all
http_access allow localallow
http_access allow USallow
http_access deny all
Intercepted / bumped requests are not permitted to go via peers - even
if the cache_peer is configured to use TLS on its connection with Squid.
Squid is not yet capable of re-wrapping the CONNECT request around
outbound traffic so it is not able to even fake the end-to-end security
requirement of HTTPS when sending to peers. We opted for disabling peer
traffic for bumped/intercepted HTTPS rather than making Squid perform
information leaks by default.
You can bump and scan / block. But not bump and re-route.
Amos
