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

Julian Perconti vh1988 at yahoo.com.ar
Fri Sep 7 16:58:59 UTC 2018


> De: squid-users <squid-users-bounces at lists.squid-cache.org> En nombre de
> Amos Jeffries
> Enviado el: viernes, 7 de septiembre de 2018 01:18
> Para: squid-users at lists.squid-cache.org
> Asunto: Re: [squid-users] About SSL peek-n-splice/bump configurations
> 
> 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

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

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

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

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


Thank You

> 
> 
> Amos
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users



More information about the squid-users mailing list