[squid-users] About SSL peek-n-splice/bump configurations

[Amos Jeffries]

On 8/09/18 4:58 AM, Julian Perconti wrote:
>> De: Amos Jeffries
>> On 7/09/18 1:48 PM, Julian Perconti wrote:>
>>> Hi all,
>>>
>>> I have a new strange situation:
>>>
>>> With this peek-n-splice configuration:
>>>
>>> ssl_bump peek step1 all
>>> ssl_bump peek step2 noBumpSites
>>> ssl_bump splice step3 noBumpSites
>>> ssl_bump bump
>>
>> So... (lets call this config A)
>>
>> #step1 does this:
>>
>>> ssl_bump peek step1 all
>>
>> #step2 does this:
>>
>>> ssl_bump peek step2 noBumpSites
>>> ssl_bump bump
>>
>> If the bump at step2 happened, there is no step3.
>>
>> #step3 does this:
>>
>>> ssl_bump splice step3 noBumpSites
>>
>>
>>
>>>
>>> I got this error on spliced sites (a bank site):
>>>
>>> The system return in the browser this error: (chrome 69):
>>>
>>> (104) Connection reset by peer (TLS code: SQUID_ERR_SSL_HANDSHAKE)
>>> Handshake with SSL server failed: [No Error]
>>>
>>> This proxy and the remote host failed to negotiate a mutually acceptable
>> security settings for handling your request. It is possible that the remote host
>> does not support secure connections, or the proxy is not satisfied with the
>> host security credentials.
>>>
>>> cache.log:
>>> 2018/09/06 22:40:36 kid1| ERROR: negotiating TLS on FD 44:
>>> error:00000000:lib(0):func(0):reason(0) (5/-1/104)
>>>
>>> But if i change the ssl bump(s) directive to:
>>>
>>> ssl_bump peek step1
>>> ssl_bump splice noBumpSites
>>> ssl_bump bump all
>>>
>>
>> So ... (lets call this config B)
>>
>> #step does this:
>>
>>> ssl_bump peek step1
>>
>> #step2 does this:
>>
>>> ssl_bump splice noBumpSites
>>> ssl_bump bump all
>>
>> Notice there is never any step3, and the splice in this ruleset happens at
>> step2.
>>
>>
>> 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).
> 
> 
> 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 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.


>>
>>
>> The config (B) bumps at step2. That is what the old and very broken "client-
>> first" behaviour used to be. It does not produce any errors from the proxy
>> BUT leads directly to a huge pile of security vulnerabilities and nasty side
>> effects that may never be seen by you. Use at your own risk.
>>
>>
> 
> So in a brief I think that  config A is more secure.
> 

No. Config (A) from the earlier post actively *creates* insecurity by;

 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 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.

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