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

[Charlie Orford]

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 at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

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