> > When I say "implicit" I want to mean that there is no any step specified in > the rule. > > Understood. Please avoid that word usage. In this context, implicit means > "without being configured" or "by default". One could say that "default rules > implicitly match", or that "a rule without any ACLs matches implicitly", but > one cannot say that "rule X containing ACL Y implicitly matched". OK and sorry for that. > > Althought there is no any peek rule at step2, in the second rule a > > final action is applied to noBumpSites (if match) > > Final actions at step2 do not matter when we are talking about what happens > at step3. If a final action is applied at step2, there is no > step3 as far as an ssl_bump configuration is concerned. Yes, when a final action is applied at step2, ssl_bump rules are over when the previous step (if it's a final action) has matched. > It is impossible for any transaction to be spliced at step3 with this > configuration. Whether the transaction matches or does not match > noBumpSites at any given step is irrelevant for this statement. OK: In this configuration it is impossible any kind of splice at step3; but not for step2. In fact, noBumpSites are being spliced (at least I can see the TCP_TUNNEL in logs). > Correct. There is nothing "worse" about this case though. With the term "worst" I wanted to mean that my intention is splice sites into the ACL (noBumpSites) , not bump. > > Here is where I your explanation breaks my head. Here is the most > > important confusion of all of my own other > > confusions/misunderstanding. > > Final actions are "bump", "terminate", and "splice". As you can easily see, this > statement does not depend on ACLs. > > An action is either final or not, by that action nature/definition. ACLs are one > of the precondition for applying an action, but ACLs do not affect action > "finality". Well, Yes. Strictly speaking final actions (and maybe any action) do not depend on the acl, let's say it is a natural function/behavior of Squid beyond any acl. However, when a final action is present in a rule and that rule contains an ACL, the final action will apply to that ACL. At least that is the behaviour I see. If not, Squid would not being splice'ing "noBumpSites" which is an ACL; as he is doing right now. I say good? > > And even with the splice action as second rule, the 3rd rule is > > processed (Squid is still processing rules after splice noBumpSites > > ACL). > > An action presence in the rules does not, on its own, stop Squid from > processing lower rules. *Applying* a final action does. So, why squid process the last rule which stare at step 2? He already applied the splice to the ACL sites. > >> After Squid applies the "splice" action (in whatever context, for > >> whatever reason), SslBump processing for that transaction is over. > >> Same for "bump" and "terminate" actions. > > > What do You exactly mean with "for that transaction"? Maybe that rule? > > No, I do not mean "that rule". In this context, "transaction" is, roughly > speaking, an "HTTP CONNECT request" or "TLS connection". An applied final > action stops all ssl_bump processing for the corresponding > transaction/request/connection, and not just one ssl_bump rule processing. > That difference is why those actions are called "final". OK, thank You for that clarification of misinterpreted terms. So going back to current config: ssl_bump peek step1 ssl_bump splice noBumpSites # I think that here the splice action is applied at step2. Even if there is no step specified. And due to previous rule. ssl_bump stare step2 Due to I think that: the splice action happens at step2 (more checks?), and not at step 1 (less checks); This is the config the one of best fit to my necessities. Quick reminder of the idea/need: In the most possible "secure" way: bump to all except banks and other sensitive sites; and less possible interference to that sensitive sites. Just a comment: Squid is working fine,but still the cache.log shows these kind or errors (quite annoying): kid1| Error negotiating SSL connection on FD 26: error:00000001:lib(0):func(0):reason(1) (1/-1) kid1| ERROR: negotiating TLS on FD 31: error:00000000:lib(0):func(0):reason(0) (5/-1/104) Always or almost always are only those two types of error [reason(1) (1/-1) - (0) (5/-1/104)] But that is another story. Apart nobody reports problems about the browsing. > Alex. Thank You, again. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
