On 05/26/2017 05:22 PM, Vieri wrote: > If I have this: > > ssl_bump peek all > ssl_bump splice AllowTroublesome > ssl_bump bump all ... then you have a configuration that does not make sense because one cannot bump after peeking at step2. Your configuration is equivalent to * if the current step is 1 or 2, then peek * if AllowTroublesome during step 3, then splice * otherwise, do the impossible which, bugs notwithstanding, is equivalent to ssl_bump peek all ssl_bump splice all If the above does not block anything then your http_access rules allow all CONNECTs (and you never get beyond CONNECTs because you do not bump). > If I replace the above snippet with this: > > ssl_bump stare all > ssl_bump bump all This configuration makes sense (but it may not do what you want). If you want to be able to make a "splice or bump" decision, then you have to make it during step2: ssl_bump peek step1 ssl_bump splice AllowTroublesome ssl_bump bump all > If I had an http_access rule that allowed the transaction to take > place then I would expect it to happen regardless of the ssl_bump > directive. Your expectations are wrong. SslBump directives expose http_access rules to more (or fewer) transactions. For example, the "splice all" configuration does not expose http_access rules to any GET requests. > Alex, you mention the SSLPeekAndSplice web page. I'll try to sum it > up in just a few lines The SslBump feature is too complex to sum it up in just a few lines unless those lines are something like "do not use it without fully understanding it". Once you learn the basics of SSL handshake, which Squid steps look at what parts of the handshake, and what the essential difference between peeking and staring is, then SslBump becomes less of black magic. Without that knowledge, it is a dark mystery. > - peek implies splice which means you can't do content analysis (as > in scan for threats via c-icap modules) Wrong. Peeking at step1 does not preclude future bumping. Peeking at step2 precludes future bumping. If you peek at step2, then you have to splice or terminate at step3. > - stare implies bump which means you can do content analysis Wrong for similar/symmetrical reasons. > - you don't need to stare, you can just bump Wrong in many cases -- usually you _do_ need to stare (or peek) at least at step1, but YMMV. > - you need to stare before bump if you want the clients to accept a > certificate with domain names instead of IP addresses Misleading. You need to stare or peek to get more information, including the server domain name. That information comes from either the client or the server, depending on the step. That information is used to generate a fake certificate. The more info Squid has, the better it can fake/mimic the true certificate, but learning more information restricts the set of ssl_bump actions. > - you can bump first by ACLs and then splice the rest If you mean that ssl_bump rules may start with "bump" rules and end with "splice" rules, then this is true, but the reverse is also true, and the rules may contain a mixture of many actions. > - you can bump after peek but only if you do that at SslBump1 Too vague to be generally useful. You can bump after peeking at step1. You cannot bump after peeking at step2. > the "Bump All Sites Except Banks" example where the next > phrase contradicts the title by saying that the requests to non-banks > won't be bumped. Correct! The example, the title, and the warning were written by different people. One of them is right. If you know how SslBump works, you know which part is correct. At that time, please feel free to propose changes to fix the wiki page. Hundreds of folks receive SslBump help on this mailing list, but only one of them took the pains to improve the page afterwards (thank you again, Marcus Kool!). Parts of that page still need a lot of work. HTH, Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
