On 10/09/18 6:29 AM, Julian Perconti wrote: >> -----Mensaje original----- >> De: Amos Jeffries >> >> On 9/09/18 5:45 AM, Julian Perconti wrote: >>>> -----Mensaje original----- >>>> De: Amos Jeffries >>>> >>>>> So from http://marek.helion.pl/install/squid.html >>>>> >>>>> We have this configs: >>>>> >>>>> ssl_bump peek step1 all >>>>> ssl_bump peek step2 noBumpSites >>>>> ssl_bump splice step3 noBumpSites >>>>> ssl_bump stare step2 >>>>> ssl_bump bump step3 >>>>> >>>>> Is better to use the above conf (staring at step2)? Because you said >>>>> that >>>> bump at step2 is insecure. >>>>> >>>>> Is the same if a I change the order of the above conf to: >>>>> >>>>> ssl_bump peek step1 all >>>>> ssl_bump peek step2 noBumpSites >>>>> ssl_bump stare step2 <<< order changed ssl_bump splice step3 >>>>> noBumpSites ssl_bump bump step3 >>>>> >>>> >>>> What exactly do you think the step1, step2, step3 ACLs here are doing? >>> >>> I don not know what -exactly- these ACL are doing; that is what I trying to >> find out. >>> I have some ideas about them, but not the exactly knowledge, for that >>> reason I asked if there is difference between those 2 configs order >>> (because the step is the same) >> >> Okay. When ssl_bump is being processed the first time SslBump1 matches as >> true, the second time SslBump2 is true, and third time for SslBump3. >> Outside their own step in the TLS handshake process they match false. >> >> This is how you select that a certain line in ssl_bump is *only* to match and >> happen at a certain part (step) of the handshake sequence. > > Well. > > First of all thank You for your time and explanation, and patient of course. > It's much appretiated. > > I Hope this thread helps to others that have a similar confusion and doubts > like me. > Still the things are not "entirely" clear, I will quote. > > > ...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. >> >>> >>>> >>>> I hoped it is obvious, but maybe not. Understanding that detail >>>> should help resolve at least some of your confusion about these >>>> config snippets and how "tiny" changes to them are affecting Squid >> behaviour in major ways. >>>> >>> >>> No, it isn't obviuos to me, and yes, I am still trying to understand by re- >> reading wiki squid doc and other sites about peek and splice decisions and >> about the steps too. >>> >>>> >>>>> >>>>> So in a brief I think that config A is more secure. >>>>> >>>> >>>> No. Config (A) from the earlier post actively *creates* insecurity >>>> by; >>> >>> But,according to http://marek.helion.pl/install/squid.html; It's supposed >> that config "A" check server certificate. Because it is peeking at step2 and >> splicing at step3 the whitelist sites. >>> >> >> The peek at step2 line has another ACL condition which must _also_ be true >> for peek to actually happen. In every transaction where that noBumpSites is >> *false* the ssl_bump ACL processing continues on and finds the "bump" line. >> >> (that much is just regular ACL processing logic, not SSL-Bump specific). >> >> >> Also, Marek is another slightly confused admin like yourself. So that page >> follows what he understands and has a few mistakes. It is also from >> 2 years ago, since then we have fixed some bugs and TLS has had features >> added and removed (notably TLS/1.3 rollout begun and SSL formally >> obsoleted). >> >>>> >>>> 1) hiding any information about the real server security level, >>>> - downgrade attacks. Right down to plaintext levels. >>>> >>>> 2) hiding any information about the server certificate validity, >>>> - silent third-party MITM. >>>> - invalid certificate attacks. >>>> >>>> 3) opening the server connection to multiplexed use from multiple >>>> clients of Squid, >>>> - consider that in light of (1) and (2) >>> >>> I dont understand, in earlier post: >>> >>>>> ssl_bump peek step1 all >>>>> ssl_bump peek step2 noBumpSites >>>>> ssl_bump splice step3 noBumpSites >>>>> ssl_bump bump >>>>> >>>> So... (lets call this config A) >>> >>> In this config I think the problem is that squid is peeking at step2 >>> noBumpSites; >> >> Yes, exactly so. >> >>> but also bump all other sites at step2 (there is no step specified in >> the last line -the bump-) >>> >> >> Not quite. That line is the reason bump is being done in (A). >> >> BUT if that line had a step3 ACL there would still be the same cases hitting >> ... >> no lines -> an implict guess from Squid about splice vs bump. > > Therefore is always better to tell to squid the step. To avoid ambiguous > decison, etc. > >> >> I thought Squid chose bump to preserve the old client-first behaviour. >> But your test below indicates that your version is splicing. > > That is what I want to do. > But I dont understand why sites are failling if I am splicing those ones. May > be cause I am peeking at step2 and splice at step3 the noBumpSites. > >> >> >>> Therefore I think that would be "better" or " less insecure" bumping at >> step3. >>> >> >> Yes, exactly so - it is more secure to bump at step3. >> >> BUT, as Alex said, bump at step3 does not work after a peek at step2. > > Yes, according to the doc, peeking at step2 precules future bumping. I dont > want to bump the whitelist, I want to tunnel instead. > That is why peek all at step1 but peek noBumpSites at step2. > >> >> The peek happening at step2 means any secret tokens have already been >> passed around. Squid then cannot replace those tokens with its own ones. >> 'stare' is the action which holds back things like that and filters the >> features >> such that Squid can bump the encryption. >> > > 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. > >> >> The other bumps, which happen at step2 are where the issues I pointed out >> happen. Those vulnerabilities are directly cause by lack of serverHello >> details >> and how insecure it is to trust the client *alone* about what is going on. >> From Squid's perspective attacks usually come from clients (external >> malicious ones), so yeah not a good idea to trust them based on their own >> claims (clientHello). >> > > 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. > >> >>> Conlusion based on these words: >>> >>>> So config (A) is trying to do a step3 (handshake with server) when it >>>> has only peek'ed and relayed the clientHello as-is (including any >>>> secret tokens an unknown features the client is trying to use). The >>>> bump action is bound to fail. >>>> ** "stare" is the action which sets up and filters the handshake >>>> ready for bump action at step3 (server handshake with TLS features >>>> Squid knows how to handle). >>> >>> I think that my config would be something like this: >>> >>> ssl_bump peek step1 all >>> >>> ssl_bump peek step2 noBumpSites >>> >>> From squid doc: >>> "When a peek rule matches during step 2, Squid proceeds to step3 where it >> parses the TLS Server Hello and extracts server certificate while preserving >> the possibility of splicing the client and server connections; peeking at the >> server certificate usually precludes future bumping" >>> >>> And from http://marek.helion.pl/install/squid.html >>> Peeking at step 2 will check the name stored in server certificate >>> (CommonName, SubjectAltName) as well. So let's do it! you must enable >>> peek at step 2 and finally splice at step3 (if certName matches the >>> whitelist) >>> >> >> Pause. >> >> What do you want/need to happen to the handshakes that do not match the >> noBumpSites criteria for peeking? > > Quick answer: Bump. > Then put the below line after your "peek step2 noBumPSites" line: ssl_bump stare step2 > What I exactly want to do is: > Secure bump to the sites that are not listed in "noBumoSites" ACL and secure > splice/tunnel to sites listed in "noBumpSites". > >> >> Squid has to do something, your test below indicates that is splice. >> >> Anyway, assume the implicit is doing something you don't want or likely to >> change as bugs get fixed. Make sure one of your config lines always matches >> to be clear. >> >> Resume; >> >>> ssl_bump splice step3 noBumpSites >>> (following the ruleset explained above) >>> >>> And here I believe that the final bump should be make at step3: >>> >>> ssl_bump bump step3 >>> >>> OR there is no difference if i dont specify the step in the bump line? >>> >> >> If you omit a step ACL in any ssl_bump line that lines action will apply at >> any >> step where; its ACLs match, the action is valid, and no prior line has >> matched. > > An old doubt, answered by Alex and now by You, thanks to both. > So it is always better to tell squid what "he" exactly has to do in each > step. Or avoid to let him to "decide"... > >> >> >>> summarizing: >>> >>> ssl_bump peek step1 all >>> ssl_bump peek step2 noBumpSites >>> ssl_bump splice step3 noBumpSites >>> ssl_bump bump step3 >>> >>> EDIT: >>> Before send this mail to list, I test the squid behaviour and if I >>> dont add a stare (dont know why this happens, stare is the less used >>> option I saw in many examples on the web) line at step2, all accesed >>> site are spliced; so my final config would be taken from helion.pl: >>> (almost defeated by this thread/topic) >>> >> >> Okay, so your Squid implicitly chooses to splice at step2. >> Sorry about the confusion. The implicit action(s) have been different in the >> past. Which is #1 reason to make an explicit config line for each case. >> >> >>> ssl_bump peek step1 all # at step 1 we're peeking at >>> client TLS-request in order to find the "SNI" >>> ssl_bump peek step2 nobumpSites # here we're peeking at server >>> certificate >>> ssl_bump splice step3 nobumpSites # here we're splicing >>> connections which match the whitelist >>> ssl_bump stare step2 # here we're staring at >>> server certificate >>> ssl_bump bump step3 # finally we're bumping all >>> other SSL connections at step 3 > > 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 autor of helion.pl says: >>> >>> "Honestly I don't see a reason to stare at the server certificate before >> bumping. Even without "staring" the fake-certificate has the same attributes >> (Common Name etc.) like the original one. But it might change in the >> future..." >>> >>> So I leave the stare line to avoid splice all the traffic. >>> >> >> Good. > > Final Words, the site that start to fail from one day to antoher is > www.santanderrio.com.ar. All other spliced sites never stops working. > > I will use ssllabs.com to test the site. > > 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. 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. 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. Amos _______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
