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

[Mihai Ene]

> Since Squid does not (yet) generate new outgoing CONNECT requests to
cache_peer's it cannot tunnel through a non-TLS peer to a server on the
other side.

I see. This is an undocumented and unexpected restriction of cache_peer.
The cache_peer documentation should mention that the `ssl` option is
mandatory when the peer is being used after an `ssl_bump`.

Thank you for all your help, i've learned a lot :)

*Mihai Ene*
Software Developer

*UB | Your universal basket*

http://ub.io
me at ub.io
@shop_ub
+44 (0)7473 804972 <+447473804972>

On Tue, Jul 19, 2016 at 7:54 AM, Amos Jeffries <squid3 at treenet.co.nz> wrote:

> On 19/07/2016 3:19 a.m., Mihai Ene wrote:
> > Your details helped me understand a lot better.
> >
> > It turns out squid correctly adds the header to the CONNECT request, when
> > that request is made to another proxy. It cannot be itself,
> unfortunately,
> > because then it complains about a loop.
> >
> > Also unfortunately, your suggestion of doing `ssl-bump` on the http port
> > doesn't work because the squid process terminates with a failed assertion
> > when using cache_peer, it seems to be this bug
> > http://bugs.squid-cache.org/show_bug.cgi?id=3963 , which I get during
> with
> > my squid 3.5.20 `2016/07/18 15:07:50.566| assertion failed:
> > PeerConnector.cc:116: "peer->use_ssl"`.
> >
>
> That is becasue your config is then requiring Squid to fetch the TLS
> certificate details from a non-TLS cache_peer.
>
> Since Squid does not (yet) generate new outgoing CONNECT requests to
> cache_peer's it cannot tunnel through a non-TLS peer to a server on the
> other side.
>
> To fetch and mimic the server TLS certificate, Squid has to connect to
> the/a server using TLS. Preferrably the server listed in DNS for the
> domain being requested.
>
>
> NP: It is worth noting that this same cache_peer being non-TLS issue is
> affecting any of the intercepted port 443 traffic which is denied from
> going direct to a server and only allowed through the cache_peer. You
> will continue to see it sometimes regardless of the http_port settings.
>
>
> > Config used:
> >
> > ```
> > http_port 8000 ssl-bump generate-host-certificates=on
> > dynamic_cert_mem_cache_size=16MB cert=/etc/squid/ca.crt
> > key=/etc/squid/ca.key dhparams=/etc/squid/dh2048.pem options=NO_SSLv3
> >
> > sslcrtd_program /usr/lib/squid/ssl_crtd -s /var/lib/squid_ssl_db -M 32MB
> > sslcrtd_children 32
> > acl step1 at_step SslBump1
> > ssl_bump peek step1
> > ssl_bump bump all
> >
> > never_direct allow all
> >
> > cache_peer 192.71.64.174 parent 6745 0 no-query no-digest default
> >
> > http_access allow all
> > ```
> >
> > Considering the fact that I can't do `ssl-bump` on http port because of
> the
> > `peer-use_ssl` assertion (bug linked above), also considering the fact
> that
> > squid :8000 using itself as a proxy :8443 complains about a proxy loop,
> are
> > there any other options I might have to use ssl_bump *with* multiple
> > cache_peer, and cache_peer selection based on proxy_auth and/or
> req_header?
> >
>
> In curent Squid releases the peers need to be receiving TLS connections
> in order for decrypted traffic to be delivered there.
>
>
> Otherwise:
> <
> http://wiki.squid-cache.org/SquidFaq/AboutSquid#How_to_add_a_new_Squid_feature.2C_enhance.2C_of_fix_something.3F
> >
>
> Amos
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160719/3183886e/attachment-0001.html>