On 09/17/2018 11:53 AM, Julian Perconti wrote: >> 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 > 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. Yes. >> for each rule >> do # ...and this loop, will execute as many times as the amount of the rules the config has. For each other loop iteration, this inner loop will execute zero or more times, depending on the number _and_ meaning/content of the rules. Both loops can finish "early" (i.e. before three steps and/or before all configured rules are evaluated). > Now, How does Squid takes and retains decisions when the steps are > implicit/explicit throught the rules? See my loops summary above: If the inner loop runs to its completion, then Squid applies the default action (because the inner loop found no usable explicit rules). There is no secret magic here (at least not at this level of detail). > 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. Just to avoid misunderstanding: Final actions may be taken at any step, but only final actions are possible at step3. > 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. I do not know what you mean. Splice at step1 is certainly possible and even recommended for known non-TLS traffic. > the thing that really does not makes sense is splice at step1 and then splice at step2: It is not possible to splice twice. Splicing is one of the final actions. No other action follows a final action (by definition). Search for the two "exit" words in the loop summary to find where final actions may be applied. > Acording to squid doc.: "step2/step3 is only performed if a peek or > stare rule matched during the previous step." (not a splice rule) Correct. > So, Is "correct" to splice at step1 or step2? The best thing to do depends on your goals and the transaction. Splicing at step1, step2, OR step3 makes sense in some cases and does not make sense (or is impossible) in others. You need to evaluate your rules in the context of a specific transaction though: The same set of ssl_bump rules may splice transaction A at step1 and transaction C at step3. The loops summarized above are executed from scratch for every transaction that reaches ssl_bump directive evaluation. >> * 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. It is impossible to make "splice or bump" decision at step3 because splicing at step3 requires peeking at step2 while bumping at step3 requires staring at step2. In a context of a single transaction, it is impossible to both peek and stare at the same time! Thus, you essentially have to make that "splice or bump" decision earlier, at step1 or step2, when you have less information than you would have at step3. It is almost like the dominant quantum physics theory -- by measuring at step2, you determine the outcome of that measurement (i.e. available actions at step3). > 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. A matching peek rule at step1 results in (TLS Client Hello being parsed during) step2. It also tells Squid to splice by default at step2 if Squid needs to apply a default action at step2. A matching stare rule at step1 results in (TLS Client Hello being parsed during) step2. It also tells Squid to bump by default at step2 if Squid needs to apply a default action at step2. There are no TLS byte modifications during peeking or staring at step1. I think this is all documented at https://wiki.squid-cache.org/Features/SslPeekAndSplice > ssl_bump peek noBumpSites > ssl_bump stare > > But, what happen if Squid decides automagically wrong? Or something does not match...? I do not know what you mean by "Squid decides automagically wrong" At step1 and at step2, if noBumpSites matches, then Squid will peek. At step1 and at step2, if noBumpSites does not match, then Squid will stare. At step3, no explicit rules can match so Squid will either splice or bump, depending on whether noBumpSites matched at step2. > 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?" Sorry, I do not. And since there are many details that define what one wants to (or should) do, it may be impractical to relay all of them on an informal email thread. However, if you understand how SslBump rules work, then you can either answer a vague "Am I doing what I want to be doing?" question yourself or ask more specific questions that can be answered on the mailing list. Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
