[squid-users] Wrong req_header result in cache_peer_access when using ssl_bump

[Amos Jeffries]

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 ]