To follow up:
Adding ssl to the cache_peer directive on squid1 (and changing squid2 so
it listens for connections on an https_port) gets us a little further
but still doesn't work.
Clients get a SQUID_X509_V_ERR_DOMAIN_MISMATCH error (because the
auto-generated cert squid1 gives to the client contains the domain of
the cache_peer *not* the ultimate origin server).
The above is with the following ssl_bump directives set in squid1's config:
ssl_bump peek step1
ssl_bump peek step2
ssl_bump splice step3
A post from another user on this list seems to suggest they successfully
got squid to do what we want
(http://lists.squid-cache.org/pipermail/squid-users/2015-November/007955.html)
but when emulating their setup (i.e. peeking at step1, staring at step2
and then bumping at step3) we get the same
SQUID_X509_V_ERR_DOMAIN_MISMATCH error.
Setting sslflags=DONT_VERIFY_DOMAIN on the cache_peer directive has no
effect.
Connecting to squid1 with a proxy aware client (on a standard http_port
with the ssl-bump flag set but no intercept) also results in the same
problem.
Where are we going wrong?
Charlie
On 27/01/2017 18:24, Charlie Orford wrote:
Hi list
We're using squid 3.5.23 and trying to achieve the following:
client https request (not proxy aware) -> squid1 (https NAT intercept)
-> upstream squid2 (configured as a cache_peer in squid1) -> origin
server (e.g. www.google.com)
Amos mentioned in this thread
http://lists.squid-cache.org/pipermail/squid-users/2016-March/009468.html
that:
> Squid can:
>
> A) relay CONNECT message from client to any upstream proxy.
>
> B) generate CONNECT message on arriving intercepted HTTPS and relay
> that to upstream proxy *IF* (and only if) ssl_bump selects the 'splice'
> action.
>
> C) relay https:// URLs to an upstream TLS proxy.
>
>
> That is all at present.
>
> Squid cannot (yet) generate CONNECT messages to try and fetch TLS
> details via a non-TLS cache_peer. If you are able to sponsor that
> enhancement work patches are welcome, or sponsorship $$ to help pay
> persons working on these things (Christos / measurement-factory) are
> also welcome.
Option B seems to cover what we need i.e. squid1 wraps arriving
intercepted HTTPS traffic in a CONNECT and sends it upstream to squid2
which in turn tunnels it to the origin server. Unfortunately, we can't
get it to work: as soon as squid1 receives a client HTTPS request it
exits with "assertion failed: PeerConnector.cc:116: "peer->use_ssl""
in cache.log
Relevant config for squid1:
######################################
acl localnet src 10.100.0.0/24
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
acl Blocked_domains dstdomain "/etc/squid3/blocked.domains.acl"
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3
acl MITM_TRAFFIC myportname MITM_port
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny to_localhost
http_access deny Blocked_domains
http_access allow localhost
http_access allow localnet
http_access deny all
http_reply_access allow all
https_port 8443 ssl-bump intercept
cert=/etc/squid3/root_ca.combined.pem generate-host-certificates=on
dynamic_cert_mem_cache_size=8MB name=MITM_port
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/lib/squid3/ssl_db -M 4MB
ssl_bump peek all
ssl_bump splice all
nonhierarchical_direct off
never_direct allow all
prefer_direct off
cache_peer 192.168.0.1 parent 3128 0 no-query no-digest
no-netdb-exchange name=WWW_GATEWAY
Relevant config for squid2:
######################################
acl localnet src 192.168.0.0/24
acl SSL_ports port 443
acl Safe_ports port 80 # http
acl Safe_ports port 443 # https
acl Safe_ports port 777 # multiling http
acl CONNECT method CONNECT
http_port 3128
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access deny to_localhost
http_access allow localnet
http_access deny all
http_reply_access allow all
Is what we want to do currently achievable with the latest 3.5 branch
or have we misunderstood what Amos was stating (some of his posts
about ssl interception and cache_peer support can be fairly cryptic)?
If it is achievable, does the cache_peer link itself also need to be
encrypted (via the ssl flag) to make it work?
Thanks,
Charlie
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users
