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