<div dir="ltr">> <span style="font-size:12.8px">Since Squid does not (yet) generate new outgoing CONNECT requests to</span><br style="font-size:12.8px"><span style="font-size:12.8px">cache_peer's it cannot tunnel through a non-TLS peer to a server on the</span><br style="font-size:12.8px"><span style="font-size:12.8px">other side.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">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`.</span></div><div><br></div><div>Thank you for all your help, i've learned a lot :)</div><div class="gmail_extra"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br><b>Mihai Ene</b><div><font color="#999999">Software Developer</font></div><div><font color="#999999"><br></font></div><div><b style="color:rgb(153,153,153);font-size:12.8000001907349px">UB | Your universal basket</b></div><div><font color="#999999"><br></font></div><div><font color="#999999"><a href="http://ub.io" target="_blank">http://ub.io</a></font></div><div><font color="#999999"><a href="mailto:me@ub.io" target="_blank">me@ub.io</a></font></div><div><span style="font-size:small">@shop_ub</span><br></div><div><font color="#999999"><a href="tel:+447473804972" value="+447881904476" target="_blank">+44 (0)7473 804972</a></font></div></div></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">On Tue, Jul 19, 2016 at 7:54 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 19/07/2016 3:19 a.m., Mihai Ene wrote:<br>
> Your details helped me understand a lot better.<br>
><br>
> It turns out squid correctly adds the header to the CONNECT request, when<br>
> that request is made to another proxy. It cannot be itself, unfortunately,<br>
> because then it complains about a loop.<br>
><br>
> Also unfortunately, your suggestion of doing `ssl-bump` on the http port<br>
> doesn't work because the squid process terminates with a failed assertion<br>
> when using cache_peer, it seems to be this bug<br>
> <a href="http://bugs.squid-cache.org/show_bug.cgi?id=3963" rel="noreferrer" target="_blank">http://bugs.squid-cache.org/show_bug.cgi?id=3963</a> , which I get during with<br>
> my squid 3.5.20 `2016/07/18 15:07:50.566| assertion failed:<br>
> PeerConnector.cc:116: "peer->use_ssl"`.<br>
><br>
<br>
</span>That is becasue your config is then requiring Squid to fetch the TLS<br>
certificate details from a non-TLS cache_peer.<br>
<br>
Since Squid does not (yet) generate new outgoing CONNECT requests to<br>
cache_peer's it cannot tunnel through a non-TLS peer to a server on the<br>
other side.<br>
<br>
To fetch and mimic the server TLS certificate, Squid has to connect to<br>
the/a server using TLS. Preferrably the server listed in DNS for the<br>
domain being requested.<br>
<br>
<br>
NP: It is worth noting that this same cache_peer being non-TLS issue is<br>
affecting any of the intercepted port 443 traffic which is denied from<br>
going direct to a server and only allowed through the cache_peer. You<br>
will continue to see it sometimes regardless of the http_port settings.<br>
<span class=""><br>
<br>
> Config used:<br>
><br>
> ```<br>
> http_port 8000 ssl-bump generate-host-certificates=on<br>
> dynamic_cert_mem_cache_size=16MB cert=/etc/squid/ca.crt<br>
> key=/etc/squid/ca.key dhparams=/etc/squid/dh2048.pem options=NO_SSLv3<br>
><br>
> sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/squid_ssl_db -M 32MB<br>
> sslcrtd_children 32<br>
> acl step1 at_step SslBump1<br>
> ssl_bump peek step1<br>
> ssl_bump bump all<br>
><br>
> never_direct allow all<br>
><br>
> cache_peer 192.71.64.174 parent 6745 0 no-query no-digest default<br>
><br>
> http_access allow all<br>
> ```<br>
><br>
> Considering the fact that I can't do `ssl-bump` on http port because of the<br>
> `peer-use_ssl` assertion (bug linked above), also considering the fact that<br>
> squid :8000 using itself as a proxy :8443 complains about a proxy loop, are<br>
> there any other options I might have to use ssl_bump *with* multiple<br>
> cache_peer, and cache_peer selection based on proxy_auth and/or req_header?<br>
><br>
<br>
</span>In curent Squid releases the peers need to be receiving TLS connections<br>
in order for decrypted traffic to be delivered there.<br>
<br>
<br>
Otherwise:<br>
<<a href="http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F" rel="noreferrer" target="_blank">http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F</a>><br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
<br>
</font></span></blockquote></div><br></div></div>