[squid-users] Clarity on sending intercepted HTTPS traffic upstream to a cache_peer

Charlie Orford charlie at charlie.is
Fri Jan 27 18:24:17 UTC 2017


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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20170127/de795d81/attachment.html>


More information about the squid-users mailing list