> Both loops can finish "early" (i.e. before three steps and/or before all > configured rules are evaluated). Yes, maybe I would have should say at least: "Well in really, depend on the rules.." Especially in the inner loop. But I pointed to the maximum possibilities. (if exists) > Just to avoid misunderstanding: Final actions may be taken at any step, but > only final actions are possible at step3. Good point. My mistake, I forgot that. In fact, in the actions table its clear that a final action like terminate can occurs at any step and even worst, any action can occurs at step1. >From another point of view: at step3 only final actions are allowed. > > 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. Idem; same comments as above. > > 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. So, if a rule "x" match a splice action at inner loop when the outer loop starts, then take the final action for the rule "x" and if no there is no more rules at step1 exit and proceed to evaluate the rules for the step2. Some like that? > 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. I lost You here. > 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). Wait, maybe I do not explain myself well or I don not understand what do You want to mean; the ACL at every step are not the same. See below. > > ssl_bump peek noBumpSites > > ssl_bump stare It suppsed that here due to acl in the first line, squid will bump later, all except sites that matches the acl. > > 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" Well, it was just an (probably bad one) idea/thought. > At step1 and at step2, if noBumpSites matches, then Squid will peek. Therefore default splice... > At step1 and at step2, if noBumpSites does not match, then Squid will stare. ...and default bump. > At step3, no explicit rules can match so Squid will either splice or bump, > depending on whether noBumpSites matched at step2. Yes, just an aclaration: in this specific case "At step3, no explicit rules can match" (not anymore). All was already done in the previous steps. > > 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. Ok I am sorry for that, I understood that You had an idea about what I want to do, in a earlier message. I will answer with a "little" change in the last config to illustrate what I should/want to do in my scenario. It was: (Again: With this cfg I dont see any domain in TCP_TUNNEL neither the Security alerts..) ssl_bump peek noBumpSites # Here two steps will happen. And final action (splice) happens at step3 by default. ssl_bump stare And now is: (And with this I see the domain:443 in TCP_TUNNEL and Security alerts about the domain and ip match in the logs.) ssl_bump splice noBumpSites # This line reachs a splice rule at step1 and that is a final action, without future proccesing. ssl_bump stare Squid is telling to the client (in last config.) : "I will not touch any TLS byte. I can not do much about the security risk you may run. Despite what I said, I will do as many checks as possible then You will be connected..." Maybe splice at step1 I am leaving the client alone. But, what can I do? I have to choose: peek at 1 and 2 like before (and errors can happen; that is why I have reopened the thread... the cause was an error message from squid while a client was trying to access a bank site) or just splice (less checks,maybe less errors). Thank You again. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
