> -----Mensaje original----- > De: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> En nombre de > Amos Jeffries > Enviado el: lunes, 10 de septiembre de 2018 01:13 > Para: squid-users@xxxxxxxxxxxxxxxxxxxxx > Asunto: Re: 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* _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
