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

[Alex Rousskov]

On 09/12/2018 08:28 AM, Julian Perconti wrote:


> Please, let me know if I understand why those cfg are equals

I am afraid you do not. You are probably missing the fact that, at each
step, the rules after the matching applicable rule are not checked.
Also, you seem to insert some implicit peeking rules that are never
there. Finally, there may be some confusion regarding how multiple ACLs
on one line are evaluated (and/or you do not think that stepN is just an
ACL?). Details below.


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


>>   ssl_bump peek step1  # implicit "all" at step1

Yes, if you wish to think about it that way. In reality, the condition
is exactly "step1", rather than "step1 and all" or "step1 and true".


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


> then this line, match at step1 

No, this line will not be evaluated at step1. Only the first rule is
evaluated at step1 (because that first rule always matches at step1).


> and then at step2, so when a match occurs at step2 it precludes future bumping of the sites listed in the ACL.

Yes, but that is kind of irrelevant here because there are no bump rules
to exclude. At step3, this previous/step2 peeking should result in Squid
applying the default "splice" rule (you can view that as excluding the
default "bump" rule if you wish).


>> ssl_bump stare all # Here there is either no step2 (and any step)
>> specified but, because in the previous line You has (implicitly)
>> peeked at step2, the stare'ing not (or can´t) applies to sites
>> listed in ACL (they were peeked at step2).

Something like that. Step2 always happens in this configuration (so "no
step2" does not make sense), and there is no such thing as "implicit
peeking", but I think you more-or-less got the right idea here.


> ssl_bump peek noBumpSites
> ssl_bump stare all


>> ssl_bump peek noBumpSites # Like previous example, but..I guess
>> that as there is no "all" explicit, this line do a "peek all at
>> step1" (implicitly)

No, this line does not do "peek all". It does "peek noBumpSites". That
is, it tells Squid to peek when and only when both of the conditions
below are true:

(a) the peeking action is applicable (i.e., step1 or step2)
(b) the noBumpSites ACL matches

The two conditions above are evaluated in the specified order. Condition
(b) is not evaluated unless condition (a) is satisfied.



> To clarify, if I would add an "all" at the end of this line, then all traffic would be spliced.

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



>>> 1: Is this peek-n-splice ruleset insecure?
>>
>> Define "secure".

> Well, is not the same if there is a squid-TLS (in the LAN) between a
> client and sensitive external server when a TLS connection is being
> established as if there is nothing between they.

I am not sure I interpret your definition correctly, but I hope the
following statements will answer your question regardless of that
interpretation:

* Staring (at step2) or bumping (at any step) alters TLS bytes on the
wire. The client and the origin server will see some TLS bytes that are
going to differ from the TLS bytes they would have seen if Squid was not
there.

* In this scope, the deprecated client-first and server-first actions
are equivalent to applying the "bump" action.

* If successful, ssl_bump peek and splice actions do not alter TLS
bytes. Peeking and/or splicing Squid can be viewed as a TCP proxy as far
as TLS bytes forwarding is concerned. The client and the origin server
will see the same TLS bytes they would have seen if Squid was not there.

* In this scope, various errors are usually equivalent to applying the
"bump" action.


If your definition of "secure" is "does not change TLS bytes exchanges
between client and server", then 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".


> In this sense I would like to know how could I interference as less
> as possible with the squid in the middle when someone is accesing to
> a site that I wish not to bump.

Peeking and/or splicing does not change TLS bytes. It is passive
monitoring. See the bullets above for a more complete/precise picture.


> 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


HTH,

Alex.