> > So, in a brief the confi is: > > > > ssl_bump peek step1 all > > ssl_bump peek step2 noBumpSites > > ssl_bump stare step2 all > > ... which should be equivalent to an even simpler config: > > ssl_bump peek step1 > ssl_bump peek noBumpSites > ssl_bump stare all Yes, i've tested and squid log shows the same. So,it appears that squid takes the same actions. > > ... which, for many reasonable definitions of noBumpSites (that match during > step1 if and only if they should match during step1), can be simplified even > further: > > ssl_bump peek noBumpSites > ssl_bump stare all Same as above, this "compact" config seems to be the same as the three above bump ruleset. Please, let me know if I understand why those cfg are equals or equivalent to config I've posted as a "final one". First alternative difference: > ssl_bump peek step1 # implicit "all" at step1 > ssl_bump peek noBumpSites # As there no step specified, squid match at any step then this line, match at step1 and then at step2 , so when a match occurs at step2 it precludes future bumping of the sites listed in the ACL. > ssl_bump stare all # Here there is either no step2 (and any step) specified but, because in the previous line You has (implicitly) peeked at step2, the stare'ing not (or can´t) applies to sites listed in ACL (they were peeked at step2). Second alternative difference: > ssl_bump peek noBumpSites # Like previous example, but..I guess that as there is no "all" explicit, this line do a "peek all at step1" (implicitly) and at step2 sites listed in ACL are being peek'd. To clarify, if I would add an "all" at the end of this line, then all traffic would be spliced. > ssl_bump stare all # There is no change between this line in both configs you've posted, So my "explanation" would be the same as of the "First alternative" > However, please note that the three configs above implicitly rely on Squid > splicing (or bumping) at step3 because of the previously matching > step2 peek (or stare) action and the lack of an explicit step3 rule. > Whether Squid v4.2 actually does what it should be doing, I do not know. Answered; squid "automagic " are working as spected. (Squid Cache: Version 4.2-20180902-r6d8f397) > > > 1: Is this peek-n-splice ruleset insecure? > > Define "secure". Well, is not the same if there is a squid-TLS (in the LAN) between a client and sensitive external server when a TLS connection is being established as if there is nothing between they. In this sense I would like to know how could I interference as less as possible with the squid in the middle when someone is accesing to a site that I wish not to bump. Or let the less quantity of security holes as possible. > > 2: It is correct to say that those lines are not necessary/redundant? > > They should be redundant, but I do not know whether Squid v4.2 > implements this aspect of the specs correctly. I know that there were related > implementation bugs in some Squid v3 releases. You can test and, if needed, > file a bug report. > > > > (#ssl_bump splice step3 noBumpSites/#ssl_bump bump step3 all) > > Please note that the meaning of your noBumpSites ACL changes from one > step to another (because it gets more/different info). Thus, it is incorrect to > say that > > ssl_bump peek step1 > ssl_bump peek step2 noBumpSites > ssl_bump splice step3 noBumpSites > ... > > is always exactly equivalent to > > ssl_bump peek step1 > ssl_bump peek step2 noBumpSites > ssl_bump splice step3 all # should be optional > ... > > When using the first configuration, it is possible that, in some specific case, > noBumpSites matches during step2 but does not match during step3, and > Squid proceeds to evaluating the remaining "..." rules in that specific case. > Such sequence of events is not possible in the second configuration because > splicing at step3 is unconditional there -- it does not rely on noBumpSites > matches during step3. OK, thanks to clarify that. Last question. When I do this: ssl_bump splice noBumpSites ssl_bump stare all It is supposed that in this config I am (guessing), implicity, peeking (first?) and splice at any step and bumping (implicity) at step3 sites that does not match with whitelist by staring at step2. Maybe something like that, I dont know. The thin is that I see in the logs a tunnel but, instead an IP address it shows a domain. (TCP_TUNNEL www.dropbox.com:433) *and* a security ALERT. Saying that there is no IP that match with the xyz.net domain, or some like that. So, taking into account the needs that I have already mentioned, what is the way I should take? > HTH, Always helps. Thank You! > Alex. _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
