> > So, when squid reaches this first rule and line (there is no explicit > > step) ...does Squid make a "bucle of steps" only along the first line > > and go to next line only when the rule stop being > > applicable/matchable? > > I hesitate answering that question with a simple "yes" or "no" because any > such answer is likely to mislead folks reading this email. Well yes, and I hope that this thread helps to others. > > The overall logic is like this: > > for each step > do > for each rule > do > if the rule action is possible and the rule ACLs match, > then perform the rule action and either go to the next > step or, after applying the final action, exit > done > apply the default action and exit > done Well, this explanation merits to copy it and paste into squid.conf as a comment. Let me know if I understand what Squid does with the rules of SslBump through this logic: > for each step > do # This loop will execute as maximum up to three times; because there are 3 steps in the entire SslBump environment. > for each rule > do # ...and this loop, will execute as many times as the amount of the rules the config has. Probably my interpretation of the nested loop is wrong. Now, How does Squid takes and retains decisions when the steps are implicit/explicit throught the rules? The developers knows the details. > > He is being a passive observer of that TLS traffic. > > Squid also validates what it observes/forwards. And there is also TCP/IP > traffic before (and around) TLS traffic. OK, so I will peek, instead of splice at step1 and step2; and the final action will be splice and it will happen at step3; the step where the final actions are always taken. I think that splice at step1 does not make sense according to the doc. and also to the order of steps or the sequence, about how the rules are evaluated. By other hand, lets squid to do more checks even if a sites will be spliced: to do that, as I said above, I (think that) have to peek instead splice at step1 and step2. Even more, about the step3 the squid doc. says: I: Get TLS Server Hello info from the server, including the server certificate. II: Validate the TLS server certificate. Finally, the thing that really does not makes sense is splice at step1 and then splice at step2: Acording to squid doc.: "step2/step3 is only performed if a peek or stare rule matched during the previous step." (not a splice rule) > > Here, I am talking about the idea of (explicitly) splice at step1 and then at > step2 of a white list of sites. > > If you splice at step1, then the number of validations that Squid does would > be smaller (possibly zero, not sure) than if you splice at step2. Again, following the documentation: "Step 2 is only performed if a peek or stare rule matched during the previous step." So, Is "correct" to splice at step1 or step2? > The devil is in the details: Always. > * A key detail here is determining whether the intended site _is_ > "really/special sensitive". For example, the intercepted client is connecting to > b::a:d IPv6 address while claiming in the TLS Hello that it is trying to get to > sensitive.example.com. Should Squid trust the intended destination IP > address or the TLS SNI? Or should we wait for the server to identify itself > with a valid SSL certificate? Etc. >From the "security side" I think that the second option. "...wait for the server to identify (...)" Therefore, I think that as is "more secure" bump at step3 then should be more secure splice at step3 too. > * The other key detail is what should happen when that sensitive site refuses > to communicate with Squid or otherwise misbehaves. Should Squid, for > example, simply close the browser connection, making it more likely that the > user (or their admin) blames the proxy? Or should Squid bump the browser > connection to explain what has happened, creating all the headaches > associated with bumping. Do not what to say at this point. Maybe I am missing something... > Your Squid configuration should reflect all these key decisions. > If Squid does not have enough configuration options or code to do exactly > what you want, then you (or others) can always add more code/options. If > your use case is common/general enough, then quality implementations of > those additional features should be officially accepted. Well, let me show You, what is my *second final* config to do the the most approximate actions I want Squid do and who has read the thread knows, taken as a conclusion of the thread: Telling to Squid what exactly he has to do at each step explicitly: ssl_bump peek step1 noBumpSites # at step1 peak or stare do the same, but Amos says that stare alters "the letters" while peek no. ssl_bump peek step2 noBumpSites ssl_bump splice step3 noBumpSites # This is probably reduntant ssl_bump stare step1 # Maybe It is the same if I peek here instead stare, because the difference about stare and peek happens at step2, the same come could be stay at first line, not sure. ssl_bump stare step2 ssl_bump bump step3 # This is even more reduntant too. If You have a look at helion.pl and/or the original config and compare his config and my own above are very similar (not to say identical) As an excercise a more compact config that do more-or-less the same would be: ssl_bump peek noBumpSites ssl_bump stare But, what happen if Squid decides automagically wrong? Or something does not match...? Do You think that the above rules is more-or-less the more nearest what I want to do? Excuse me but, I think that at this stage, I gues that You already know what I mean when I say "...what I want to do?" _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
