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@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
