> -----Mensaje original----- > De: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> En nombre de > Amos Jeffries > Enviado el: domingo, 9 de septiembre de 2018 02:35 > Para: squid-users@xxxxxxxxxxxxxxxxxxxxx > Asunto: Re: About SSL peek-n-splice/bump configurations > > On 9/09/18 5:45 AM, Julian Perconti wrote: > >> -----Mensaje original----- > >> De: squid-users <squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx> En nombre > >> de Amos Jeffries Enviado el: viernes, 7 de septiembre de 2018 15:19 > >> Para: squid-users@xxxxxxxxxxxxxxxxxxxxx > >> Asunto: Re: About SSL peek-n-splice/bump configurations > >> > >>> 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...? 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. To clarify the SslBump order is determinant but its also depends in what I want to do with steps and ACLs. 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... > > > > >> > >> 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? > > 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? > > > 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. 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? (also I dont understand what exactly the satre action do) ssl_bump bump step3 I think this config avoid the "old client-first insecure" behaviour. I am right? And squid check server-certitifacte before splice. > > > > 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. > > > HTH Yes, it really helps. Thank You very much. > Amos > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
