<div dir="ltr">> <span style="font-size:12.8px">Squid SHOULD be able to send SSL-bump decrypted traffic to a cache_peer</span><br style="font-size:12.8px"><span style="font-size:12.8px">with 'ssl' flag set.</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">But squid's source code says otherwise: <a href="https://github.com/squid-cache/squid/blob/23f981d410009ba5aee455144d18b4178d042b34/src/FwdState.cc#L816">https://github.com/squid-cache/squid/blob/23f981d410009ba5aee455144d18b4178d042b34/src/FwdState.cc#L816</a></span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Besides, I'm seeing that `debugs` output on line 819 in my logs when testing with an ssl enabled cache_peer.</span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div></div><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><br><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 Wed, Jul 20, 2016 at 1:32 PM, 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 20/07/2016 2:37 a.m., Mihai Ene wrote:<br>
> I did some further testing, and it would appear that even when `cache_peer`<br>
> uses `ssl` option, ERR_CANNOT_FORWARD is returned.<br>
><br>
> I believe `cache_peer` ACLs are incompatible with `ssl_bump`ed traffic.<br>
><br>
> These restrictions should be documented. I'd be happy to contribute to the<br>
> docs, but the procedure either seems too complicated, or the `man` pages<br>
> aren't the place. Anyway, contributing should be a separate thread.<br>
><br>
> Can a maintainer confirm that `cache_peer` does not work with `ssl_bump`ed<br>
> traffic, even when `ssl` option is used?<br>
><br>
<br>
</span>I can confirm the following ...<br>
<br>
 Squid SHOULD be able to send SSL-bump decrypted traffic to a cache_peer<br>
with 'ssl' flag set.<br>
<br>
<br>
The requirement Squid is enforcing is that the decrypted traffic is only<br>
ever transmitted over secure (ie TLS) connections. As long as the peer<br>
connection meets that criteria, it should be fine.<br>
<br>
Two gotcha's though when using peers:<br>
<br>
 1) if your bumping at step 3, it involves the serverHello details.<br>
Squid will mimic the *peer certificate*. Which may not be the origin<br>
server certificate the client expects to see.<br>
<br>
 2) if your bumping is at step 1 or 2, it involves only the clientHello<br>
details, no server cert. Then the client will receive the *Squid<br>
certificate*, which is almost certainly not what the client expects to see.<br>
<br>
<br>
As to your error message. ERR_CANNOT_FORWARD is an indication that your<br>
rules prevent any accessible destination. In other words, the ones<br>
permitted are not responding.<br>
<br>
Amos<br>
[ maintainer hat usually on when responding here :-P ]<br>
<br>
</blockquote></div><br></div>