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

[Mihai Ene]

> 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
me at ub.io
@shop_ub
+44 (0)7473 804972 <+447473804972>

On Wed, Jul 20, 2016 at 1:32 PM, Amos Jeffries <squid3 at 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 ]
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160720/96a6c887/attachment.html>