> Squid SHOULD be able to send SSL-bump decrypted traffic to a cache_peer with 'ssl' flag set.
But squid's source code says otherwise: https://github.com/squid-cache/squid/blob/23f981d410009ba5aee455144d18b4178d042b34/src/FwdState.cc#L816 Besides, I'm seeing that `debugs` output on line 819 in my logs when testing with an ssl enabled cache_peer. *Mihai Ene* Software Developer *UB | Your universal basket* http://ub.io m...@ub.io @shop_ub +44 (0)7473 804972 <+447473804972> On Wed, Jul 20, 2016 at 1:32 PM, Amos Jeffries <squ...@treenet.co.nz> wrote: > On 20/07/2016 2:37 a.m., Mihai Ene wrote: > > 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? > > > > I can confirm the following ... > > Squid SHOULD be able to send SSL-bump decrypted traffic to a cache_peer > with 'ssl' flag set. > > > The requirement Squid is enforcing is that the decrypted traffic is only > ever transmitted over secure (ie TLS) connections. As long as the peer > connection meets that criteria, it should be fine. > > Two gotcha's though when using peers: > > 1) if your bumping at step 3, it involves the serverHello details. > Squid will mimic the *peer certificate*. Which may not be the origin > server certificate the client expects to see. > > 2) if your bumping is at step 1 or 2, it involves only the clientHello > details, no server cert. Then the client will receive the *Squid > certificate*, which is almost certainly not what the client expects to see. > > > As to your error message. ERR_CANNOT_FORWARD is an indication that your > rules prevent any accessible destination. In other words, the ones > permitted are not responding. > > Amos > [ maintainer hat usually on when responding here :-P ] > >
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
