[squid-users] Wrong req_header result in cache_peer_access when using ssl_bump

[Amos Jeffries]

On 19/07/2016 3:19 a.m., Mihai Ene wrote:
> Your details helped me understand a lot better.
> 
> It turns out squid correctly adds the header to the CONNECT request, when
> that request is made to another proxy. It cannot be itself, unfortunately,
> because then it complains about a loop.
> 
> Also unfortunately, your suggestion of doing `ssl-bump` on the http port
> doesn't work because the squid process terminates with a failed assertion
> when using cache_peer, it seems to be this bug
> http://bugs.squid-cache.org/show_bug.cgi?id=3963 , which I get during with
> my squid 3.5.20 `2016/07/18 15:07:50.566| assertion failed:
> PeerConnector.cc:116: "peer->use_ssl"`.
> 

That is becasue your config is then requiring Squid to fetch the TLS
certificate details from a non-TLS cache_peer.

Since Squid does not (yet) generate new outgoing CONNECT requests to
cache_peer's it cannot tunnel through a non-TLS peer to a server on the
other side.

To fetch and mimic the server TLS certificate, Squid has to connect to
the/a server using TLS. Preferrably the server listed in DNS for the
domain being requested.


NP: It is worth noting that this same cache_peer being non-TLS issue is
affecting any of the intercepted port 443 traffic which is denied from
going direct to a server and only allowed through the cache_peer. You
will continue to see it sometimes regardless of the http_port settings.


> Config used:
> 
> ```
> http_port 8000 ssl-bump generate-host-certificates=on
> dynamic_cert_mem_cache_size=16MB cert=/etc/squid/ca.crt
> key=/etc/squid/ca.key dhparams=/etc/squid/dh2048.pem options=NO_SSLv3
> 
> sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/squid_ssl_db -M 32MB
> sslcrtd_children 32
> acl step1 at_step SslBump1
> ssl_bump peek step1
> ssl_bump bump all
> 
> never_direct allow all
> 
> cache_peer 192.71.64.174 parent 6745 0 no-query no-digest default
> 
> http_access allow all
> ```
> 
> Considering the fact that I can't do `ssl-bump` on http port because of the
> `peer-use_ssl` assertion (bug linked above), also considering the fact that
> squid :8000 using itself as a proxy :8443 complains about a proxy loop, are
> there any other options I might have to use ssl_bump *with* multiple
> cache_peer, and cache_peer selection based on proxy_auth and/or req_header?
> 

In curent Squid releases the peers need to be receiving TLS connections
in order for decrypted traffic to be delivered there.


Otherwise:
<http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F>

Amos