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

[Julian Perconti]

> -----Mensaje original-----
> De: squid-users <squid-users-bounces at lists.squid-cache.org> En nombre de
> Amos Jeffries
> Enviado el: lunes, 10 de septiembre de 2018 01:13
> Para: squid-users at lists.squid-cache.org
> Asunto: Re: [squid-users] About SSL peek-n-splice/bump configurations
> 
> >
> > ...So that means that squid processes the SslBump directives:
> >
> > 1: maybe more than one time in a single request...?
> >
> 
> Yes. Up to 3 times. A peek or splice action causes another check later.
> 
> 
> > 2: In a sequential order (as You or Alex said in an earlier post)
> >
> > - ... and "automagically" determine what to do if the ACL match or not?
> > With this I mean, for example.., that in a config could be first, in this order,
> a step1 directive then a step3 directive and finally a step2? With an ACL of
> course.
> 
> No, this order is fixed and follows the TLS handshake stages/steps:
>  step1, then step2, then step3. Exact same order as on the Squid wiki page.
> 
> The automagic is only applied when
>  a) no ssl_bump lines at all match (auto-decide for you), and
>  b) an action that matches is not valid for the step (auto-ignore that line).
> 
> 
> > To clarify the SslBump order is determinant but its also depends in what I
> want to do with steps and ACLs.
> >
> 
> Yes. Though what you understand by that statement still seems to differ a bit
> from what we understand it to mean.
> 
> 
> > Lets say...it is *not* mandatory to tell squid SslBump steps directives like:
> >
> > At step1 do x
> > At step 2 do y
> > At step3 do z
> >
> > And so on...
> >
> 
> Well, its true you don't *have* to . BUt also you don't have to use SSL-Bump
> at all either.
> 
> If you want to be sure what Squid is doing, and that it will continue to do that
> reliably then telling it for each step is a good idea.

Yes, but see below..what my conclusión is.

> 
> 
> > When I should stare?
> 
> When you, as the admin with meta knowledge about the overall policy -
> know that a bump is wanted to happen later.
> 
> 
> >
> >
> > Peeking at step2 does not prevent this?
> 
> Peeking at step2 precludes / forbids later bumping, so yes.
> 
> What I have been trying to highlight is that there is traffic that config (A)
> allows to go through *without* any peek at step2. It reaches the "ssl_bump
> bump" line.
> 
> 
> 
> >
> >
> > Quick answer: Bump.

A better term would have been "Short answer"

> >
> 
> Then put the below line after your "peek step2 noBumPSites" line:
> 
>   ssl_bump stare step2
> 
> 
> >
> > Wouldn't be less ambiguous to squid if I do this change:?
> >
> > ssl_bump peek step1 all > A question: I am not here peeking the
> noBumpSites list too? Should I add an !noBumpSites? to the end of this line?
> Just a doubt.
> > ssl_bump peek step2 nobumpSites
> > ssl_bump splice step3 nobumpSites
> > ssl_bump stare step2 nobumpSites > explicit staring whitelist (I haven't test
> this) it is just an idea...it make sense?
> 
> 
> The ACLs on the line above are the same as the peek line earlier. So the
> peek line matched already, nothing reaches this line.
>  <https://wiki.squid-cache.org/SquidFaq/SquidAcl#Common_Mistakes>
> 
> Less ambiguous, yes, if your knowledge of Squid ACLs is low. The FAQ
> link above should help a bit here.
> 
> 
> Your policy ("Quick answer: Bump.") was to prefer bump'ing. For that to
> happen as step 3 it needs a stare first at step 2.
> 
> So consider the stare here as the normal action this step2 is supposed
> to perform. With the peek line being the whitelist preventing stare+bump
> for special cases.
> 
> >  (also I dont understand what exactly the satre action do)
> 
> Hmm. Think of "peek" as a postal worker reading postcards people send in
> the mail. "stare" as the postal worker both reading and rewriting them
> to remove words (s)he doesn't like or understand.
> 
> Say if the a postcard ended with the words "never qwertyuio". A peek'ing
> postie would still deliver it unchanged, a stare'ing postie would
> deliver a postcard with the last word "never".
> 
> If the sender/receiver of the postcard had agreed to start using crypto
> every time a message ended with "qwertyuio" - the peeking postie would
> then just see a bunch of garbage/crypted postcards start to happen. The
> stare'ing one would be able to read the content, maybe even continue
> changing things.
> 
> The exact details are more complex of course, but essentially the same
> things going on.
> 
> 
> 
> > I think this config avoid the "old client-first insecure" behaviour. I am right?
> And squid check server-certitifacte before splice.
> >
> 
> Step 3 is where the "preclude" starts to matter.
> 
> 
> The Step 2 action determines whether the original clientHello or one
> rewritten by Squid gets sent to the server in order to get a serverHello
> out of it.
> 
> AIUI, "stare step2" precludes "splice step3". So that line should be
> ignored by Squid unless there was a peek done at step2.
> 
> To follow that postal analogy; client-first is like the postal worker
> simply replying to peoples postcards instead of delivering them. If/when
> they have to answer a question, writing a wholly new/different message
> to find out for itself first before answering.
> 
> 
> >
> > The thing that cause a lot of confusion to me is that in peek-n-splice
> environment, I can peek, plice,bump,starte in many steps (1,2,3).
> > That make the things a bit complex to decide. And of course to understand.
> 
> 
> Nod. One thing to be clear on is that TLS is designed to actively
> prevent MITM doing things like bump'ing. A client and server which are
> both using TLS properly cannot be bump'ed. They can only be peek'd and
> splice'd.

