[squid-users] Problems with peek and slice through parent proxy

[Amos Jeffries]

On 12/07/18 01:43, Kedar K wrote:
> 
> 
> On Wed, Jul 11, 2018 at 7:03 PM Hess, Niklas wrote:
> 
>     Hello list,____
> 
>     __ __
> 
>     I´m setting up a Squid proxy specifically to scan the incoming
>     traffic from a cloud platform.____
> 

Please clarify what "incoming" means to you. Is the cloud platform
generating request messages or supplying the responses?

The HTTP definition of in/out is oriented with request flow. ie from the
origin server point of view, *opposite* to what an ISP would describe it as.



>     ClamAV should scan the incoming traffic.____
> 
>     __ __
> 
>     So far so good.____
> 
>     __ __

May appear to be, but your displayed config is absolutely *not* "all
good". Details below.


> 
>     The cloud uses WebDAV over HTTPS, so I have to SSL-Bump the incoming
>     traffic via Peek and Splice Feature.____
> 

Then do so. The config you show below is not peek+splice.

It is "bump all" which is the old client-first behaviour.


>     That works indeed with the CA signed internal Certificate.____
> 

Ah, if by CA you mean one of the global "Trusted CA". Then you probably
should not be using SSl-Bump at all. That is a feature for
forward/explicit proxy to access.

Otherwise if your CA is a self-signed/generated one then of course it
"works". All SSL-Bump variants use that type of CA certificate.


>     __ __
> 
>     But as soon as I add a cache_peer as a “parent proxy” it does not
>     work. (This request could not be forwarded to the origin server or
>     to any parent caches.)____
> 
>     I just get “FwdState.cc(813) connectStart: fwdConnectStart: Ssl
>     bumped connections through parent proxy are not allowed” in the
>     cache.log____
> 
>     __ __
> 
>     And yes I know ssl-bump through a parent proxy is an security issue
>     and might be unsecure, but the connection to the parent is internal,
>     save and secure.____
> 

Don't count on that. You configured an open proxy. Anyone who can open a
TCP connection to it pretty much has wide-open (and anonymized) access
to all your LAN internal services.

The decision to do that, even for testing, implies a potential for holes
which does not bode well.



>     I don’t know how, but could there be a way to “comment out” the
>     section in fwdConnectStart source file?____
> 

You cannot comment out a *lack* of something. That is the problem here.
There is no TLS on this peer's connection, so no server-cert exists for
Squid to copy/forge in what it is sending the client. More on that below.


>     __ __
> 
>     Squid Cache: Version 3.5.27____
> 
>     Service Name: squid____
> 
>     configure options:  '--with-openssl' '--enable-ssl-crtd'____
> 
>     __ __
> 
>     __ __
> 
>     Here´s my “minimal” SSL-Bump config:____
> 
>     __ __
> 
>     ### Start config____
> 
>     __ __
> 
>     debug_options ALL,6____
> 
>     shutdown_lifetime 1 seconds____
> 
>     __ __
> 
>     http_port 8080 ssl-bump
>     cert=/usr/local/squid/etc/ssl_cert/Squidtest.pem
>     generate-host-certificates=on dynamic_cert_mem_cache_size=4MB____
> 
>     __ __
> 
>     sslcrtd_program /usr/local/squid/libexec/ssl_crtd -s /var/lib/ssl_db
>     -M 4MB____
> 
>     sslcrtd_children 25 startup=5 idle=10____
> 
>     __ __
> 
>     cache_peer 10.106.3.66 parent 8080 0 no-query no-digest name=parent____
> 

The connection to this peer is not secured. TLS (thus HTTPS) traffic is
required to remain secure on outbound connections.
 Note that this does *not* mean it has to remain HTTPS - but it cannot
be plain-text HTTP like the above peer connection. Currently the only
security protocol cache_peer supports is TLS/SSL, so the "ssl" (v2.6 -
v3.5) or "tls" options (v4.0+) is required.

Also, the outgoing server cert is what Squid bases its forged
serverHello certificate on. So there are major problems added when the
cache_peer certificate is different from the origin servers one.

The ideal way to relay SSL-Bumped traffic between proxies is currently
to let Squid re-encrypt it. Then to repeat the NAT intercept directing
Squids outbound connections into the second proxy.

IIRC, Measurement Factory have an ongoing project adding ability for
Squid to generate CONNECT messages which will make cache_peer links work
better. But even so the second proxy will still have to do its own
SSL-Bump on the crypted traffic, because we *have* to get the origin
server cert parameters through the whole chain to the client for the TLS
to work properly.


>     __ __
> 
>     never_direct allow all____
> 
>     __ __
> 
>     sslproxy_cert_error allow all____
> 
>     sslproxy_flags DONT_VERIFY_PEER____
> 

Don't do this. Ever. It actively disables all the security which is the
whole point of TLS existence. Rendering any tests which you may do to
check for "working" invalid.

The server/peer could emit random garbage bytes in a syntax layout
resembling a TLS handshake and this Squid would blithely say "okay" and
send it the clients private data. While telling the client *and you*
that everything was find and working properly. So not even useful for
troubleshooting.


>     __ __
> 
>     ssl_bump bump all
> 
> ​Did you forget to copy at_step acls?
> 
> acl step1 at_step SslBump1
> acl step2 at_step SslBump2
> acl step3 at_step SslBump3
> ​

That alone won't help here. "acl ..." lines are simply telling Squid
what to test *for*, not when to test nor any action that test should
result in.

What is needed is an actual policy on what needs to happen, in terms of
these TLS handshake stages. From that you should be able to craft
ssl_bump rules to enact that policy.

The actual minimal is:

 ssl_bump splice all

A more usual splice for troubleshooting is:

 ssl_bump peek all
 ssl_bump splice all

 - which tells Squid to look at (peek) all stages of the handshake which
can be looked at, without doing any changes, then to splice (opaque
tunnel) the crypted data portion.


The minimal to decrypt is:

 acl step1 at_step SslBump1
 ssl_bump peek step1
 ssl_bump stare all
 ssl_bump bump all

- which tells Squid to look at clientHello in the TLS handshake, and
look at the serverHello part while filtering out any features that
prohibit bump, then decrypt the crypted portion.


>     __ __
> 
>     http_access allow all____
> 

Another don't.

Please keep the default http_access lines we provide as recommended
rules. Add whatever you need at the point the default config file says
"INSERT YOUR OWN RULE(S) HERE".

Restrictions should be based on what the LAN is (for ISP proxies), or on
what domains being serviced are (for CDN / reverse-proxy).


Amos