> -----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) > > 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. > > 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; but also bump all other sites at step2 (there is no step specified in the last line -the bump-) Therefore I think that would be "better" or " less insecure" bumping at step3. 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) 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? 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) 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 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. Thank You again. Squid Cache: Version 4.2-20180902-r6d8f397 Service Name: squid This binary uses OpenSSL 1.1.0f 25 May 2017. For legal restrictions on distribution see https://www.openssl.org/source/license.html configure options: '--prefix=/usr' '--build=x86_64-linux-gnu' '--localstatedir=/var/squid' '--libexecdir=/lib/squid' '--srcdir=.' '--datadir=/share/squid' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-silent-rules' '--with-cppunit-basedir=/usr' '--enable-inline' '--enable-async-io=8' '--enable-delay-pools' '--enable-underscores' '--sysconfdir=/etc/squid' '--with-logdir=/var/log/squid' '--with-pidfile=/var/run/squid.pid' '--with-openssl' '--enable-ssl-crtd' '--mandir=/share/man' '--enable-arp-acl' '--enable-esi' '--enable-zph-qos' '--enable-wccpv2' '--with-filedescriptors=65536' '--with-large-files' '--with-default-user=proxy' '--enable-linux-netfilter' '--enable-follow-x-forwarded-for' '--enable-storeio=ufs,aufs,diskd' '--enable-removal-policies=lru,heap' '--enable-icap' '--enable-icap-client' '--enable-cache-digests' '--enable-async-io' '--enable-poll' '--enable-truncate' '--disable-ident-lookups' '--disable-translation' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall' 'LDFLAGS=-fPIE -pie -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-D_FORTIFY_SOURCE=2' 'CXXFLAGS=-g -O2 -fPIE -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security' > > > > >> > >>> I can Access to spliced site and no any kind of errors in access.log > >>> > >>> Any idea? > >> > >> Have you read the documentation? > >> <https://wiki.squid-cache.org/Features/SslPeekAndSplice> > > > > Yes I did, but the thing is (still for me) a bit complex, see what the autor of > the link posted above said about the squid TLS. > > > > I assume you mean Alex, that page is a true community effort with > several authors. He is "just" the latest to update the info as Squid > changed and/or better ways to write the info were found. Both of us are > in the main dev team on Squid and neither authored the actual ssl_bump > processing code. I refered to this page: http://marek.helion.pl/install/squid.html > > Note that my descriptions are at time hedged with "should", "may", "if", > etc and Alex outright mentions possible bugs along with similar terms. > > > Any suggestions towards simplifying the wiki details, or presenting them > in an easier to read way would be welcome. > > > >> > >> Break your rules down into the stages as I have above and what is going > on > >> becomes a bit more clear. > >> > >> Then you can consider what ssl_bump is doing in terms of what info Squid > >> has available. > >> step1: TCP IP:port or CONNECT URI (forward-proxy only) > >> step2: TLS clientHello + TLS SNI (if any) > >> step3: TLS serverHello + server cert > >> > >> The entire directive set is interpreted from top-to-bottom left-to-right > each > >> step. First line to fully match is what happens for that step. > > > > Above in the current thread, there is a question about the order of steps. > > > > The "steps" are messages of the TLS handshake and Squid processing code. > They happen as per the wiki page section "Processing steps". My above is > a summary of the *data* available at each step at the time each ssl_bump > processing occurs. > > The variable things are what info the client and server are providing, > and what your locally defined ACLs (like the "noBumpSites") are actually > matching on when tested. > > There is also the fact that all this code is still quite volatile so the > code changes nearly every release or so, and parts of it all are buggy - > some we know about, some not yet. See above about both Alex and I > hedging our descriptions a bit at times where things become > non-deterministic. > > > > However I test (today) the site that caused (yesterday) the handshake > problem and with the original config and now works, so I dont know what to > think what could be happened. > > TLS is quite a volatile environment. It could be many things. > > Unfortunately it also means further learning we might all get about this > failure situation is not likely to happen any time soon. > > > I refer to this with the term "original config": > > > > ssl_bump peek step1 all > > ssl_bump peek step2 noBumpSites > > ssl_bump splice step3 noBumpSites > > ssl_bump bump > > > > Even though this works on your previously broken site as well as others > it still has the problems related to bump sometimes happening at step2 > before server details are known to your Squid. > > > 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