That is what I want to do:
Sensitive sites like banks, I dont want to bump/intercept. Instead of that, do a secure tunnel, between the client and server. May be via peeki'ng at step2?

> 
> There are many features in TLS that partially or fully work towards that
> goal. So it depends on which of those are negotiated between the
> endpoints (*if* negotiated) and also whether Squid is up to date enough
> to detect and prevent them when stare'ing.
> 
> There are also a bunch of different protocols happening in the HTTP
> environment these days (QUICK, CoAP, SPDY, HTTP/2 etc) - if one of those
> which Squid does not (yet) support is used to transfer TLS related data
> the endpoints may be transmitting info the proxy cannot affect.

Yes, sad but true today, I think.

> 
> 
> There is still an arms-race going on in TLS these days (though slowing a
> bit now). Thus the whole "only use the latest Squid release when
> SSL-Bump'ing" line we push so hard.
> 

OK, let me show You the final config, explained (called config "F"):

acl noBumpSites ssl::server_name_regex -i "/etc/squid/url.nobump"

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

   ssl_bump peek step1 all

Here I am peek'ing all, to bump/splice/stare at next step.
The doc.: 
"Step 1 is the only step that is always performed." 
" When a peek rule matches during step1, Squid proceeds to step2 where it parses the TLS Client Hello and extracts SNI (if any)."

   ssl_bump peek step2 noBumpSites

Here I am peek'ing too, but at step2 so, this makes future bump impossble. 
The doc.: "Peeking at this step usually makes bumping at step 3 impossible."

I think that splice at step3 would be reduntant. Because if peek'ing here "usually" makes bump imposible at next step so squid will decide an "automagic splice noBumpSites"

   ssl_bump stare step2 all

Here we star'ing at step2.
The doc.: "Staring at this step usually makes splicing at step 3 impossible."

Unlike the previous example, stare'ing at this step makes impossbile  future splic'ing... therefore squid will decide an "automagic bump all"

And finally:
Due to what has been said above, these two next lines I think are redundant or not necessary.

#ssl_bump splice step3 noBumpSites
#ssl_bump bump step3 all

The doc.:
" Step 3 is only performed if a peek or stare rule matched during the previous step."
" In most cases, the only meaningful choice at step 3 is whether to terminate the connection. "
The key-line for me to understand was: "The splicing or bumping decision is usually dictated by either peeking or staring at the previous step."

So, in a brief the confi is:

ssl_bump peek step1 all
ssl_bump peek step2 noBumpSites
ssl_bump stare step2 all

Comments:
In access.log I saw the bumped traffic (sites that are not white-listed by noBumpSites ACL) and TCP_TUNNEL when a spliced connection ends.
But, also see *many* lines like these when access to a non-intercepted or spliced site, say ibm.com:

At the beggining:
NONE/200 0 CONNECT 2.19.111.47:443 - ORIGINAL_DST/2.19.111.47 -  

At the end:
TCP_TUNNEL/200 197238 CONNECT 2.19.111.47:443

Final questions:

1: Is this peek-n-splice ruleset insecure? Whether if the site is bumped or spliced, both cases.
2: It is correct to say that those lines are not necessary/redundant? (#ssl_bump splice step3 noBumpSites/#ssl_bump bump step3 all)
3: Is the order of each step "correct"?


*Best regards and thank You*