[squid-users] About SSL peek-n-splice/bump configurations

[Julian Perconti]

> > 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.