[squid-users] About SSL peek-n-splice/bump configurations
Amos Jeffries
squid3 at treenet.co.nz
Sun Sep 9 05:34:30 UTC 2018
On 9/09/18 5:45 AM, Julian Perconti wrote:
>> -----Mensaje original-----
>> De: squid-users <squid-users-bounces at lists.squid-cache.org> En nombre de
>> Amos Jeffries
>> Enviado el: viernes, 7 de septiembre de 2018 15:19
>> Para: squid-users at lists.squid-cache.org
>> Asunto: Re: [squid-users] 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.
>
>>
>> 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.
I thought Squid chose bump to preserve the old client-first behaviour.
But your test below indicates that your version is splicing.
> 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.
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.
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).
> 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?
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.
> 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
>
> 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.
HTH
Amos
More information about the squid-users
mailing list