<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-text-flowed" style="font-size: 17px;"
lang="x-unicode">Hi list
<br>
<br>
We're using squid 3.5.23 and trying to achieve the following:
<br>
<br>
client https request (not proxy aware) -> squid1 (https NAT
intercept) -> upstream squid2 (configured as a cache_peer in
squid1) -> origin server (e.g. <a
class="moz-txt-link-abbreviated" href="http://www.google.com">www.google.com</a>)
<br>
<br>
Amos mentioned in this thread <a class="moz-txt-link-freetext"
href="http://lists.squid-cache.org/pipermail/squid-users/2016-March/009468.html">http://lists.squid-cache.org/pipermail/squid-users/2016-March/009468.html</a>
that:
<br>
<br>
> Squid can:
<br>
>
<br>
> A) relay CONNECT message from client to any upstream proxy.
<br>
>
<br>
> B) generate CONNECT message on arriving intercepted HTTPS
and relay
<br>
> that to upstream proxy <b class="moz-txt-star"><span
class="moz-txt-tag">*</span>IF<span class="moz-txt-tag">*</span></b>
(and only if) ssl_bump selects the 'splice'
<br>
> action.
<br>
>
<br>
> C) relay <a class="moz-txt-link-freetext" href="https://">https://</a>
URLs to an upstream TLS proxy.
<br>
>
<br>
>
<br>
> That is all at present.
<br>
>
<br>
> Squid cannot (yet) generate CONNECT messages to try and fetch
TLS
<br>
> details via a non-TLS cache_peer. If you are able to sponsor
that
<br>
> enhancement work patches are welcome, or sponsorship $$ to
help pay
<br>
> persons working on these things (Christos /
measurement-factory) are
<br>
> also welcome.
<br>
<br>
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
<br>
<br>
Relevant config for squid1:
<br>
######################################
<br>
acl localnet src 10.100.0.0/24
<br>
acl SSL_ports port 443
<br>
acl Safe_ports port 80 # http
<br>
acl Safe_ports port 443 # https
<br>
acl Safe_ports port 777 # multiling http
<br>
acl CONNECT method CONNECT
<br>
acl Blocked_domains dstdomain "/etc/squid3/blocked.domains.acl"
<br>
acl step1 at_step SslBump1
<br>
acl step2 at_step SslBump2
<br>
acl step3 at_step SslBump3
<br>
acl MITM_TRAFFIC myportname MITM_port
<br>
<br>
http_access allow manager localhost
<br>
http_access deny manager
<br>
http_access deny !Safe_ports
<br>
http_access deny CONNECT !SSL_ports
<br>
http_access deny to_localhost
<br>
http_access deny Blocked_domains
<br>
http_access allow localhost
<br>
http_access allow localnet
<br>
http_access deny all
<br>
http_reply_access allow all
<br>
<br>
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
<br>
sslcrtd_program /usr/lib/squid3/ssl_crtd -s /var/lib/squid3/ssl_db
-M 4MB
<br>
<br>
ssl_bump peek all
<br>
ssl_bump splice all
<br>
<br>
nonhierarchical_direct off
<br>
never_direct allow all
<br>
prefer_direct off
<br>
cache_peer 192.168.0.1 parent 3128 0 no-query no-digest
no-netdb-exchange name=WWW_GATEWAY
<br>
<br>
<br>
Relevant config for squid2:
<br>
######################################
<br>
acl localnet src 192.168.0.0/24
<br>
acl SSL_ports port 443
<br>
acl Safe_ports port 80 # http
<br>
acl Safe_ports port 443 # https
<br>
acl Safe_ports port 777 # multiling http
<br>
acl CONNECT method CONNECT
<br>
<br>
http_port 3128
<br>
<br>
http_access allow manager localhost
<br>
http_access deny manager
<br>
http_access deny !Safe_ports
<br>
http_access deny CONNECT !SSL_ports
<br>
http_access deny to_localhost
<br>
http_access allow localnet
<br>
http_access deny all
<br>
<br>
http_reply_access allow all
<br>
<br>
<br>
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)? <br>
<br>
If it is achievable, does the cache_peer link itself also need to
be encrypted (via the ssl flag) to make it work?<br>
<br>
Thanks,
<br>
Charlie
<br>
<br>
<br>
<br>
</div>
</body>
</html>