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

[Alex Rousskov]

On 09/22/2018 10:40 AM, Julian Perconti wrote:
>>> # Second rule:
>>> ssl_bump splice noBumpSites
>>>
>>> I think that this rule should implicity match only at step2.
>>
>> I do not know what "implicitly match" means here, but yes, the splice rule
>> may only match at step2 in this configuration:

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


>> * It cannot match at step3 because for a splice rule to match at step3 a peek
>> rule has to match at step2, and there is no peek rule that can match at step2
>> in your configuration.

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


> In fact, in case that (for any reason) the 2nd rule can not match,
> there is a explicit stare rule at step2.

Yes, and it will be applied, and it is not a peek rule, so this applied
staring action will prevent splicing at step3.


> So, I think that its almost impossible that splice at step3 happens
> in this configuration for the noBumpSites.

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.


> In the worst of the cases, if at rule #2 no match, then noBumpSites
> will be bumped, due to stare at step2.

Correct. There is nothing "worse" about this case though.


>>> In that case is clear "splice is a final action" then no more future checks.

>> The notion of a "final" action does not depend on rule ACLs.

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


> In the config I posted, there is a splice action in the middle, and
> only the "noBumpSites" are spliced

Yes.


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


> It is checked

Yes, it is checked at stepN when the previous rules do not match at (or
are not applicable to) that step.


>    ssl_bump splice noBumpSites = ssl_bump splice noBumpSites all.

Yes. Adding "and true" to any logical condition does not change that
condition. However, I fear that the above correct equivalence does not
mean what you think it means. It means there is no point in adding
"all". It does not mean that adding "all" changes the meaning of that
ssl_bump rule or of what you are saying.


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

Alex.