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

[Alex Rousskov]

On 09/12/2018 09:02 PM, Julian Perconti wrote:

> ssl_bump peek step1
> ssl_bump peek noBumpSites
> ssl_bump stare all

>>>> ssl_bump peek noBumpSites # As there no step specified, squid match
>>>> at any step

>> Not exactly. Squid will evaluate this rule at any step that (a) reaches
>> this line and (b) where the peek action is applicable. The intersection
>> of those two preconditions is "step2" rather than "any step".

> Ok, say that the most (not to say the *only*) important beyond any step or action is the *secuential order -line_by_line-* of the rules (steps) .
> 
> Example:
> 
>   ssl_bump splice noBumpSites # this will be totally ignored by Squid if a stare rule precedes this.

No, this is incorrect. There are many cases were a previous stare rule
will not have the effect you state it will. For example:

  # Squid may splice at step2 despite the preceding stare rule
  # because staring at step1 does not preclude splicing.

  ssl_bump stare step1
  ssl_bump splice noBumpSites

and

  # Squid will splice at step1 despite the preceding stare rule
  # because the preceding stare rule never matches
  ssl_bump stare !all
  ssl_bump splice all


> ssl_bump stare noBumpSites # No matter what, here is the Squid first
> match and he is at step1...

> ssl_bump splice noBumpSites # ...Therefore here Squid is at step2,
> then this line will never match, even not having specified the step
> in both lines, because "noBumpSites" was already stared at first
> line.
You seem to be assuming that the action during the previous step is
important even if the rule with that action did not match during the
previous step. That is incorrect. The previous step action may be
important only if it was actually used during that previous step (i.e.
Squid reached that action's rule and that rule's ACLs matched).


> if in case that an implicit stare occurs at step2 due to first line,
> then squid will [...] never-match/ignore the second line completely.

That is correct. The part in [...] was a bit misleading because it
depended on the not shown (default?) rules, so I removed it.



> Resume: Implicit splice and bump exists aalways exists. Implicit peek, no. Is this correct?

There are ways to interpret this statement correctly, but I would not
phrase it this way.

A better statement would be that when no rule matched at a given step,
Squid uses the default rule. The default rule is "bump" if Squid stared
at the previous step. The default rule is "splice" in all other cases,
including the case where no rule matched during the first step (i.e.
there was no "previous step").


>> Adding "all" to any line changes nothing as far as line matching is
>> considered. The value of "foo and true" is equivalent to the value of "foo".
> 
> So the word "all" makes sense if its is "alone"?

The documented ssl_bump line syntax requires an ACL. If you want a rule
to always match, use an "all" ACL. Ideally, the syntax should be relaxed
to not require an ACL at all in those cases. I did not check whether the
implementation matches the documentation.


> e.g.: ssl_bump peek step1 all = ssl_bump peek step1, *always*?

Yes, as far as rule matching is concerned. The "all" ACL always matches.


>> if your configuration has a "stare"
>> and/or "bump" actions, it is "insecure". If your configuration may lead
>> to certificate validation errors, it is also "insecure".

> Does not the splice at step1 and step2 action avoid this? I mean if
> squid act as a -TCP forward proxy only- for noBumpSites. "Don't touch
> TLS bytes"

I am not sure what you mean by "this" exactly, but splicing (at any
step) does not guarantee the lack of errors. The earlier you tell Squid
to splice the connections, the fewer checks Squid will do, decreasing
the probability of an error. Errors lead to bumping the client
connection (to deliver the error message).


>>> When I do this:
>>>
>>> ssl_bump splice noBumpSites
>>> ssl_bump stare all
>>
>>> It is supposed that in this config I am (guessing), implicity,
>>> peeking  (first?) and splice at any step and bumping (implicity) at
>>> step3 sites that does not match with whitelist by staring at step2.
>>> Maybe something like that, I dont know.
>>
>> I do not think your description of the above configuration is correct.
>> Squid uses default actions ("splice" or "bump") when no applicable rules
>> match. In the above configuration, one of the rules will always match
>> during step1 and during step2 (if any). Thus, there will be no implicit
>> splicing or bumping during the first steps. If Squid reaches step3, then
>> Squid will apply the default bump rule at that step (because "stare"
>> matched at the previous step).
>>
>> I am not sure, but I think the above configuration is equivalent to the
>> following configuration that does not rely on default rules:
>>
>>   ssl_bump splice step1 noBumpSites
>>   ssl_bump splice step2 noBumpSites
>>   ssl_bump stare step1
>>   ssl_bump stare step2
>>   ssl_bump bump step3

> According to Amos: Always is better to be explicit and bump at step3
> after stare at step2. (And of course more clearly to understand)

That "always better to be explicit" recipe fails when you cannot tell (a
priori) what the previous step result was. In those cases, you may want
to rely on the default rules (after making sure they work) OR rewrite
the configuration so that you know for sure what the previous step
result was. In the two-line configuration above, we always know what the
previous step result was, so it is possible to add an explicit (and
correct) step3 action.

Which configuration is clearer depends on the observer. Use whatever
correct variant looks best to _you_.


> BUT here you are never peek'ing? How is that? 

Staring at step1 performs the same actions as peeking at step1. The only
difference is the side effect on the default rules choice for step2 (if
Squid needs to make that choice). In both of the above configurations,
there is no need for Squid to make that choice for step2.


Alex.