Re: Clarity on sending intercepted HTTPS traffic upstream to a cache_peer

[Charlie Orford <charlie@xxxxxxxxxx>]

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

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users