Re: [squid-users] Dynamic Certs Squid 3.3

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
Received on Tue Oct 16 2012 - 23:12:47 MDT