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

[Julian Perconti]

> De: Alex Rousskov <rousskov at measurement-factory.com>
> Enviado el: lunes, 13 de agosto de 2018 02:01
> Para: Julian Perconti <vh1988 at yahoo.com.ar>; squid-users at lists.squid-
> cache.org
> Asunto: Re: [squid-users] About SSL peek-n-splice/bump configurations
> 
> On 08/12/2018 06:57 PM, Julian Perconti wrote:
> >> De: Alex Rousskov <rousskov at measurement-factory.com>
> >> Enviado el: domingo, 12 de agosto de 2018 20:50
> >> Para: Julian Perconti <vh1988 at yahoo.com.ar>;
> >> squid-users at lists.squid-cache.org
> >> Asunto: Re: [squid-users] About SSL peek-n-splice/bump configurations
> >>
> >> On 08/12/2018 04:09 PM, Julian Perconti wrote:
> >>> I would like to know which of these two cfg's are "better" or "more
> secure"
> >>> when a site/domain is spliced, bumped, etc.
> 
> >> It is impossible to answer that question without knowing how _you_
> >> define "better" or "more secure".
> 
> 
> > I tried to meant, "security" from the client-side accessing to a
> > non-bumped or spliced site, i.g.: bank website... client-side
> > "privacy" or an a -real- man-in-the-middle attack due to squid in the
> > middle.
> 
> A splicing Squid does not perform a man-in-the-middle attack on TLS or HTTP
> traffic. It essentially acts as a TCP/IP-level proxy and can log TLS handshake
> details. In some environments, doing all that improves "privacy" and
> "security". In others, it makes things worse (for some definition of "privacy"
> and "security").
> 
> A bumping Squid performs a man-in-the-middle attack on TLS traffic.
> After a successful attack, it essentially acts as an HTTP-level proxy and can log
> or even alter TLS and HTTP traffic. In some environments, doing all that
> improves "privacy" and "security" (for some definition of "privacy" and
> "security"). In others, it makes things worse.
> 
> You would have to ask a much more specific question to get a more specific
> (but still correct) answer.
> 
> 
> > Is well-known that there is no system /network/o.s. 100% secure but, I
> > dont know why, I always thought or stil think that with a https
> > proxy/filtering, the security or "the things" tooggles more risky if
> > this one did not exist. Even squid 100% correctly configured and
> > server well secured.
> 
> There are examples where deploying a splicing or even bumping Squid
> improves security of the humans and/or machines that are trusting Squid to
> examine and/or police their traffic. There are counter-examples as well. And
> I am sure that many installations can be viewed as both, depending on who
> gets to define "privacy", "security", and the "right balance" between the
> two.
> 
> 
> > What does squid when I dont specify the step?
> 
> Bugs notwithstanding, Squid should either
> 
> * bump if you were staring during the previous (explicitly configured) step or
> 
> * splice otherwise (including cases when no previous step was explicitly
> configured or existed).
> 
> I would not rely on this (correct) behavior without testing (at least) your
> Squid version (at least). I know that early SslBump implementations had bugs
> in that area.
> 
> 
> > For example:
> >
> > What does squid do with..:
> > ssl_bump splice step3 noBumpSites
> 
> Assuming there are no other rules, Squid should splice at step1 (see the
> "splice otherwise" rule above).
> 
> 
> > ...And what it do instead with this?:
> > ssl_bump splice noBumpSites
> 
> Assuming there are no other rules, Squid should splice at step1. It will do that
> when noBumpSites matches (naturally) and if noBumpSites does not match
> (per the "splice otherwise" rule above).
> 
> 
> > So, Would You prefer option 2?
> 
> Sorry, I cannot answer this question -- too many unknown variables. It is like
> asking a doctor whether she prefers to treat the patient with drug A or drug
> B when the doctor does not know what the patient is suffering from and
> what the patient's treatment preferences/goals are.
> 
> 
> >>> with Option 1 I don't see the domain in "TUNNEL" line, just the IP
> >>> addr.)
> 
> >> I doubt that is how it is supposed to work. When splicing, Option 1
> >> should have the same or more information so it should log the domain
> >> name if Option 2 has the domain name. If you are comparing log lines
> >> for identical transactions, then this could be a Squid bug.
> 
> > I dont know, I just tell what happen in the access.log when I
> > switching between these ssl_bump configs.
> 
> Yes, and I am just describing what should be happening (IMO). If what is
> actually happening bothers you, and it does not match what should be
> happening, and nobody comes up with a better explanation, then consider
> filing a bug report and working with developers to address the problem.
> 
> 
> HTH,
> 
> Alex.

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

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

I can Access to spliced site and no any kind of errors in access.log

Any idea?

Thanks in advance