I did some further testing, and it would appear that even when `cache_peer` uses `ssl` option, ERR_CANNOT_FORWARD is returned.
I believe `cache_peer` ACLs are incompatible with `ssl_bump`ed traffic.
These restrictions should be documented. I'd be happy to contribute to the docs, but the procedure either seems too complicated, or the `man` pages aren't the place. Anyway, contributing should be a separate thread.
Can a maintainer confirm that `cache_peer` does not work with `ssl_bump`ed traffic, even when `ssl` option is used?
On Tue, Jul 19, 2016 at 10:47 AM, Mihai Ene <me@xxxxx> wrote:
> 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.I see. This is an undocumented and unexpected restriction of cache_peer. The cache_peer documentation should mention that the `ssl` option is mandatory when the peer is being used after an `ssl_bump`.Thank you for all your help, i've learned a lot :)On Tue, Jul 19, 2016 at 7:54 AM, Amos Jeffries <squid3@xxxxxxxxxxxxx> wrote: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
_______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
