Hi. On 16.11.2015 00:39, Alex Rousskov wrote: > Hello Eugene, > > 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". > > There is currently no decent support for inspecting CONNECT tunnels > other than SSL/TLS-encrypted HTTP (i.e., HTTPS) tunnels. > > Splicing a tunnel at SslBump step1 converts a to-be-inspected tunnel > into an opaque tunnel before inspection starts. > > The recently added on_unsupported_protocol directive can automatically > convert being-inspected non-HTTPS tunnels into opaque ones in some > common cases, but it needs more work to cover more cases. > > > AFAICT, you assume that "splicing" turns off all tunnel inspection. This > is correct for step1 (as I mentioned above). This is not correct for > other steps because they happen after some inspection already took > place. Inspection errors that on_unsupported_protocol cannot yet handle, > may result in connection termination and other problems. > > > If Squid behavior contradicts some of the above rules, it is probably a > bug we should fix. Otherwise, it is likely to be a missing feature. > > > Finally, if Squid kills your ICQ (non-HTTPS) client tunnels, you need to > figure out whether those connections are inspected (i.e., go beyond > SslBump step1). If they are inspected, then this is not a Squid bug but > a misconfiguration (unless the ACL code itself is buggy!). If they are > not inspected, then it is probably a Squid bug. I do not have enough > information to distinguish between those cases, but I hope that others > on the mailing list can guide you towards a resolution given the above > information. 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) ? - (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). - I cannot understand what is the relation between http_access and sslBump, and I assume there is one. 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, But now things became complicated in my head, I can't even reproduce my past results, I'm starting to think that this was an illusion of success. Could you clarify things a bit ? 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. Can you describe a situation when I need to peek or stare ? Thanks. Eugene. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
