On 11/15/2015 11:13 PM, Eugene M. Zheganin wrote: > On 16.11.2015 00:39, Alex Rousskov wrote: >> Squid currently supports two kinds of CONNECT tunnels: >> >> 1. A regular opaque tunnel, as intended by HTTP specifications. >> >> 2. An inspected tunnel containing SSL/TLS-encrypted HTTP traffic. >> >> Opaque tunnels are the default. Optional SslBump-related features allow >> the admin to designate admin-selected CONNECT tunnels for HTTPS >> inspections (of various depth). This distinction explains why and when >> Squid expects "HTTPS inside". > Seems like the lack of understanding is my main problem. I read > Peek/Splice article in wiki on an on, but I just cannot catch it: > > - are the sslBump directives evaluated in order and does the order > matter (I assume it does) ? Yes and yes. This is described in squid.conf.documented IIRC. > - (the most difficult thing to understand) I just cannot understand the > "step1" approach. I can understand splice/bump thing - it's like we > splice or we bump. I cannot understand other stepX-related actions, what > they do and when do I need'em (and when I do not). The wiki describes what each step and each action does. I understand that those descriptions may not be sufficient. Better documentation is welcomed, and you are encouraged to ask specific questions to provide that "better documentation" to yourself and others. You are in a better position to improve documentation than I am! > - I cannot understand what is the relation between http_access and > sslBump, and I assume there is one. This is poorly documented indeed. For some additional info, see Squid bug 4340 summary: http://bugs.squid-cache.org/show_bug.cgi?id=4340 > When I first discovered sslBump I > thought I will be able to block HTTP objects inside HTTPS session - like > pictures, or particular scripts, or particular MIME types, and it seems > like I was able to do that, Sure, you can block messages inside a bumped inspected tunnel. Once the tunnel is bumped (not spliced!), it works almost like a regular HTTP message stream (but there are exceptions like authentication and peer selection). Most difficulties are related to blocking tunnelling attempts themselves. In other words, blocking CONNECT messages (at various bumping stages before the tunnel is bumped). > For example this number of directives is straightforward: > > ===Cut=== > acl foo dst 192.168.0.1 > acl bar dst 192.168.0.2 > > sslBump bump foo > sslBump splice bar > ===Cut=== > > It's one dst we bump and the other we splice. The above configuration is not as "straightforward" as you might think: * If you are dealing with real CONNECT requests (not intercepted tunnels), a real CONNECT request may be for a host name and Squid will need to look up the IP address. This may affect dst matching. * You did not tell Squid what to do when neither dst matches. There were bugs in this area. The latest Squids should splice (but if you add more ssl_bump rules, they may affect the default action). IIRC, this is described in squid.conf.documented. * Bumping (even at step1) requires SSL/TLS validations of various kinds. Those validations may lead to errors. * Bumping at step1 may be subject to the following Squid bug: http://bugs.squid-cache.org/show_bug.cgi?id=4327 > Can you describe a situation when I need to peek or stare? You need to peek or stare if you need SSL/TLS handshake information to make a final bump/splice/terminate/block decision. For example, * Your ACLs need host names, not IP addresses. Even in a forwarding environment (i.e., real CONNECT requests), host names may not be available without peeking or staring (or reverse DNS lookups, but those are rarely reliable). * Your ACLs need origin server certificate details. * You do not want to splice connections to origin servers that have revoked SSL certificates. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
