Discussion:
[squid-users] About SSL peek-n-splice/bump configurations
Julian Perconti
2018-08-12 22:09:01 UTC
Permalink
Hi,

I would like to know which of these two cfg's are "better" or "more secure"
when a site/domain is spliced, bumped, etc.

Here the lines...

# mandatory lines:

acl noBumpSites ssl::server_name_regex -i "/etc/squid/url.nobump"

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

_______________

# ssl_bump option 1: (with this I don't see the domain in "TUNNEL" line,
just the IP addr.)

ssl_bump peek step1
ssl_bump peek step2 noBumpSites
ssl_bump splice step3 noBumpSites
ssl_bump stare step2
ssl_bump bump step3

# ssl_bump option 2: (with this I see the domain in "TUNNEL" line.)

ssl_bump peek step1
ssl_bump splice noBumpSites
ssl_bump bump all


And (if possible) could anyone explain the differnce between these 2 cfg's ?

The peek-n-splice config (for me) was never clearly.

Thank you in advance,

All the best
Alex Rousskov
2018-08-12 23:49:58 UTC
Permalink
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".


> acl noBumpSites ssl::server_name_regex -i "/etc/squid/url.nobump"

> # ssl_bump option 1: (with this I don't see the domain in "TUNNEL" line,
> just the IP addr.)
>
> ssl_bump peek step1
> ssl_bump peek step2 noBumpSites
> ssl_bump splice step3 noBumpSites
> ssl_bump stare step2
> ssl_bump bump step3
>
> # ssl_bump option 2: (with this I see the domain in "TUNNEL" line.)
>
> ssl_bump peek step1
> ssl_bump splice noBumpSites
> ssl_bump bump all
>
>
> And (if possible) could anyone explain the differnce between these 2 cfg's ?

Bugs notwithstanding, Option 1 looks at the TLS server Hello details
(step2) before splicing or bumping the connections (at step3). Option 2
does not -- it splices or bumps based on TLS client Hello info only.

Option 1 should give Squid/you more information about the server when
splicing the two connections. For example, you can use server
certificate info during step3 and when logging.

Option 1 should give the client more information about the server when
bumping the client -- the client will get a mimicked server certificate
detail with this option.

I believe the information obtained at each step is documented at
https://wiki.squid-cache.org/Features/SslPeekAndSplice

Please note that your

ssl_bump splice step3 noBumpSites

is a bit risky because your noBumpSites may match differently on each
step (as it gets more reliable information). It could match at step2 but
not match at step3 or vice versa, but the decision to splice (or bump)
is essentially made at step2 -- if you peeked at step2, then you should
be splicing or terminating at step3 (and if you stared at step2, then
you should be bumping or terminating at step3). Your rules may not
follow that principle if noBumpSites matching changes.


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

Alex.
Julian Perconti
2018-08-13 00:57:01 UTC
Permalink
> -----Mensaje original-----
> De: Alex Rousskov <***@measurement-factory.com>
> Enviado el: domingo, 12 de agosto de 2018 20:50
> Para: Julian Perconti <***@yahoo.com.ar>; squid-***@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".

First of all: I am relative new in the "ssl/tls filtering world". There are many things I dont understand very well yet.

You might be right and I probably wrong.

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.

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.

>
>
> > acl noBumpSites ssl::server_name_regex -i "/etc/squid/url.nobump"
>
> > # ssl_bump option 1: (with this I don't see the domain in "TUNNEL"
> > line, just the IP addr.)
> >
> > ssl_bump peek step1
> > ssl_bump peek step2 noBumpSites
> > ssl_bump splice step3 noBumpSites
> > ssl_bump stare step2
> > ssl_bump bump step3
> >
> > # ssl_bump option 2: (with this I see the domain in "TUNNEL" line.)
> >
> > ssl_bump peek step1
> > ssl_bump splice noBumpSites
> > ssl_bump bump all
> >
> >
> > And (if possible) could anyone explain the differnce between these 2 cfg's
> ?
>
> Bugs notwithstanding, Option 1 looks at the TLS server Hello details
> (step2) before splicing or bumping the connections (at step3). Option 2 does
> not -- it splices or bumps based on TLS client Hello info only.
>

What does squid when I dont specify the step?

For example:

What does squid do with..:
ssl_bump splice step3 noBumpSites

...And what it do instead with this?:
ssl_bump splice noBumpSites

> Option 1 should give Squid/you more information about the server when
> splicing the two connections. For example, you can use server certificate info
> during step3 and when logging.
>
> Option 1 should give the client more information about the server when
> bumping the client -- the client will get a mimicked server certificate detail
> with this option.
>
> I believe the information obtained at each step is documented at
> https://wiki.squid-cache.org/Features/SslPeekAndSplice

Yes, but many things are pretty complex to understand well, even making tests.

>
> Please note that your
>
> ssl_bump splice step3 noBumpSites
>
> is a bit risky because your noBumpSites may match differently on each step
> (as it gets more reliable information). It could match at step2 but not match
> at step3 or vice versa, but the decision to splice (or bump) is essentially made
> at step2 -- if you peeked at step2, then you should be splicing or terminating
> at step3 (and if you stared at step2, then you should be bumping or
> terminating at step3). Your rules may not follow that principle if noBumpSites
> matching changes.

I Will consider this.

So, Would You prefer option 2? For now, I am testing that option.

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

> Alex.

Thank You

P.S.: squid versiĆ³n 4.2 on debian 9.5
Alex Rousskov
2018-08-13 05:00:41 UTC
Permalink
On 08/12/2018 06:57 PM, Julian Perconti wrote:
>> De: Alex Rousskov <***@measurement-factory.com>
>> Enviado el: domingo, 12 de agosto de 2018 20:50
>> Para: Julian Perconti <***@yahoo.com.ar>; squid-***@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.
Julian Perconti
2018-09-07 01:48:02 UTC
Permalink
> De: Alex Rousskov <***@measurement-factory.com>
> Enviado el: lunes, 13 de agosto de 2018 02:01
> Para: Julian Perconti <***@yahoo.com.ar>; squid-***@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 <***@measurement-factory.com>
> >> Enviado el: domingo, 12 de agosto de 2018 20:50
> >> Para: Julian Perconti <***@yahoo.com.ar>;
> >> squid-***@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
Amos Jeffries
2018-09-07 04:18:10 UTC
Permalink
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).


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.



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

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.


Amos
Alex Rousskov
2018-09-07 04:47:15 UTC
Permalink
On 09/06/2018 10:18 PM, Amos Jeffries wrote:

> 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

You should also add this to step3 if the bump did not happen at step2
(i.e. if noBumpSites matched at step2):

ssl_bump bump


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

Correct (assuming noBumpSites matches 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 handshake with the server actually started during step2 (SSL Hellos
were exchanged). The SSL negotiation (if any) completes during step3,
most likely without Squid participation (because Squid is just splicing
at TCP level). If Squid does try to participate in that SSL negotiation,
then it is a Squid bug (see below), and, like you said below, the
handshake will fail because Squid has forwarded client information
without knowing client secrets.


> The bump action is bound to fail.

IIRC, the bump action should be ignored by Squid at step3 because it
becomes banned by peeking at step2. Bugs notwithstanding,
banned/impossible actions should be ignored. Instead, the connections
should be spliced at step3 if no rule matches at step3 because the last
matching rule at step2 was "peek", indicating a splicing intent. Again,
I do not know whether the Squid actually does what it is supposed to do
in this case.


> The config (B) bumps at step2.

It also splices banks at step2. It is possible that the working test
case is spliced at step2 when using config B (and that is why it works).


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

Correct.


Cheers,

Alex.
Julian Perconti
2018-09-07 16:58:59 UTC
Permalink
> De: squid-users <squid-users-***@lists.squid-cache.org> En nombre de
> Amos Jeffries
> Enviado el: viernes, 7 de septiembre de 2018 01:18
> Para: squid-***@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-***@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
Amos Jeffries
2018-09-07 18:19:08 UTC
Permalink
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
Julian Perconti
2018-09-08 17:45:10 UTC
Permalink
> -----Mensaje original-----
> De: squid-users <squid-users-***@lists.squid-cache.org> En nombre de
> Amos Jeffries
> Enviado el: viernes, 7 de septiembre de 2018 15:19
> Para: squid-***@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)

>
> 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-***@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
Amos Jeffries
2018-09-09 05:34:30 UTC
Permalink
On 9/09/18 5:45 AM, Julian Perconti wrote:
>> -----Mensaje original-----
>> De: squid-users <squid-users-***@lists.squid-cache.org> En nombre de
>> Amos Jeffries
>> Enviado el: viernes, 7 de septiembre de 2018 15:19
>> Para: squid-***@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
Julian Perconti
2018-09-09 18:29:13 UTC
Permalink
> -----Mensaje original-----
> De: squid-users <squid-users-***@lists.squid-cache.org> En nombre de
> Amos Jeffries
> Enviado el: domingo, 9 de septiembre de 2018 02:35
> Para: squid-***@lists.squid-cache.org
> Asunto: Re: [squid-users] About SSL peek-n-splice/bump configurations
>
> On 9/09/18 5:45 AM, Julian Perconti wrote:
> >> -----Mensaje original-----
> >> De: squid-users <squid-users-***@lists.squid-cache.org> En nombre
> >> de Amos Jeffries Enviado el: viernes, 7 de septiembre de 2018 15:19
> >> Para: squid-***@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.

Well.

First of all thank You for your time and explanation, and patient of course. It's much appretiated.

I Hope this thread helps to others that have a similar confusion and doubts like me.
Still the things are not "entirely" clear, I will quote.


...So that means that squid processes the SslBump directives:

1: maybe more than one time in a single request...?

2: In a sequential order (as You or Alex said in an earlier post)

- ... and "automagically" determine what to do if the ACL match or not?
With this I mean, for example.., that in a config could be first, in this order, a step1 directive then a step3 directive and finally a step2? With an ACL of course.
To clarify the SslBump order is determinant but its also depends in what I want to do with steps and ACLs.

Lets say...it is *not* mandatory to tell squid SslBump steps directives like:

At step1 do x
At step 2 do y
At step3 do z

And so on...

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

Therefore is always better to tell to squid the step. To avoid ambiguous decison, etc.

>
> I thought Squid chose bump to preserve the old client-first behaviour.
> But your test below indicates that your version is splicing.

That is what I want to do.
But I dont understand why sites are failling if I am splicing those ones. May be cause I am peeking at step2 and splice at step3 the noBumpSites.

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

Yes, according to the doc, peeking at step2 precules future bumping. I dont want to bump the whitelist, I want to tunnel instead.
That is why peek all at step1 but peek noBumpSites 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.
>

When I should stare?

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

Peeking at step2 does not prevent this?

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

Quick answer: Bump.

What I exactly want to do is:
Secure bump to the sites that are not listed in "noBumoSites" ACL and secure splice/tunnel to sites listed in "noBumpSites".

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

An old doubt, answered by Alex and now by You, thanks to both.
So it is always better to tell squid what "he" exactly has to do in each step. Or avoid to let him to "decide"...

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

Wouldn't be less ambiguous to squid if I do this change:?

ssl_bump peek step1 all > A question: I am not here peeking the noBumpSites list too? Should I add an !noBumpSites? to the end of this line? Just a doubt.
ssl_bump peek step2 nobumpSites
ssl_bump splice step3 nobumpSites
ssl_bump stare step2 nobumpSites > explicit staring whitelist (I haven't test this) it is just an idea...it make sense? (also I dont understand what exactly the satre action do)
ssl_bump bump step3

I think this config avoid the "old client-first insecure" behaviour. I am right? And squid check server-certitifacte before splice.

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

Final Words, the site that start to fail from one day to antoher is www.santanderrio.com.ar. All other spliced sites never stops working.

I will use ssllabs.com to test the site.

The thing that cause a lot of confusion to me is that in peek-n-splice environment, I can peek, plice,bump,starte in many steps (1,2,3).
That make the things a bit complex to decide. And of course to understand.
>
>
> HTH

Yes, it really helps.

Thank You very much.

> Amos
> _______________________________________________
> squid-users mailing list
> squid-***@lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
Amos Jeffries
2018-09-10 04:12:45 UTC
Permalink
On 10/09/18 6:29 AM, Julian Perconti wrote:
>> -----Mensaje original-----
>> De: Amos Jeffries
>>
>> On 9/09/18 5:45 AM, Julian Perconti wrote:
>>>> -----Mensaje original-----
>>>> De: Amos Jeffries
>>>>
>>>>> 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.
>
> Well.
>
> First of all thank You for your time and explanation, and patient of course. It's much appretiated.
>
> I Hope this thread helps to others that have a similar confusion and doubts like me.
> Still the things are not "entirely" clear, I will quote.
>
>
> ...So that means that squid processes the SslBump directives:
>
> 1: maybe more than one time in a single request...?
>

Yes. Up to 3 times. A peek or splice action causes another check later.


> 2: In a sequential order (as You or Alex said in an earlier post)
>
> - ... and "automagically" determine what to do if the ACL match or not?
> With this I mean, for example.., that in a config could be first, in this order, a step1 directive then a step3 directive and finally a step2? With an ACL of course.

No, this order is fixed and follows the TLS handshake stages/steps:
step1, then step2, then step3. Exact same order as on the Squid wiki page.

The automagic is only applied when
a) no ssl_bump lines at all match (auto-decide for you), and
b) an action that matches is not valid for the step (auto-ignore that
line).


> To clarify the SslBump order is determinant but its also depends in what I want to do with steps and ACLs.
>

Yes. Though what you understand by that statement still seems to differ
a bit from what we understand it to mean.


> Lets say...it is *not* mandatory to tell squid SslBump steps directives like:
>
> At step1 do x
> At step 2 do y
> At step3 do z
>
> And so on...
>

Well, its true you don't *have* to . BUt also you don't have to use
SSL-Bump at all either.

If you want to be sure what Squid is doing, and that it will continue to
do that reliably then telling it for each step is a good idea.



>>
>>>
>>>>
>>>> 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.
>
> Therefore is always better to tell to squid the step. To avoid ambiguous decison, etc.
>
>>
>> I thought Squid chose bump to preserve the old client-first behaviour.
>> But your test below indicates that your version is splicing.
>
> That is what I want to do.
> But I dont understand why sites are failling if I am splicing those ones. May be cause I am peeking at step2 and splice at step3 the noBumpSites.
>
>>
>>
>>> 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.
>
> Yes, according to the doc, peeking at step2 precules future bumping. I dont want to bump the whitelist, I want to tunnel instead.
> That is why peek all at step1 but peek noBumpSites 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.
>>
>
> When I should stare?

When you, as the admin with meta knowledge about the overall policy -
know that a bump is wanted to happen later.


>
>>
>> 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).
>>
>
> Peeking at step2 does not prevent this?

Peeking at step2 precludes / forbids later bumping, so yes.

What I have been trying to highlight is that there is traffic that
config (A) allows to go through *without* any peek at step2. It reaches
the "ssl_bump bump" line.



>
>>
>>> 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?
>
> Quick answer: Bump.
>

Then put the below line after your "peek step2 noBumPSites" line:

ssl_bump stare step2


> What I exactly want to do is:
> Secure bump to the sites that are not listed in "noBumoSites" ACL and secure splice/tunnel to sites listed in "noBumpSites".
>
>>
>> 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.
>
> An old doubt, answered by Alex and now by You, thanks to both.
> So it is always better to tell squid what "he" exactly has to do in each step. Or avoid to let him to "decide"...
>
>>
>>
>>> 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
>
> Wouldn't be less ambiguous to squid if I do this change:?
>
> ssl_bump peek step1 all > A question: I am not here peeking the noBumpSites list too? Should I add an !noBumpSites? to the end of this line? Just a doubt.
> ssl_bump peek step2 nobumpSites
> ssl_bump splice step3 nobumpSites
> ssl_bump stare step2 nobumpSites > explicit staring whitelist (I haven't test this) it is just an idea...it make sense?


The ACLs on the line above are the same as the peek line earlier. So the
peek line matched already, nothing reaches this line.
<https://wiki.squid-cache.org/SquidFaq/SquidAcl#Common_Mistakes>

Less ambiguous, yes, if your knowledge of Squid ACLs is low. The FAQ
link above should help a bit here.


Your policy ("Quick answer: Bump.") was to prefer bump'ing. For that to
happen as step 3 it needs a stare first at step 2.

So consider the stare here as the normal action this step2 is supposed
to perform. With the peek line being the whitelist preventing stare+bump
for special cases.




> (also I dont understand what exactly the satre action do)

Hmm. Think of "peek" as a postal worker reading postcards people send in
the mail. "stare" as the postal worker both reading and rewriting them
to remove words (s)he doesn't like or understand.

Say if the a postcard ended with the words "never qwertyuio". A peek'ing
postie would still deliver it unchanged, a stare'ing postie would
deliver a postcard with the last word "never".

If the sender/receiver of the postcard had agreed to start using crypto
every time a message ended with "qwertyuio" - the peeking postie would
then just see a bunch of garbage/crypted postcards start to happen. The
stare'ing one would be able to read the content, maybe even continue
changing things.

The exact details are more complex of course, but essentially the same
things going on.



> I think this config avoid the "old client-first insecure" behaviour. I am right? And squid check server-certitifacte before splice.
>

Step 3 is where the "preclude" starts to matter.


The Step 2 action determines whether the original clientHello or one
rewritten by Squid gets sent to the server in order to get a serverHello
out of it.

AIUI, "stare step2" precludes "splice step3". So that line should be
ignored by Squid unless there was a peek done at step2.

To follow that postal analogy; client-first is like the postal worker
simply replying to peoples postcards instead of delivering them. If/when
they have to answer a question, writing a wholly new/different message
to find out for itself first before answering.


>>>
>>> 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.
>
> Final Words, the site that start to fail from one day to antoher is www.santanderrio.com.ar. All other spliced sites never stops working.
>
> I will use ssllabs.com to test the site.
>
> The thing that cause a lot of confusion to me is that in peek-n-splice environment, I can peek, plice,bump,starte in many steps (1,2,3).
> That make the things a bit complex to decide. And of course to understand.


Nod. One thing to be clear on is that TLS is designed to actively
prevent MITM doing things like bump'ing. A client and server which are
both using TLS properly cannot be bump'ed. They can only be peek'd and
splice'd.

There are many features in TLS that partially or fully work towards that
goal. So it depends on which of those are negotiated between the
endpoints (*if* negotiated) and also whether Squid is up to date enough
to detect and prevent them when stare'ing.

There are also a bunch of different protocols happening in the HTTP
environment these days (QUICK, CoAP, SPDY, HTTP/2 etc) - if one of those
which Squid does not (yet) support is used to transfer TLS related data
the endpoints may be transmitting info the proxy cannot affect.


There is still an arms-race going on in TLS these days (though slowing a
bit now). Thus the whole "only use the latest Squid release when
SSL-Bump'ing" line we push so hard.

Amos
Julian Perconti
2018-09-10 18:35:42 UTC
Permalink
> -----Mensaje original-----
> De: squid-users <squid-users-***@lists.squid-cache.org> En nombre de
> Amos Jeffries
> Enviado el: lunes, 10 de septiembre de 2018 01:13
> Para: squid-***@lists.squid-cache.org
> Asunto: Re: [squid-users] About SSL peek-n-splice/bump configurations
>
> >
> > ...So that means that squid processes the SslBump directives:
> >
> > 1: maybe more than one time in a single request...?
> >
>
> Yes. Up to 3 times. A peek or splice action causes another check later.
>
>
> > 2: In a sequential order (as You or Alex said in an earlier post)
> >
> > - ... and "automagically" determine what to do if the ACL match or not?
> > With this I mean, for example.., that in a config could be first, in this order,
> a step1 directive then a step3 directive and finally a step2? With an ACL of
> course.
>
> No, this order is fixed and follows the TLS handshake stages/steps:
> step1, then step2, then step3. Exact same order as on the Squid wiki page.
>
> The automagic is only applied when
> a) no ssl_bump lines at all match (auto-decide for you), and
> b) an action that matches is not valid for the step (auto-ignore that line).
>
>
> > To clarify the SslBump order is determinant but its also depends in what I
> want to do with steps and ACLs.
> >
>
> Yes. Though what you understand by that statement still seems to differ a bit
> from what we understand it to mean.
>
>
> > Lets say...it is *not* mandatory to tell squid SslBump steps directives like:
> >
> > At step1 do x
> > At step 2 do y
> > At step3 do z
> >
> > And so on...
> >
>
> Well, its true you don't *have* to . BUt also you don't have to use SSL-Bump
> at all either.
>
> If you want to be sure what Squid is doing, and that it will continue to do that
> reliably then telling it for each step is a good idea.

Yes, but see below..what my conclusiĆ³n is.

>
>
> > When I should stare?
>
> When you, as the admin with meta knowledge about the overall policy -
> know that a bump is wanted to happen later.
>
>
> >
> >
> > Peeking at step2 does not prevent this?
>
> Peeking at step2 precludes / forbids later bumping, so yes.
>
> What I have been trying to highlight is that there is traffic that config (A)
> allows to go through *without* any peek at step2. It reaches the "ssl_bump
> bump" line.
>
>
>
> >
> >
> > Quick answer: Bump.

A better term would have been "Short answer"

> >
>
> Then put the below line after your "peek step2 noBumPSites" line:
>
> ssl_bump stare step2
>
>
> >
> > Wouldn't be less ambiguous to squid if I do this change:?
> >
> > ssl_bump peek step1 all > A question: I am not here peeking the
> noBumpSites list too? Should I add an !noBumpSites? to the end of this line?
> Just a doubt.
> > ssl_bump peek step2 nobumpSites
> > ssl_bump splice step3 nobumpSites
> > ssl_bump stare step2 nobumpSites > explicit staring whitelist (I haven't test
> this) it is just an idea...it make sense?
>
>
> The ACLs on the line above are the same as the peek line earlier. So the
> peek line matched already, nothing reaches this line.
> <https://wiki.squid-cache.org/SquidFaq/SquidAcl#Common_Mistakes>
>
> Less ambiguous, yes, if your knowledge of Squid ACLs is low. The FAQ
> link above should help a bit here.
>
>
> Your policy ("Quick answer: Bump.") was to prefer bump'ing. For that to
> happen as step 3 it needs a stare first at step 2.
>
> So consider the stare here as the normal action this step2 is supposed
> to perform. With the peek line being the whitelist preventing stare+bump
> for special cases.
>
> > (also I dont understand what exactly the satre action do)
>
> Hmm. Think of "peek" as a postal worker reading postcards people send in
> the mail. "stare" as the postal worker both reading and rewriting them
> to remove words (s)he doesn't like or understand.
>
> Say if the a postcard ended with the words "never qwertyuio". A peek'ing
> postie would still deliver it unchanged, a stare'ing postie would
> deliver a postcard with the last word "never".
>
> If the sender/receiver of the postcard had agreed to start using crypto
> every time a message ended with "qwertyuio" - the peeking postie would
> then just see a bunch of garbage/crypted postcards start to happen. The
> stare'ing one would be able to read the content, maybe even continue
> changing things.
>
> The exact details are more complex of course, but essentially the same
> things going on.
>
>
>
> > I think this config avoid the "old client-first insecure" behaviour. I am right?
> And squid check server-certitifacte before splice.
> >
>
> Step 3 is where the "preclude" starts to matter.
>
>
> The Step 2 action determines whether the original clientHello or one
> rewritten by Squid gets sent to the server in order to get a serverHello
> out of it.
>
> AIUI, "stare step2" precludes "splice step3". So that line should be
> ignored by Squid unless there was a peek done at step2.
>
> To follow that postal analogy; client-first is like the postal worker
> simply replying to peoples postcards instead of delivering them. If/when
> they have to answer a question, writing a wholly new/different message
> to find out for itself first before answering.
>
>
> >
> > The thing that cause a lot of confusion to me is that in peek-n-splice
> environment, I can peek, plice,bump,starte in many steps (1,2,3).
> > That make the things a bit complex to decide. And of course to understand.
>
>
> Nod. One thing to be clear on is that TLS is designed to actively
> prevent MITM doing things like bump'ing. A client and server which are
> both using TLS properly cannot be bump'ed. They can only be peek'd and
> splice'd.

That is what I want to do:
Sensitive sites like banks, I dont want to bump/intercept. Instead of that, do a secure tunnel, between the client and server. May be via peeki'ng at step2?

>
> There are many features in TLS that partially or fully work towards that
> goal. So it depends on which of those are negotiated between the
> endpoints (*if* negotiated) and also whether Squid is up to date enough
> to detect and prevent them when stare'ing.
>
> There are also a bunch of different protocols happening in the HTTP
> environment these days (QUICK, CoAP, SPDY, HTTP/2 etc) - if one of those
> which Squid does not (yet) support is used to transfer TLS related data
> the endpoints may be transmitting info the proxy cannot affect.

Yes, sad but true today, I think.

>
>
> There is still an arms-race going on in TLS these days (though slowing a
> bit now). Thus the whole "only use the latest Squid release when
> SSL-Bump'ing" line we push so hard.
>

OK, let me show You the final config, explained (called config "F"):

acl noBumpSites ssl::server_name_regex -i "/etc/squid/url.nobump"

acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

ssl_bump peek step1 all

Here I am peek'ing all, to bump/splice/stare at next step.
The doc.:
"Step 1 is the only step that is always performed."
" When a peek rule matches during step1, Squid proceeds to step2 where it parses the TLS Client Hello and extracts SNI (if any)."

ssl_bump peek step2 noBumpSites

Here I am peek'ing too, but at step2 so, this makes future bump impossble.
The doc.: "Peeking at this step usually makes bumping at step 3 impossible."

I think that splice at step3 would be reduntant. Because if peek'ing here "usually" makes bump imposible at next step so squid will decide an "automagic splice noBumpSites"

ssl_bump stare step2 all

Here we star'ing at step2.
The doc.: "Staring at this step usually makes splicing at step 3 impossible."

Unlike the previous example, stare'ing at this step makes impossbile future splic'ing... therefore squid will decide an "automagic bump all"

And finally:
Due to what has been said above, these two next lines I think are redundant or not necessary.

#ssl_bump splice step3 noBumpSites
#ssl_bump bump step3 all

The doc.:
" Step 3 is only performed if a peek or stare rule matched during the previous step."
" In most cases, the only meaningful choice at step 3 is whether to terminate the connection. "
The key-line for me to understand was: "The splicing or bumping decision is usually dictated by either peeking or staring at the previous step."

So, in a brief the confi is:

ssl_bump peek step1 all
ssl_bump peek step2 noBumpSites
ssl_bump stare step2 all

Comments:
In access.log I saw the bumped traffic (sites that are not white-listed by noBumpSites ACL) and TCP_TUNNEL when a spliced connection ends.
But, also see *many* lines like these when access to a non-intercepted or spliced site, say ibm.com:

At the beggining:
NONE/200 0 CONNECT 2.19.111.47:443 - ORIGINAL_DST/2.19.111.47 -

At the end:
TCP_TUNNEL/200 197238 CONNECT 2.19.111.47:443

Final questions:

1: Is this peek-n-splice ruleset insecure? Whether if the site is bumped or spliced, both cases.
2: It is correct to say that those lines are not necessary/redundant? (#ssl_bump splice step3 noBumpSites/#ssl_bump bump step3 all)
3: Is the order of each step "correct"?


*Best regards and thank You*
Alex Rousskov
2018-09-10 19:46:33 UTC
Permalink
On 09/10/2018 12:35 PM, Julian Perconti wrote:

> So, in a brief the confi is:
>
> ssl_bump peek step1 all
> ssl_bump peek step2 noBumpSites
> ssl_bump stare step2 all

... which should be equivalent to an even simpler config:

ssl_bump peek step1
ssl_bump peek noBumpSites
ssl_bump stare all

... which, for many reasonable definitions of noBumpSites (that match
during step1 if and only if they should match during step1), can be
simplified even further:

ssl_bump peek noBumpSites
ssl_bump stare all


However, please note that the three configs above implicitly rely on
Squid splicing (or bumping) at step3 because of the previously matching
step2 peek (or stare) action and the lack of an explicit step3 rule.
Whether Squid v4.2 actually does what it should be doing, I do not know.


> 1: Is this peek-n-splice ruleset insecure?

Define "secure".


> 2: It is correct to say that those lines are not necessary/redundant?

They should be redundant, but I do not know whether Squid v4.2
implements this aspect of the specs correctly. I know that there were
related implementation bugs in some Squid v3 releases. You can test and,
if needed, file a bug report.


> (#ssl_bump splice step3 noBumpSites/#ssl_bump bump step3 all)

Please note that the meaning of your noBumpSites ACL changes from one
step to another (because it gets more/different info). Thus, it is
incorrect to say that

ssl_bump peek step1
ssl_bump peek step2 noBumpSites
ssl_bump splice step3 noBumpSites
...

is always exactly equivalent to

ssl_bump peek step1
ssl_bump peek step2 noBumpSites
ssl_bump splice step3 all # should be optional
...

When using the first configuration, it is possible that, in some
specific case, noBumpSites matches during step2 but does not match
during step3, and Squid proceeds to evaluating the remaining "..." rules
in that specific case. Such sequence of events is not possible in the
second configuration because splicing at step3 is unconditional there --
it does not rely on noBumpSites matches during step3.


HTH,

Alex.
Julian Perconti
2018-09-12 14:28:11 UTC
Permalink
> > So, in a brief the confi is:
> >
> > ssl_bump peek step1 all
> > ssl_bump peek step2 noBumpSites
> > ssl_bump stare step2 all
>
> ... which should be equivalent to an even simpler config:
>
> ssl_bump peek step1
> ssl_bump peek noBumpSites
> ssl_bump stare all

Yes, i've tested and squid log shows the same. So,it appears that squid takes the same actions.

>
> ... which, for many reasonable definitions of noBumpSites (that match during
> step1 if and only if they should match during step1), can be simplified even
> further:
>
> ssl_bump peek noBumpSites
> ssl_bump stare all

Same as above, this "compact" config seems to be the same as the three above bump ruleset.

Please, let me know if I understand why those cfg are equals or equivalent to config I've posted as a "final one".

First alternative difference:

> ssl_bump peek step1 # implicit "all" at step1
> ssl_bump peek noBumpSites # As there no step specified, squid match at any step then this line, match at step1 and then at step2 , so when a match occurs at step2 it precludes future bumping of the sites listed in the ACL.
> ssl_bump stare all # Here there is either no step2 (and any step) specified but, because in the previous line You has (implicitly) peeked at step2, the stare'ing not (or canĀ“t) applies to sites listed in ACL (they were peeked at step2).

Second alternative difference:

> ssl_bump peek noBumpSites # Like previous example, but..I guess that as there is no "all" explicit, this line do a "peek all at step1" (implicitly) and at step2 sites listed in ACL are being peek'd. To clarify, if I would add an "all" at the end of this line, then all traffic would be spliced.
> ssl_bump stare all # There is no change between this line in both configs you've posted, So my "explanation" would be the same as of the "First alternative"

> However, please note that the three configs above implicitly rely on Squid
> splicing (or bumping) at step3 because of the previously matching
> step2 peek (or stare) action and the lack of an explicit step3 rule.
> Whether Squid v4.2 actually does what it should be doing, I do not know.

Answered; squid "automagic " are working as spected. (Squid Cache: Version 4.2-20180902-r6d8f397)

>
> > 1: Is this peek-n-splice ruleset insecure?
>
> Define "secure".

Well, is not the same if there is a squid-TLS (in the LAN) between a client and sensitive external server when a TLS connection is being established as if there is nothing between they.

In this sense I would like to know how could I interference as less as possible with the squid in the middle when someone is accesing to a site that I wish not to bump.
Or let the less quantity of security holes as possible.

> > 2: It is correct to say that those lines are not necessary/redundant?
>
> They should be redundant, but I do not know whether Squid v4.2
> implements this aspect of the specs correctly. I know that there were related
> implementation bugs in some Squid v3 releases. You can test and, if needed,
> file a bug report.
>
>
> > (#ssl_bump splice step3 noBumpSites/#ssl_bump bump step3 all)
>
> Please note that the meaning of your noBumpSites ACL changes from one
> step to another (because it gets more/different info). Thus, it is incorrect to
> say that
>
> ssl_bump peek step1
> ssl_bump peek step2 noBumpSites
> ssl_bump splice step3 noBumpSites
> ...
>
> is always exactly equivalent to
>
> ssl_bump peek step1
> ssl_bump peek step2 noBumpSites
> ssl_bump splice step3 all # should be optional
> ...
>
> When using the first configuration, it is possible that, in some specific case,
> noBumpSites matches during step2 but does not match during step3, and
> Squid proceeds to evaluating the remaining "..." rules in that specific case.
> Such sequence of events is not possible in the second configuration because
> splicing at step3 is unconditional there -- it does not rely on noBumpSites
> matches during step3.

OK, thanks to clarify that.

Last question.

When I do this:

ssl_bump splice noBumpSites
ssl_bump stare all

It is supposed that in this config I am (guessing), implicity, peeking (first?) and splice at any step and bumping (implicity) at step3 sites that does not match with whitelist by staring at step2. Maybe something like that, I dont know.

The thin is that I see in the logs a tunnel but, instead an IP address it shows a domain. (TCP_TUNNEL www.dropbox.com:433) *and* a security ALERT. Saying that there is no IP that match with the xyz.net domain, or some like that.

So, taking into account the needs that I have already mentioned, what is the way I should take?

> HTH,

Always helps.

Thank You!

> Alex.
Alex Rousskov
2018-09-12 16:41:26 UTC
Permalink
On 09/12/2018 08:28 AM, Julian Perconti wrote:


> Please, let me know if I understand why those cfg are equals

I am afraid you do not. You are probably missing the fact that, at each
step, the rules after the matching applicable rule are not checked.
Also, you seem to insert some implicit peeking rules that are never
there. Finally, there may be some confusion regarding how multiple ACLs
on one line are evaluated (and/or you do not think that stepN is just an
ACL?). Details below.


> ssl_bump peek step1
> ssl_bump peek noBumpSites
> ssl_bump stare all


>> ssl_bump peek step1 # implicit "all" at step1

Yes, if you wish to think about it that way. In reality, the condition
is exactly "step1", rather than "step1 and all" or "step1 and true".


>> ssl_bump peek noBumpSites # As there no step specified, squid match at any step

Not exactly. Squid will evaluate this rule at any step that (a) reaches
this line and (b) where the peek action is applicable. The intersection
of those two preconditions is "step2" rather than "any step".


> then this line, match at step1

No, this line will not be evaluated at step1. Only the first rule is
evaluated at step1 (because that first rule always matches at step1).


> and then at step2, so when a match occurs at step2 it precludes future bumping of the sites listed in the ACL.

Yes, but that is kind of irrelevant here because there are no bump rules
to exclude. At step3, this previous/step2 peeking should result in Squid
applying the default "splice" rule (you can view that as excluding the
default "bump" rule if you wish).


>> ssl_bump stare all # Here there is either no step2 (and any step)
>> specified but, because in the previous line You has (implicitly)
>> peeked at step2, the stare'ing not (or canĀ“t) applies to sites
>> listed in ACL (they were peeked at step2).

Something like that. Step2 always happens in this configuration (so "no
step2" does not make sense), and there is no such thing as "implicit
peeking", but I think you more-or-less got the right idea here.


> ssl_bump peek noBumpSites
> ssl_bump stare all


>> ssl_bump peek noBumpSites # Like previous example, but..I guess
>> that as there is no "all" explicit, this line do a "peek all at
>> step1" (implicitly)

No, this line does not do "peek all". It does "peek noBumpSites". That
is, it tells Squid to peek when and only when both of the conditions
below are true:

(a) the peeking action is applicable (i.e., step1 or step2)
(b) the noBumpSites ACL matches

The two conditions above are evaluated in the specified order. Condition
(b) is not evaluated unless condition (a) is satisfied.



> To clarify, if I would add an "all" at the end of this line, then all traffic would be spliced.

Adding "all" to any line changes nothing as far as line matching is
considered. The value of "foo and true" is equivalent to the value of "foo".



>>> 1: Is this peek-n-splice ruleset insecure?
>>
>> Define "secure".

> Well, is not the same if there is a squid-TLS (in the LAN) between a
> client and sensitive external server when a TLS connection is being
> established as if there is nothing between they.

I am not sure I interpret your definition correctly, but I hope the
following statements will answer your question regardless of that
interpretation:

* Staring (at step2) or bumping (at any step) alters TLS bytes on the
wire. The client and the origin server will see some TLS bytes that are
going to differ from the TLS bytes they would have seen if Squid was not
there.

* In this scope, the deprecated client-first and server-first actions
are equivalent to applying the "bump" action.

* If successful, ssl_bump peek and splice actions do not alter TLS
bytes. Peeking and/or splicing Squid can be viewed as a TCP proxy as far
as TLS bytes forwarding is concerned. The client and the origin server
will see the same TLS bytes they would have seen if Squid was not there.

* In this scope, various errors are usually equivalent to applying the
"bump" action.


If your definition of "secure" is "does not change TLS bytes exchanges
between client and server", then if your configuration has a "stare"
and/or "bump" actions, it is "insecure". If your configuration may lead
to certificate validation errors, it is also "insecure".


> In this sense I would like to know how could I interference as less
> as possible with the squid in the middle when someone is accesing to
> a site that I wish not to bump.

Peeking and/or splicing does not change TLS bytes. It is passive
monitoring. See the bullets above for a more complete/precise picture.


> When I do this:
>
> ssl_bump splice noBumpSites
> ssl_bump stare all

> It is supposed that in this config I am (guessing), implicity,
> peeking (first?) and splice at any step and bumping (implicity) at
> step3 sites that does not match with whitelist by staring at step2.
> Maybe something like that, I dont know.

I do not think your description of the above configuration is correct.
Squid uses default actions ("splice" or "bump") when no applicable rules
match. In the above configuration, one of the rules will always match
during step1 and during step2 (if any). Thus, there will be no implicit
splicing or bumping during the first steps. If Squid reaches step3, then
Squid will apply the default bump rule at that step (because "stare"
matched at the previous step).

I am not sure, but I think the above configuration is equivalent to the
following configuration that does not rely on default rules:

ssl_bump splice step1 noBumpSites
ssl_bump splice step2 noBumpSites
ssl_bump stare step1
ssl_bump stare step2
ssl_bump bump step3


HTH,

Alex.
Julian Perconti
2018-09-13 03:02:56 UTC
Permalink
> I am afraid you do not. You are probably missing the fact that, at each step,
> the rules after the matching applicable rule are not checked.
> Also, you seem to insert some implicit peeking rules that are never there.
> Finally, there may be some confusion regarding how multiple ACLs on one
> line are evaluated (and/or you do not think that stepN is just an ACL?).

You're right, it's just and ACL like any other. Maybe I lost sight of that point.

> Details below.

I will keep trying to understand the best I can.

> > ssl_bump peek step1
> > ssl_bump peek noBumpSites
> > ssl_bump stare all
>
>
> >> ssl_bump peek step1 # implicit "all" at step1
>
> Yes, if you wish to think about it that way. In reality, the condition
> is exactly "step1", rather than "step1 and all" or "step1 and true".
>
>
> >> ssl_bump peek noBumpSites # As there no step specified, squid match
> at any step
>
> Not exactly. Squid will evaluate this rule at any step that (a) reaches
> this line and (b) where the peek action is applicable. The intersection
> of those two preconditions is "step2" rather than "any step".

Ok, say that the most (not to say the *only*) important beyond any step or action is the *secuential order -line_by_line-* of the rules (steps) .

Example:

ssl_bump splice noBumpSites # this will be totally ignored by Squid if a stare rule precedes this.

i.e.:

ssl_bump stare noBumpSites # No matter what, here is the Squid first match and he is at step1...
ssl_bump splice noBumpSites # ...Therefore here Squid is at step2, then this line will never match, even not having specified the step in both lines, because "noBumpSites" was already stared at first line.

Well, I am not really sure about the above example (Maybe I choosen the worst).. if I a read what the Actions do at wiki, appears doubts in mind, it's just an example about how implicit steps works.

Anyway, as an excercise I guess that in this example what Squid will do is a final "splice noBumpSites" at step2, because stare action always match at step1 (and at wiki, peek/stare description are the same)

I can not realize right now about what will happen at step3 or SslBump3.. guess that there will never be a bump, not sure.
*BUT* if in case that an implicit stare occurs at step2 due to first line, then squid will bump the "noBumpSites" and never-match/ignore the second line completely.

> > then this line, match at step1

"This line" was ssl_bump peek noBumpSites

> No, this line will not be evaluated at step1. Only the first rule is
> evaluated at step1 (because that first rule always matches at step1).
>
>
> > and then at step2, so when a match occurs at step2 it precludes future
> bumping of the sites listed in the ACL.
>
> Yes, but that is kind of irrelevant here because there are no bump rules
> to exclude. At step3, this previous/step2 peeking should result in Squid
> applying the default "splice" rule (you can view that as excluding the
> default "bump" rule if you wish).

Yes, that's the idea, default/implicit bump all, except the "noBumpSites", but maybe is not the best way to do that.

> >> ssl_bump stare all # Here there is either no step2 (and any step)
> >> specified but, because in the previous line You has (implicitly)
> >> peeked at step2, the stare'ing not (or canĀ“t) applies to sites
> >> listed in ACL (they were peeked at step2).
>
> Something like that. Step2 always happens in this configuration (so "no
> step2" does not make sense), and there is no such thing as "implicit
> peeking", but I think you more-or-less got the right idea here.

I didn't know that no exists "implicit peeking" as you said above. Instead, I always thought that peeking was mandatory.
Resume: Implicit splice and bump exists aalways exists. Implicit peek, no. Is this correct?

See my doubt at the end...and conclusion.

> >> ssl_bump peek noBumpSites # Like previous example, but..I guess
> >> that as there is no "all" explicit, this line do a "peek all at
> >> step1" (implicitly)
>
> No, this line does not do "peek all". It does "peek noBumpSites". That
> is, it tells Squid to peek when and only when both of the conditions
> below are true:
>
> (a) the peeking action is applicable (i.e., step1 or step2)
> (b) the noBumpSites ACL matches
>
> The two conditions above are evaluated in the specified order. Condition
> (b) is not evaluated unless condition (a) is satisfied.

Another important point to keep in mind what your are telling above.

> > To clarify, if I would add an "all" at the end of this line, then all traffic would
> be spliced.
>
> Adding "all" to any line changes nothing as far as line matching is
> considered. The value of "foo and true" is equivalent to the value of "foo".

So the word "all" makes sense if its is "alone"? Or not even like that?
e.g.: ssl_bump peek step1 all = ssl_bump peek step1, *always*?

> I am not sure I interpret your definition correctly, but I hope the
> following statements will answer your question regardless of that
> interpretation:
>
> * Staring (at step2) or bumping (at any step) alters TLS bytes on the
> wire. The client and the origin server will see some TLS bytes that are
> going to differ from the TLS bytes they would have seen if Squid was not
> there.
>
> * In this scope, the deprecated client-first and server-first actions
> are equivalent to applying the "bump" action.
>
> * If successful, ssl_bump peek and splice actions do not alter TLS
> bytes. Peeking and/or splicing Squid can be viewed as a TCP proxy as far
> as TLS bytes forwarding is concerned. The client and the origin server
> will see the same TLS bytes they would have seen if Squid was not there.
>
> * In this scope, various errors are usually equivalent to applying the
> "bump" action.

Very clear and useful explanation

>
> If your definition of "secure" is "does not change TLS bytes exchanges
> between client and server"

Yes, you have correctly understood what I tried to mean with the term "secure"; Say..: "Don't let squid touch sites that should not be touched" ...or some like that.

>, then if your configuration has a "stare"
> and/or "bump" actions, it is "insecure". If your configuration may lead
> to certificate validation errors, it is also "insecure".

Does not the splice at step1 and step2 action avoid this? I mean if squid act as a -TCP forward proxy only- for noBumpSites. "Don't touch TLS bytes"

> > When I do this:
> >
> > ssl_bump splice noBumpSites
> > ssl_bump stare all
>
> > It is supposed that in this config I am (guessing), implicity,
> > peeking (first?) and splice at any step and bumping (implicity) at
> > step3 sites that does not match with whitelist by staring at step2.
> > Maybe something like that, I dont know.
>
> I do not think your description of the above configuration is correct.
> Squid uses default actions ("splice" or "bump") when no applicable rules
> match. In the above configuration, one of the rules will always match
> during step1 and during step2 (if any). Thus, there will be no implicit
> splicing or bumping during the first steps. If Squid reaches step3, then
> Squid will apply the default bump rule at that step (because "stare"
> matched at the previous step).
>
> I am not sure, but I think the above configuration is equivalent to the
> following configuration that does not rely on default rules:
>
> ssl_bump splice step1 noBumpSites
> ssl_bump splice step2 noBumpSites
> ssl_bump stare step1
> ssl_bump stare step2
> ssl_bump bump step3

According to Amos: Always is better to be explicit and bump at step3 after stare at step2. (And of course more clearly to understand)

I have tested this above config (I think that this one you've posted is what I want to do) against the "compact/default one (the last "2-lines-config" above) and I almost sure that the squid logs reports the same behaviour, and maybe there are less lines with: "ssl" lib errors...and "Security Alert: there is no ip/domain match...."

BUT here you are never peek'ing? How is that?
You are stare'ing instead of peek'ing at step1 (3rd line), I would have done a peek at that line. I refered to this question when I said "see the doubt at the end..." at almost at the middle of msg..

> HTH,
>
> Alex.

OK....:

I think that is enough. We should make a pause or close the thread.
I *MUST* as soon as possible re-re and re-read the this thread entirely again and again.. And the Wiki page too.
Because I am remembering (in English as well as I can) that Amos said things that You are telling me -again- (maybe in other words, but that isn't important neither the point)

All the best,

Thank You all
Alex Rousskov
2018-09-13 15:00:14 UTC
Permalink
On 09/12/2018 09:02 PM, Julian Perconti wrote:

> ssl_bump peek step1
> ssl_bump peek noBumpSites
> ssl_bump stare all

>>>> ssl_bump peek noBumpSites # As there no step specified, squid match
>>>> at any step

>> Not exactly. Squid will evaluate this rule at any step that (a) reaches
>> this line and (b) where the peek action is applicable. The intersection
>> of those two preconditions is "step2" rather than "any step".

> Ok, say that the most (not to say the *only*) important beyond any step or action is the *secuential order -line_by_line-* of the rules (steps) .
>
> Example:
>
> ssl_bump splice noBumpSites # this will be totally ignored by Squid if a stare rule precedes this.

No, this is incorrect. There are many cases were a previous stare rule
will not have the effect you state it will. For example:

# Squid may splice at step2 despite the preceding stare rule
# because staring at step1 does not preclude splicing.

ssl_bump stare step1
ssl_bump splice noBumpSites

and

# Squid will splice at step1 despite the preceding stare rule
# because the preceding stare rule never matches
ssl_bump stare !all
ssl_bump splice all


> ssl_bump stare noBumpSites # No matter what, here is the Squid first
> match and he is at step1...

> ssl_bump splice noBumpSites # ...Therefore here Squid is at step2,
> then this line will never match, even not having specified the step
> in both lines, because "noBumpSites" was already stared at first
> line.
You seem to be assuming that the action during the previous step is
important even if the rule with that action did not match during the
previous step. That is incorrect. The previous step action may be
important only if it was actually used during that previous step (i.e.
Squid reached that action's rule and that rule's ACLs matched).


> if in case that an implicit stare occurs at step2 due to first line,
> then squid will [...] never-match/ignore the second line completely.

That is correct. The part in [...] was a bit misleading because it
depended on the not shown (default?) rules, so I removed it.



> Resume: Implicit splice and bump exists aalways exists. Implicit peek, no. Is this correct?

There are ways to interpret this statement correctly, but I would not
phrase it this way.

A better statement would be that when no rule matched at a given step,
Squid uses the default rule. The default rule is "bump" if Squid stared
at the previous step. The default rule is "splice" in all other cases,
including the case where no rule matched during the first step (i.e.
there was no "previous step").


>> Adding "all" to any line changes nothing as far as line matching is
>> considered. The value of "foo and true" is equivalent to the value of "foo".
>
> So the word "all" makes sense if its is "alone"?

The documented ssl_bump line syntax requires an ACL. If you want a rule
to always match, use an "all" ACL. Ideally, the syntax should be relaxed
to not require an ACL at all in those cases. I did not check whether the
implementation matches the documentation.


> e.g.: ssl_bump peek step1 all = ssl_bump peek step1, *always*?

Yes, as far as rule matching is concerned. The "all" ACL always matches.


>> if your configuration has a "stare"
>> and/or "bump" actions, it is "insecure". If your configuration may lead
>> to certificate validation errors, it is also "insecure".

> Does not the splice at step1 and step2 action avoid this? I mean if
> squid act as a -TCP forward proxy only- for noBumpSites. "Don't touch
> TLS bytes"

I am not sure what you mean by "this" exactly, but splicing (at any
step) does not guarantee the lack of errors. The earlier you tell Squid
to splice the connections, the fewer checks Squid will do, decreasing
the probability of an error. Errors lead to bumping the client
connection (to deliver the error message).


>>> When I do this:
>>>
>>> ssl_bump splice noBumpSites
>>> ssl_bump stare all
>>
>>> It is supposed that in this config I am (guessing), implicity,
>>> peeking (first?) and splice at any step and bumping (implicity) at
>>> step3 sites that does not match with whitelist by staring at step2.
>>> Maybe something like that, I dont know.
>>
>> I do not think your description of the above configuration is correct.
>> Squid uses default actions ("splice" or "bump") when no applicable rules
>> match. In the above configuration, one of the rules will always match
>> during step1 and during step2 (if any). Thus, there will be no implicit
>> splicing or bumping during the first steps. If Squid reaches step3, then
>> Squid will apply the default bump rule at that step (because "stare"
>> matched at the previous step).
>>
>> I am not sure, but I think the above configuration is equivalent to the
>> following configuration that does not rely on default rules:
>>
>> ssl_bump splice step1 noBumpSites
>> ssl_bump splice step2 noBumpSites
>> ssl_bump stare step1
>> ssl_bump stare step2
>> ssl_bump bump step3

> According to Amos: Always is better to be explicit and bump at step3
> after stare at step2. (And of course more clearly to understand)

That "always better to be explicit" recipe fails when you cannot tell (a
priori) what the previous step result was. In those cases, you may want
to rely on the default rules (after making sure they work) OR rewrite
the configuration so that you know for sure what the previous step
result was. In the two-line configuration above, we always know what the
previous step result was, so it is possible to add an explicit (and
correct) step3 action.

Which configuration is clearer depends on the observer. Use whatever
correct variant looks best to _you_.


> BUT here you are never peek'ing? How is that?

Staring at step1 performs the same actions as peeking at step1. The only
difference is the side effect on the default rules choice for step2 (if
Squid needs to make that choice). In both of the above configurations,
there is no need for Squid to make that choice for step2.


Alex.
Julian Perconti
2018-09-14 00:13:40 UTC
Permalink
> > Example:
> >
> > ssl_bump splice noBumpSites # this will be totally ignored by Squid if a
> stare rule precedes this.
>
> No, this is incorrect. There are many cases were a previous stare rule will not
> have the effect you state it will. For example:
>
> # Squid may splice at step2 despite the preceding stare rule
> # because staring at step1 does not preclude splicing.
>
> ssl_bump stare step1
> ssl_bump splice noBumpSites

Well yes, I think You are right; but my example (or what I wanted to mean) was: -Maybe You have post that to give an example about how that rule could probably, not match, I don't know-

ssl_bump stare noBumpSites (at this line your example said: ssl_bump stare step1)
ssl_bump splice noBumpSites

...And here appears a "key-question":

ssl_bump stare noBumpSites # This is the first line of SslBumps ruleset.

So, when squid reaches this first rule and line (there is no explicit step) ...does Squid make a "bucle of steps" only along the first line and go to next line only when the rule stop being applicable/matchable?
If the answer of my question is: "Yes" then the second line has not any effect because, I guess that squid will do a bump in more-or-less this way:

ssl_bump stare noBumpSites

... is the same as:

ssl_bump stare step1 noBumpSites
ssl_bump stare step2 noBumpSites # Here is where he second line stops making sense
ssl_bump bump step3 noBumpSites # Finally bump due to the previous step

Thus:

ssl_bump splice noBumpSites # will never matchs.

Going a bit to the past, Amos explained the following when I asked:

>> ...So that means that squid processes the SslBump directives:
>> 1: maybe more than one time in a single request...?
>>
>Yes. Up to 3 times. A peek or splice action causes another check later.

Well, Amos never mentioned a "stare" action here, so I dont know I a "stare" applies to this too.
And even worse, maybe I did not understand him correctly.

> # Squid will splice at step1 despite the preceding stare rule
> # because the preceding stare rule never matches
> ssl_bump stare !all
> ssl_bump splice all

And this example is more obvious than the first one. It is like that previous line would not exists.

(...)

> > Does not the splice at step1 and step2 action avoid this? I mean if
> > squid act as a -TCP forward proxy only- for noBumpSites. "Don't touch
> > TLS bytes"
>
> I am not sure what you mean by "this" exactly, but splicing (at any
> step) does not guarantee the lack of errors.

Ok, but is Squid the culprit of those error? He is being a passive observer of that TLS traffic.
Here, I am talking about the idea of (explicitly) splice at step1 and then at step2 of a white list of sites.

Question based on words below:

>>>* If successful, ssl_bump peek and splice actions do not alter TLS
>>>bytes. Peeking and/or splicing Squid can be viewed as a TCP proxy as far
>>>as TLS bytes forwarding is concerned. The client and the origin server
>>>will see the same TLS bytes they would have seen if Squid was not there.
>>>
>>>* In this scope, various errors are usually equivalent to applying the
>>>"bump" action.

>The earlier you tell Squid to
> splice the connections, the fewer checks Squid will do, decreasing the
> probability of an error.

That is the idea with the noBumpSites ACL, the least amount of errors possible.

Lets say: "Let's remove as much responsibility as possible to Squid about what happens with really/special sensitive sites, If something goes wrong"
Talking with Squid/In other words: "Squid, do a *full* bump to msn.com and youtube.com too; but please *never do not nothing neither touch nothing* with bankaust.com.au
(Some like that)

> Errors lead to bumping the client connection (to
> deliver the error message).

What do You mean about those errors?

Thank You
Alex Rousskov
2018-09-14 15:17:34 UTC
Permalink
On 09/13/2018 06:13 PM, Julian Perconti wrote:

> ssl_bump stare noBumpSites # This is the first line of SslBumps ruleset.

> So, when squid reaches this first rule and line (there is no explicit
> step) ...does Squid make a "bucle of steps" only along the first
> line and go to next line only when the rule stop being
> applicable/matchable?

I hesitate answering that question with a simple "yes" or "no" because
any such answer is likely to mislead folks reading this email.

The overall logic is like this:

for each step
do
for each rule
do
if the rule action is possible and the rule ACLs match,
then perform the rule action and either go to the next
step or, after applying the final action, exit
done
apply the default action and exit
done


The overall logic is _not_ like this:

for each rule
do
for each step
...
done

So, "yes", Squid only executes the first rule action _when_ the first
rule action is applicable and its ACLs match at every step, but, "no",
Squid does not make a bunch of steps with only the first rule in mind.


>>> Does not the splice at step1 and step2 action avoid this? I mean if
>>> squid act as a -TCP forward proxy only- for noBumpSites. "Don't touch
>>> TLS bytes"

>> I am not sure what you mean by "this" exactly, but splicing (at any
>> step) does not guarantee the lack of errors.

> Ok, but is Squid the culprit of those error?

Usually not. Common errors include network connectivity errors, client
Host validation errors, server certificate validation errors, and being
fed a non-TLS protocol. However, it could be Squid itself. Bugs do happen.


> He is being a passive observer of that TLS traffic.

Squid also validates what it observes/forwards. And there is also TCP/IP
traffic before (and around) TLS traffic.


> Here, I am talking about the idea of (explicitly) splice at step1 and then at step2 of a white list of sites.

If you splice at step1, then the number of validations that Squid does
would be smaller (possibly zero, not sure) than if you splice at step2.
Same for the step2/step3 difference. TCP/IP-level errors may be present
at every step.


> Lets say: "Let's remove as much responsibility as possible to Squid
> about what happens with really/special sensitive sites, If something
> goes wrong"

Your overall intent was clear many emails ago, and it is a common
desire/need. The devil is in the details:

* A key detail here is determining whether the intended site _is_
"really/special sensitive". For example, the intercepted client is
connecting to b::a:d IPv6 address while claiming in the TLS Hello that
it is trying to get to sensitive.example.com. Should Squid trust the
intended destination IP address or the TLS SNI? Or should we wait for
the server to identify itself with a valid SSL certificate? Etc.

* The other key detail is what should happen when that sensitive site
refuses to communicate with Squid or otherwise misbehaves. Should Squid,
for example, simply close the browser connection, making it more likely
that the user (or their admin) blames the proxy? Or should Squid bump
the browser connection to explain what has happened, creating all the
headaches associated with bumping.

Your Squid configuration should reflect all these key decisions.

If Squid does not have enough configuration options or code to do
exactly what you want, then you (or others) can always add more
code/options. If your use case is common/general enough, then quality
implementations of those additional features should be officially accepted.


Alex.
Julian Perconti
2018-09-17 17:53:21 UTC
Permalink
> > So, when squid reaches this first rule and line (there is no explicit
> > step) ...does Squid make a "bucle of steps" only along the first line
> > and go to next line only when the rule stop being
> > applicable/matchable?
>
> I hesitate answering that question with a simple "yes" or "no" because any
> such answer is likely to mislead folks reading this email.

Well yes, and I hope that this thread helps to others.

>
> The overall logic is like this:
>
> for each step
> do
> for each rule
> do
> if the rule action is possible and the rule ACLs match,
> then perform the rule action and either go to the next
> step or, after applying the final action, exit
> done
> apply the default action and exit
> done

Well, this explanation merits to copy it and paste into squid.conf as a comment.

Let me know if I understand what Squid does with the rules of SslBump through this logic:

> for each step
> do # This loop will execute as maximum up to three times; because there are 3 steps in the entire SslBump environment.

> for each rule
> do # ...and this loop, will execute as many times as the amount of the rules the config has.

Probably my interpretation of the nested loop is wrong.

Now, How does Squid takes and retains decisions when the steps are implicit/explicit throught the rules? The developers knows the details.

> > He is being a passive observer of that TLS traffic.
>
> Squid also validates what it observes/forwards. And there is also TCP/IP
> traffic before (and around) TLS traffic.

OK, so I will peek, instead of splice at step1 and step2; and the final action will be splice and it will happen at step3; the step where the final actions are always taken.

I think that splice at step1 does not make sense according to the doc. and also to the order of steps or the sequence, about how the rules are evaluated.
By other hand, lets squid to do more checks even if a sites will be spliced: to do that, as I said above, I (think that) have to peek instead splice at step1 and step2.

Even more, about the step3 the squid doc. says:
I: Get TLS Server Hello info from the server, including the server certificate.
II: Validate the TLS server certificate.

Finally, the thing that really does not makes sense is splice at step1 and then splice at step2:
Acording to squid doc.: "step2/step3 is only performed if a peek or stare rule matched during the previous step." (not a splice rule)

> > Here, I am talking about the idea of (explicitly) splice at step1 and then at
> step2 of a white list of sites.
>
> If you splice at step1, then the number of validations that Squid does would
> be smaller (possibly zero, not sure) than if you splice at step2.

Again, following the documentation: "Step 2 is only performed if a peek or stare rule matched during the previous step." So, Is "correct" to splice at step1 or step2?

> The devil is in the details:

Always.

> * A key detail here is determining whether the intended site _is_
> "really/special sensitive". For example, the intercepted client is connecting to
> b::a:d IPv6 address while claiming in the TLS Hello that it is trying to get to
> sensitive.example.com. Should Squid trust the intended destination IP
> address or the TLS SNI? Or should we wait for the server to identify itself
> with a valid SSL certificate? Etc.

From the "security side" I think that the second option. "...wait for the server to identify (...)"

Therefore, I think that as is "more secure" bump at step3 then should be more secure splice at step3 too.

> * The other key detail is what should happen when that sensitive site refuses
> to communicate with Squid or otherwise misbehaves. Should Squid, for
> example, simply close the browser connection, making it more likely that the
> user (or their admin) blames the proxy? Or should Squid bump the browser
> connection to explain what has happened, creating all the headaches
> associated with bumping.

Do not what to say at this point. Maybe I am missing something...

> Your Squid configuration should reflect all these key decisions.
> If Squid does not have enough configuration options or code to do exactly
> what you want, then you (or others) can always add more code/options. If
> your use case is common/general enough, then quality implementations of
> those additional features should be officially accepted.

Well, let me show You, what is my *second final* config to do the the most approximate actions I want Squid do and who has read the thread knows, taken as a conclusion of the thread:

Telling to Squid what exactly he has to do at each step explicitly:

ssl_bump peek step1 noBumpSites # at step1 peak or stare do the same, but Amos says that stare alters "the letters" while peek no.
ssl_bump peek step2 noBumpSites
ssl_bump splice step3 noBumpSites # This is probably reduntant
ssl_bump stare step1 # Maybe It is the same if I peek here instead stare, because the difference about stare and peek happens at step2, the same come could be stay at first line, not sure.
ssl_bump stare step2
ssl_bump bump step3 # This is even more reduntant too.

If You have a look at helion.pl and/or the original config and compare his config and my own above are very similar (not to say identical)

As an excercise a more compact config that do more-or-less the same would be:

ssl_bump peek noBumpSites
ssl_bump stare

But, what happen if Squid decides automagically wrong? Or something does not match...?

Do You think that the above rules is more-or-less the more nearest what I want to do?
Excuse me but, I think that at this stage, I gues that You already know what I mean when I say "...what I want to do?"
Alex Rousskov
2018-09-17 19:57:12 UTC
Permalink
On 09/17/2018 11:53 AM, Julian Perconti wrote:

>> The overall logic is like this:
>>
>> for each step
>> do
>> for each rule
>> do
>> if the rule action is possible and the rule ACLs match,
>> then perform the rule action and either go to the next
>> step or, after applying the final action, exit
>> done
>> apply the default action and exit
>> done

> Let me know if I understand what Squid does with the rules of SslBump through this logic:
>
>> for each step
>> do # This loop will execute as maximum up to three times; because there are 3 steps in the entire SslBump environment.

Yes.


>> for each rule
>> do # ...and this loop, will execute as many times as the amount of the rules the config has.

For each other loop iteration, this inner loop will execute zero or more
times, depending on the number _and_ meaning/content of the rules.

Both loops can finish "early" (i.e. before three steps and/or before all
configured rules are evaluated).



> Now, How does Squid takes and retains decisions when the steps are
> implicit/explicit throught the rules?

See my loops summary above: If the inner loop runs to its completion,
then Squid applies the default action (because the inner loop found no
usable explicit rules). There is no secret magic here (at least not at
this level of detail).


> OK, so I will peek, instead of splice at step1 and step2; and the
> final action will be splice and it will happen at step3; the step
> where the final actions are always taken.

Just to avoid misunderstanding: Final actions may be taken at any step,
but only final actions are possible at step3.


> I think that splice at step1 does not make sense according to the
> doc. and also to the order of steps or the sequence, about how the
> rules are evaluated.

I do not know what you mean. Splice at step1 is certainly possible and
even recommended for known non-TLS traffic.


> the thing that really does not makes sense is splice at step1 and then splice at step2:

It is not possible to splice twice. Splicing is one of the final
actions. No other action follows a final action (by definition). Search
for the two "exit" words in the loop summary to find where final actions
may be applied.


> Acording to squid doc.: "step2/step3 is only performed if a peek or
> stare rule matched during the previous step." (not a splice rule)

Correct.


> So, Is "correct" to splice at step1 or step2?

The best thing to do depends on your goals and the transaction. Splicing
at step1, step2, OR step3 makes sense in some cases and does not make
sense (or is impossible) in others.

You need to evaluate your rules in the context of a specific transaction
though: The same set of ssl_bump rules may splice transaction A at step1
and transaction C at step3. The loops summarized above are executed from
scratch for every transaction that reaches ssl_bump directive evaluation.


>> * A key detail here is determining whether the intended site _is_
>> "really/special sensitive". For example, the intercepted client is connecting to
>> b::a:d IPv6 address while claiming in the TLS Hello that it is trying to get to
>> sensitive.example.com. Should Squid trust the intended destination IP
>> address or the TLS SNI? Or should we wait for the server to identify itself
>> with a valid SSL certificate? Etc.

> From the "security side" I think that the second option. "...wait for the server to identify (...)"

> Therefore, I think that as is "more secure" bump at step3 then should be more secure splice at step3 too.

It is impossible to make "splice or bump" decision at step3 because
splicing at step3 requires peeking at step2 while bumping at step3
requires staring at step2. In a context of a single transaction, it is
impossible to both peek and stare at the same time!

Thus, you essentially have to make that "splice or bump" decision
earlier, at step1 or step2, when you have less information than you
would have at step3. It is almost like the dominant quantum physics
theory -- by measuring at step2, you determine the outcome of that
measurement (i.e. available actions at step3).


> Telling to Squid what exactly he has to do at each step explicitly:
>
> ssl_bump peek step1 noBumpSites # at step1 peak or stare do the same, but Amos says that stare alters "the letters" while peek no.

A matching peek rule at step1 results in (TLS Client Hello being parsed
during) step2. It also tells Squid to splice by default at step2 if
Squid needs to apply a default action at step2.

A matching stare rule at step1 results in (TLS Client Hello being parsed
during) step2. It also tells Squid to bump by default at step2 if Squid
needs to apply a default action at step2.

There are no TLS byte modifications during peeking or staring at step1.

I think this is all documented at
https://wiki.squid-cache.org/Features/SslPeekAndSplice



> ssl_bump peek noBumpSites
> ssl_bump stare
>
> But, what happen if Squid decides automagically wrong? Or something does not match...?

I do not know what you mean by "Squid decides automagically wrong"

At step1 and at step2, if noBumpSites matches, then Squid will peek.

At step1 and at step2, if noBumpSites does not match, then Squid will stare.

At step3, no explicit rules can match so Squid will either splice or
bump, depending on whether noBumpSites matched at step2.




> Do You think that the above rules is more-or-less the more nearest
> what I want to do? Excuse me but, I think that at this stage, I gues
> that You already know what I mean when I say "...what I want to do?"

Sorry, I do not. And since there are many details that define what one
wants to (or should) do, it may be impractical to relay all of them on
an informal email thread. However, if you understand how SslBump rules
work, then you can either answer a vague "Am I doing what I want to be
doing?" question yourself or ask more specific questions that can be
answered on the mailing list.

Alex.
Alex Rousskov
2018-09-17 20:04:20 UTC
Permalink
On 09/17/2018 01:57 PM, Alex Rousskov wrote:

> For each other loop iteration, this inner loop will execute zero or more
> times, depending on the number _and_ meaning/content of the rules.

Typo: s/other loop/outer loop/

Alex.
Julian Perconti
2018-09-18 15:11:25 UTC
Permalink
> Both loops can finish "early" (i.e. before three steps and/or before all
> configured rules are evaluated).

Yes, maybe I would have should say at least: "Well in really, depend on the rules.." Especially in the inner loop.
But I pointed to the maximum possibilities. (if exists)

> Just to avoid misunderstanding: Final actions may be taken at any step, but
> only final actions are possible at step3.

Good point.
My mistake, I forgot that.
In fact, in the actions table its clear that a final action like terminate can occurs at any step and even worst, any action can occurs at step1.
From another point of view: at step3 only final actions are allowed.

> > I think that splice at step1 does not make sense according to the doc.
> > and also to the order of steps or the sequence, about how the rules
> > are evaluated.
>
> I do not know what you mean. Splice at step1 is certainly possible and even
> recommended for known non-TLS traffic.

Idem; same comments as above.

> > the thing that really does not makes sense is splice at step1 and then splice
> at step2:
>
> It is not possible to splice twice. Splicing is one of the final actions. No other
> action follows a final action (by definition). Search for the two "exit" words in
> the loop summary to find where final actions may be applied.

So, if a rule "x" match a splice action at inner loop when the outer loop starts, then take the final action for the rule "x" and if no there is no more rules at step1 exit and proceed to evaluate the rules for the step2.
Some like that?

> The best thing to do depends on your goals and the transaction. Splicing at
> step1, step2, OR step3 makes sense in some cases and does not make sense
> (or is impossible) in others.
>
> You need to evaluate your rules in the context of a specific transaction
> though: The same set of ssl_bump rules may splice transaction A at step1 and
> transaction C at step3. The loops summarized above are executed from
> scratch for every transaction that reaches ssl_bump directive evaluation.

I lost You here.

> It is impossible to make "splice or bump" decision at step3 because splicing at
> step3 requires peeking at step2 while bumping at step3 requires staring at
> step2. In a context of a single transaction, it is impossible to both peek and
> stare at the same time!
> Thus, you essentially have to make that "splice or bump" decision earlier, at
> step1 or step2, when you have less information than you would have at
> step3. It is almost like the dominant quantum physics theory -- by measuring
> at step2, you determine the outcome of that measurement (i.e. available
> actions at step3).

Wait, maybe I do not explain myself well or I don not understand what do You want to mean; the ACL at every step are not the same. See below.

> > ssl_bump peek noBumpSites
> > ssl_bump stare

It suppsed that here due to acl in the first line, squid will bump later, all except sites that matches the acl.

> > But, what happen if Squid decides automagically wrong? Or something
> does not match...?
>
> I do not know what you mean by "Squid decides automagically wrong"

Well, it was just an (probably bad one) idea/thought.

> At step1 and at step2, if noBumpSites matches, then Squid will peek.
Therefore default splice...

> At step1 and at step2, if noBumpSites does not match, then Squid will stare.
...and default bump.

> At step3, no explicit rules can match so Squid will either splice or bump,
> depending on whether noBumpSites matched at step2.

Yes, just an aclaration: in this specific case "At step3, no explicit rules can match" (not anymore).
All was already done in the previous steps.

> > Do You think that the above rules is more-or-less the more nearest
> > what I want to do? Excuse me but, I think that at this stage, I gues
> > that You already know what I mean when I say "...what I want to do?"
>
> Sorry, I do not. And since there are many details that define what one wants
> to (or should) do, it may be impractical to relay all of them on an informal
> email thread. However, if you understand how SslBump rules work, then you
> can either answer a vague "Am I doing what I want to be doing?" question
> yourself or ask more specific questions that can be answered on the mailing
> list.

Ok I am sorry for that, I understood that You had an idea about what I want to do, in a earlier message.
I will answer with a "little" change in the last config to illustrate what I should/want to do in my scenario.

It was: (Again: With this cfg I dont see any domain in TCP_TUNNEL neither the Security alerts..)

ssl_bump peek noBumpSites # Here two steps will happen. And final action (splice) happens at step3 by default.
ssl_bump stare

And now is: (And with this I see the domain:443 in TCP_TUNNEL and Security alerts about the domain and ip match in the logs.)

ssl_bump splice noBumpSites # This line reachs a splice rule at step1 and that is a final action, without future proccesing.
ssl_bump stare

Squid is telling to the client (in last config.) :
"I will not touch any TLS byte. I can not do much about the security risk you may run. Despite what I said, I will do as many checks as possible then You will be connected..."

Maybe splice at step1 I am leaving the client alone. But, what can I do?
I have to choose: peek at 1 and 2 like before (and errors can happen; that is why I have reopened the thread... the cause was an error message from squid while a client was trying to access a bank site) or just splice (less checks,maybe less errors).

Thank You again.
Alex Rousskov
2018-09-18 16:36:10 UTC
Permalink
On 09/18/2018 09:11 AM, Julian Perconti wrote:
>>> the thing that really does not makes sense is splice at step1 and then splice
>>> at step2

>> It is not possible to splice twice. Splicing is one of the final actions. No other
>> action follows a final action (by definition).

> So, if a rule "x" match a splice action at inner loop when the outer
> loop starts, then take the final action for the rule "x" and if no
> there is no more rules at step1 exit and proceed to evaluate the
> rules for the step2.

I think it is possible to interpret your summary as a correct statement,
but the reality is much simpler: After a splice rule is applied, SslBump
is over. No more rules are checked. No more loops are iterated. Squid
simply "exits" the SslBump feature (and becomes a TCP tunnel).


>>> ssl_bump peek noBumpSites
>>> ssl_bump stare


>> At step1 and at step2, if noBumpSites matches, then Squid will peek.

> Therefore default splice...

If noBumpSites matches at step2, then, yes, Squid will splice at step3
by default. Otherwise, no; Squid will bump at step3 by default.


>> At step1 and at step2, if noBumpSites does not match, then Squid will stare.

> ...and default bump.

If noBumpSites does not match at step2, then, yes, Squid will bump at
step3 by default. Otherwise, no; Squid will splice at step3 by default.


> ssl_bump splice noBumpSites # This line reachs a splice rule at step1
> ssl_bump stare

> Squid is telling to the client: "I will not touch any TLS byte. [...]
> I will do as many checks as possible then You will be connected..."

The configuration above does not match your summary because the
configuration has a "stare" action that may run at (step1 and) step2
(and, hence, a possibility of the bump action at step3). Staring at
step2 and bumping (at any step) modify TLS bytes, of course.

Perhaps your summary only applies to the cases where noBumpSites matches
(either at step1 or at step2), but the summary did not make that clear.
There is a big difference between explaining Squid actions for a
particular transaction and summarizing what a particular configuration
means (for all transactions). Unless noted otherwise, I am focusing on
the latter.

AFAICT, the primary difference between

ssl_bump peek noBumpSites
ssl_bump stare

and

ssl_bump splice noBumpSites
ssl_bump stare

is that the former requires a noBumpSites match at step2 for the
connections to be spliced. The latter does not require that; it is even
content with splicing based on step1 (i.e. TCP/IP) info, before knowing
step2 (i.e. the TLS client) details. You can see those differences when,
for example, noBumpSites does not match at step1.

The other differences include whether the TLS client- and
server-provided information is checked and logged in all cases or just
in some cases.

Alex.
Julian Perconti
2018-09-19 16:23:28 UTC
Permalink
>After a splice rule is applied, SslBump is over. No more rules are
>checked. No more loops are iterated. Squid simply "exits" the SslBump
>feature (and becomes a TCP tunnel).

How is that? What about the meaning of the ACL's at step1 when splice?

e.g.:
There only these two rules for ssl_bump statements:

ssl_bump step1 splice sitesAB
ssl_bump step1 splice SitesCD

I guess that here, Squid has to do 2 loops at outer/main loop to evaluate step1 twice, due to rules differs (sitesAB and sitesCD ACL) and see if both match to splice.
Probably this example does not make sense: "Why don't use just 1 ACL instead 2"? But it is an example to understand and fix ideas.

Are You (perhaps) talking about the examples in the thread and not what happens "in general"?

> If noBumpSites matches at step2, then, yes, Squid will splice at step3
> by default. Otherwise, no; Squid will bump at step3 by default.

[... ]

You mentioned that explanation two times.
The question (maybe obvious) is: In which case the "noBumpSites" ACL could have not match? I mean if I tell a Squid: "splice at step1 this.site.net" How that matches can fail?
Maybe you refered in the case that a site is just not listed in the ACL.

> > ssl_bump splice noBumpSites # This line reachs a splice rule at step1
> > ssl_bump stare
>
> > Squid is telling to the client: "I will not touch any TLS byte.
> > [...] I will do as many checks as possible then You will be connected..."
>
> The configuration above does not match your summary because the
> configuration has a "stare" action that may run at (step1 and) step2
> (and, hence, a possibility of the bump action at step3). Staring at
> step2 and bumping (at any step) modify TLS bytes, of course.
>
> Perhaps your summary only applies to the cases where noBumpSites
> matches (either at step1 or at step2), but the summary did not make
> that clear.

Here borns more ore less the same doubt like above and the final one.

> There is a big difference between explaining Squid actions for a
> particular transaction and summarizing what a particular configuration
> means (for all transactions). Unless noted otherwise, I am focusing on the latter.
>
> AFAICT, the primary difference between
>
> ssl_bump peek noBumpSites
> ssl_bump stare
>
> and
>
> ssl_bump splice noBumpSites
> ssl_bump stare
>
> is that the former requires a noBumpSites match at step2 for the
> connections to be spliced.

Yes. The condition you say is mandatory but, again: Why that requirement could fail/no-match?

Thank You for the patience
Alex Rousskov
2018-09-19 21:35:29 UTC
Permalink
On 09/19/2018 10:23 AM, Julian Perconti wrote:
>> Alex: After a splice rule is applied, SslBump is over. No more rules are
>> checked. No more loops are iterated. Squid simply "exits" the SslBump
>> feature (and becomes a TCP tunnel).

> What about the meaning of the ACL's at step1 when splice?

* If the splice rule ACLs match, the splice rule is applied. In that
case you can consult my statement above.

* If the splice rule ACLs do not match, then the splice rule is not
applied. My statement above explicitly does not cover this case -- it
starts with "after a splice rule is APPLIED".


> e.g.:
> There only these two rules for ssl_bump statements:
>
> ssl_bump splice sitesAB
> ssl_bump splice SitesCD

> I guess that here, Squid has to do 2 loops at outer/main loop to
> evaluate step1 twice, due to rules differs (sitesAB and sitesCD ACL)
> and see if both match to splice.

I do not know why you are guessing instead of carefully applying the
already documented procedure, but you guessed wrong. At any step, the
first matching rule is applied. For example, if sitesAB matches, then
Squid splices without checking the second (i.e. SitesCD) rule.

N.B. I removed the (misplaced) "step1" ACLs from the above example. That
ACL does not affect the above discussion.


> Are You (perhaps) talking about the examples in the thread and not what happens "in general"?

My statements above are general except the "For example..." sentence
that refers to your specific example.


> In which case the "noBumpSites" ACL could have not match? I mean if I
> tell a Squid: "splice at step1 this.site.net" How that matches can
> fail?

Roughly speaking, the server_name ACL matches at step1 when the real or
fake CONNECT Host information match one of the configured server names.

For example, if you are intercepting or if the real CONNECT request
contains an IP address (rather than a host name), then the server_name
ACL matches if the reverse DNS lookup for that IP address is successful
and matches at least one of the configured server names. In other cases,
the ACL does not match during step1.

The reality is more complex than the above rough summary because domain
name comparison is a complex algorithm. Consult the latest Squid
documentation for details. Also, please do not forget that step2
matching adds checking TLS client SNI name, and step3 matching adds
checking certificate Subject names. It gets really complex...

For example, the Host header of a CONNECT request may not be the same as
the TLS client-supplied SNI name, and/or the server certificate subject
name may. These differences (and other random factors like DNS
inconsistencies) may result in the server_name ACL match result changes
across the steps.

Modern Squids have additional server_name options that control some of
the matching nuances discussed above.


Alex.
Julian Perconti
2018-09-19 22:41:17 UTC
Permalink
I reply to myself due to a bounce and I have to re-enable the membership to list at least 3 times at month.
Maybe a problem with Yahoo.

>>> Alex: After a splice rule is applied, SslBump is over. No more rules are
>>> checked. No more loops are iterated. Squid simply "exits" the SslBump
>>> feature (and becomes a TCP tunnel).

OK, that is what makes me a noise, and therefore I asked about what you said.

>> What about the meaning of the ACL's at step1 when splice?
>
>* If the splice rule ACLs match, the splice rule is applied. In that
>case you can consult my statement above.
>
>* If the splice rule ACLs do not match, then the splice rule is not
>applied. My statement above explicitly does not cover this case -- it
>starts with "after a splice rule is APPLIED".
>
>
>> e.g.:
>> There only these two rules for ssl_bump statements:
>>
>> ssl_bump splice sitesAB
>> ssl_bump splice SitesCD
>
>> I guess that here, Squid has to do 2 loops at outer/main loop to
>> evaluate step1 twice, due to rules differs (sitesAB and sitesCD ACL)
>> and see if both match to splice.

I think that I made a mistake in above sentence.
I have should said "(..) Squid has to do 2 loops at inner while he is at the main loop (at SslBump1)"

>I do not know why you are guessing instead of carefully applying the
>already documented procedure, but you guessed wrong. At any step, the
>first matching rule is applied. For example, if sitesAB matches, then
>Squid splices without checking the second (i.e. SitesCD) rule.

Well, I am guessing because many things are not completely clear to me and/or easy to understand, at all. I am new in TLS filtering.
For example I never would think that in the given example, the second rule (sitesCD) will not never be checked later.
I asked or write that example with the inner loop in mind; I'm sorry.

>> Are You (perhaps) talking about the examples in the thread and not what happens "in general"?
>
>My statements above are general except the "For example..." sentence
>that refers to your specific example.

Its good to know.

>> In which case the "noBumpSites" ACL could have not match? I mean if I
>> tell a Squid: "splice at step1 this.site.net" How that matches can
>> fail?
>
>Roughly speaking, the server_name ACL matches at step1 when the real or
>fake CONNECT Host information match one of the configured server names.
>
>For example, if you are intercepting or if the real CONNECT request
>contains an IP address (rather than a host name), then the server_name
>ACL matches if the reverse DNS lookup for that IP address is successful
>and matches at least one of the configured server names. In other cases,
>the ACL does not match during step1.
>
>The reality is more complex than the above rough summary because domain
>name comparison is a complex algorithm. Consult the latest Squid
>documentation for details. Also, please do not forget that step2
>matching adds checking TLS client SNI name, and step3 matching adds
>checking certificate Subject names. It gets really complex...
>
>For example, the Host header of a CONNECT request may not be the same as
>the TLS client-supplied SNI name, and/or the server certificate subject
>name may. These differences (and other random factors like DNS
>inconsistencies) may result in the server_name ACL match result changes
>across the steps.
>
>Modern Squids have additional server_name options that control some of
>the matching nuances discussed above.

That's what I imagined you meant (and worried too) -without any kind of knowledge-. And now you have just confirmed it.
So things become a little more delicate.
And *now* I understand why you have done so much emphasis saying: "If the rule match..."

>Alex.

Thank You.
Julian Perconti
2018-09-21 15:08:11 UTC
Permalink
Hi all.

I will go (finally) with this sslBump config. Although I still have some doubts...
I think that ItĀ“s time to finish this thread.

# TLS CFG
acl noBumpSites ssl::server_name_regex -i "/etc/squid/url.nobump"

# steps ACL
acl step1 at_step SslBump1
acl step2 at_step SslBump2
acl step3 at_step SslBump3

# SslBump actions
ssl_bump peek step1
ssl_bump splice noBumpSites
ssl_bump stare step2

The TLS config "explained" as well as I can understand:
*Clarification*: maybe I will quote some words out of context; but Alex told me that he almost always speaks "In general terms" about what Squid does.

# First rule:
ssl_bump peek step1 # Step 1 is the only step that is always performed.

If I no peek at step1, and instead directly splice, happens what the wiki warns (this was checked):

" Bump All Sites Except Banks
" Usually does not work for requests that go to non-banks -- they will not be bumped." (Verified)
" Depending on other settings, Squid may terminate connections to banks if Squid cannot validate client SNI (Host header forgery detection) or the server certificate."
The wiki example about this warn the config is:
ssl_bump splice serverIsBank
ssl_bump peek all
ssl_bump bump all

So my conclusion is: "It's "better" (to avoid: ...not work for requests that go to non-banks) to peek step1"

# Second rule:
ssl_bump splice noBumpSites

Here a doubt, I'm sorry.
Based on above words and the squid behaviour I mentioned, I think that this rule should implicity match only at step2.

Alex words:

>"So, "yes", Squid only executes the first rule action _when_ the first
>rule action is applicable and its ACLs match at every step, but, "no",
>Squid does not make a bunch of steps with only the first rule in mind."

With the overall logic in mind, the first impression is that the second rule could match at step1 and at step2 too. Like this rule would the first one (but is the second).
However as I said above if the splice is the first rule instead the peek, the squidĀ“s behaviour changes.

>After a splice rule is applied, SslBump is over. No more rules are
>checked. No more loops are iterated. Squid simply "exits" the SslBump
>feature (and becomes a TCP tunnel).

Here, probably (not sure) Alex rerefered here to "splice all" rule. In that case is clear "splice is a final action" then no more future checks.
"Actions splice, bump, and terminate are final actions: They prevent further processing of the ssl_bump rules."

But in my config next to splice there is an ACL. That is why I asked: "But, doesn't the ACL matters?" in earlier mail.

Therefore, due to above AlexĀ“s statement: Will Squid ignore the last rule?
I checked that the answer is no. If I remove the last rule (stare step2) all the traffic is spliced.
I think that the reason is: (explicit) peek step1 > (implicit) peek step2 > result: default splice all. (peek at step2 precludes future bumping)
Even more, if I remove the last rule, the second rule I think that will be ingnored. In reallity will had not make sense.

# Third/last rule:
ssl_bump stare step2 # stare at step2 so implicit and "secure" default bump action at step3.

Probably I said something (or all) that is WRONG.

Thank You.
Alex Rousskov
2018-09-21 15:13:30 UTC
Permalink
On 09/21/2018 09:08 AM, Julian Perconti wrote:

> I will go (finally) with this sslBump config. Although I still have some doubts...
> I think that ItĀ“s time to finish this thread.

I am confused because "you think it is time to finish this thread" but
you are asking new questions. Please clarify, do you want answers to the
questions in your last email?

Alex.
Julian Perconti
2018-09-21 16:41:25 UTC
Permalink
> > I will go (finally) with this sslBump config. Although I still have some
> doubts...
> > I think that ItĀ“s time to finish this thread.
>
> I am confused because "you think it is time to finish this thread" but you are
> asking new questions. Please clarify, do you want answers to the questions
> in your last email? all right. If you think that at this point it is worth it then do it.

Yes maybe I was contradictory.
All right. If you think that at this point it is worth it then do it.
Since along the thread I draw many wrong conclusions.
It's my fault, not your fault.
Alex Rousskov
2018-09-21 21:19:55 UTC
Permalink
On 09/21/2018 09:08 AM, Julian Perconti wrote:

> ssl_bump peek step1
> ssl_bump splice noBumpSites
> ssl_bump stare step2


> # Second rule:
> ssl_bump splice noBumpSites
>
> I think that this rule should implicity match only at step2.

I do not know what "implicitly match" means here, but yes, the splice
rule may only match at step2 in this configuration:

* It cannot match at step1 because the earlier "peek" rule matches at step1.

* It is always reached during step2 because no rules above it can match
during step2. Whether it matches during step2 depends on whether
noBumpSites matches a particular transaction during step2.

* It cannot match at step3 because for a splice rule to match at step3 a
peek rule has to match at step2, and there is no peek rule that can
match at step2 in your configuration.


> However as I said above if the splice is the first rule instead the
> peek, the squidĀ“s behaviour changes.

Naturally. If you place the splice rule first, it may match during step1
as well. If you do not, it cannot.


>> After a splice rule is applied, SslBump is over. No more rules are
>> checked. No more loops are iterated. Squid simply "exits" the SslBump
>> feature (and becomes a TCP tunnel).

> Here, probably (not sure) Alex rerefered here to "splice all" rule.

I think you are ignoring or misinterpreting the verb "applied". Here,
"applied" means Squid has executed the rule action. Not just considered
the rule containing that action, but actually ran that action. Applying
a rule action implies that the rule ACLs (whatever they were) matched,
of course. A rule action is never applied when the rule ACLs do not match.


> In that case is clear "splice is a final action" then no more future checks.

The notion of a "final" action does not depend on rule ACLs. After Squid
applies the "splice" action (in whatever context, for whatever reason),
SslBump processing for that transaction is over. Same for "bump" and
"terminate" actions.


> But in my config next to splice there is an ACL. That is why I asked: "But, doesn't the ACL matters?" in earlier mail.

ACLs (and other things) determine which rules match. After a rule
matches, then Squid applies its action, and then the notion of a "final
action" starts to matter.


> Will Squid ignore the last rule?

No. The last rule will be applied at step2 whenever noBumpSites
mismatches at step2.


HTH,

Alex.
Julian Perconti
2018-09-22 16:40:33 UTC
Permalink
> > # Second rule:
> > ssl_bump splice noBumpSites
> >
> > I think that this rule should implicity match only at step2.
>
> I do not know what "implicitly match" means here, but yes, the splice rule
> may only match at step2 in this configuration:

When I say "implicit" I want to mean that there is no any step specified in the rule.

> * It cannot match at step1 because the earlier "peek" rule matches at step1.

Yes, rule #1 "matches all" therefore the domains into "noBumpSites" ACL are also peeked. And, that first rule will always match.

> * It is always reached during step2 because no rules above it can match
> during step2.

Yes, first rule has an explicit peek at step1, hence it is impossible any kind of match at step2 before the 2nd rule or in the first rule.

>Whether it matches during step2 depends on whether
> noBumpSites matches a particular transaction during step2.

If I understood You correctly, I think that here you are pointing to an earlier message where You explained some reasons why the "noBumpSites" could not always match.

> * It cannot match at step3 because for a splice rule to match at step3 a peek
> rule has to match at step2, and there is no peek rule that can match at step2
> in your configuration.

Althought there is no any peek rule at step2, in the second rule a final action is applied to noBumpSites (if match)
In fact, in case that (for any reason) the 2nd rule can not match, there is a explicit stare rule at step2.
So, I think that its almost impossible that splice at step3 happens in this configuration for the noBumpSites.
In the worst of the cases, if at rule #2 no match, then noBumpSites will be bumped, due to stare at step2.

Is this reasoning correct?

> > However as I said above if the splice is the first rule instead the
> > peek, the squidĀ“s behaviour changes.
>
> Naturally. If you place the splice rule first, it may match during step1 as well.
> If you do not, it cannot.

That was a comment to confirm that the wiki doc warn and said at 2017's is what is happening now with Squid 4.2 (18/9 source).

> >> After a splice rule is applied, SslBump is over. No more rules are
> >> checked. No more loops are iterated. Squid simply "exits" the
> >> SslBump feature (and becomes a TCP tunnel).
>
> > Here, probably (not sure) Alex rerefered here to "splice all" rule.
>
> I think you are ignoring or misinterpreting the verb "applied". Here, "applied"
> means Squid has executed the rule action. Not just considered the rule
> containing that action, but actually ran that action. Applying a rule action
> implies that the rule ACLs (whatever they were) matched, of course. A rule
> action is never applied when the rule ACLs do not match.

Yes, I misinterpreted You more than one time; I'm sorry. (Because You are speaking in english, and I am reading/speaking in an "almost-english" as well as I can)
So, In the final action the ACL is important. This is what I tried to mean.
I insist, because when You said that, I thought (without understanding the logic): "OK, therefore if I splice at step2 some.site.net, the following lines are over; no more processing no matter whatever any ACL the rule has"

> > In that case is clear "splice is a final action" then no more future checks.
>
> The notion of a "final" action does not depend on rule ACLs.

Here is where I your explanation breaks my head. Here is the most important confusion of all of my own other confusions/misunderstanding.

In the config I posted, there is a splice action in the middle, and only the "noBumpSites" are spliced (at least checked with logs).
And even with the splice action as second rule, the 3rd rule is processed (Squid is still processing rules after splice noBumpSites ACL).
It is checked because if I remove the last rule all the traffic is spliced (due to peek at step1 and splice at step2) and future defaults actions.
I think that this happens because, if there is no 3rd line stare'ing at step2, so:

ssl_bump splice noBumpSites = ssl_bump splice noBumpSites all. (not sure, I will do a test with only one rule, to see what Squid does: ssl_bump peek step1)

If this were the last rule, but in this configuration there is a 3rd rule which is stare'ing at step2)

> After Squid applies the "splice" action (in whatever context, for whatever reason),
> SslBump processing for that transaction is over. Same for "bump" and
> "terminate" actions.

What do You exactly mean with "for that transaction"? Maybe that rule?

> > But in my config next to splice there is an ACL. That is why I asked: "But,
> doesn't the ACL matters?" in earlier mail.
>
> ACLs (and other things) determine which rules match. After a rule matches,
> then Squid applies its action, and then the notion of a "final action" starts to
> matter.

Thats statement clarify the thing a bit more.

> > Will Squid ignore the last rule?
>
> No. The last rule will be applied at step2 whenever noBumpSites mismatches
> at step2.

Yes, I said and verified that, the last rule is not ignored by Squid, even with the splice rule at previuos rule.

> HTH,
>
> Alex.

Thank You very much.
Alex Rousskov
2018-09-25 21:40:31 UTC
Permalink
On 09/22/2018 10:40 AM, Julian Perconti wrote:
>>> # Second rule:
>>> ssl_bump splice noBumpSites
>>>
>>> I think that this rule should implicity match only at step2.
>>
>> I do not know what "implicitly match" means here, but yes, the splice rule
>> may only match at step2 in this configuration:

> When I say "implicit" I want to mean that there is no any step specified in the rule.

Understood. Please avoid that word usage. In this context, implicit
means "without being configured" or "by default". One could say that
"default rules implicitly match", or that "a rule without any ACLs
matches implicitly", but one cannot say that "rule X containing ACL Y
implicitly matched".


>> * It cannot match at step3 because for a splice rule to match at step3 a peek
>> rule has to match at step2, and there is no peek rule that can match at step2
>> in your configuration.

> Althought there is no any peek rule at step2, in the second rule a
> final action is applied to noBumpSites (if match)

Final actions at step2 do not matter when we are talking about what
happens at step3. If a final action is applied at step2, there is no
step3 as far as an ssl_bump configuration is concerned.


> In fact, in case that (for any reason) the 2nd rule can not match,
> there is a explicit stare rule at step2.

Yes, and it will be applied, and it is not a peek rule, so this applied
staring action will prevent splicing at step3.


> So, I think that its almost impossible that splice at step3 happens
> in this configuration for the noBumpSites.

It is impossible for any transaction to be spliced at step3 with this
configuration. Whether the transaction matches or does not match
noBumpSites at any given step is irrelevant for this statement.


> In the worst of the cases, if at rule #2 no match, then noBumpSites
> will be bumped, due to stare at step2.

Correct. There is nothing "worse" about this case though.


>>> In that case is clear "splice is a final action" then no more future checks.

>> The notion of a "final" action does not depend on rule ACLs.

> Here is where I your explanation breaks my head. Here is the most
> important confusion of all of my own other
> confusions/misunderstanding.

Final actions are "bump", "terminate", and "splice". As you can easily
see, this statement does not depend on ACLs.

An action is either final or not, by that action nature/definition. ACLs
are one of the precondition for applying an action, but ACLs do not
affect action "finality".


> In the config I posted, there is a splice action in the middle, and
> only the "noBumpSites" are spliced

Yes.


> And even with the splice action as second rule, the 3rd rule is
> processed (Squid is still processing rules after splice noBumpSites
> ACL).

An action presence in the rules does not, on its own, stop Squid from
processing lower rules. *Applying* a final action does.


> It is checked

Yes, it is checked at stepN when the previous rules do not match at (or
are not applicable to) that step.


> ssl_bump splice noBumpSites = ssl_bump splice noBumpSites all.

Yes. Adding "and true" to any logical condition does not change that
condition. However, I fear that the above correct equivalence does not
mean what you think it means. It means there is no point in adding
"all". It does not mean that adding "all" changes the meaning of that
ssl_bump rule or of what you are saying.


>> After Squid applies the "splice" action (in whatever context, for whatever reason),
>> SslBump processing for that transaction is over. Same for "bump" and
>> "terminate" actions.

> What do You exactly mean with "for that transaction"? Maybe that rule?

No, I do not mean "that rule". In this context, "transaction" is,
roughly speaking, an "HTTP CONNECT request" or "TLS connection". An
applied final action stops all ssl_bump processing for the corresponding
transaction/request/connection, and not just one ssl_bump rule
processing. That difference is why those actions are called "final".

Alex.
Julian Perconti
2018-09-26 17:40:33 UTC
Permalink
> > When I say "implicit" I want to mean that there is no any step specified in
> the rule.
>
> Understood. Please avoid that word usage. In this context, implicit means
> "without being configured" or "by default". One could say that "default rules
> implicitly match", or that "a rule without any ACLs matches implicitly", but
> one cannot say that "rule X containing ACL Y implicitly matched".

OK and sorry for that.

> > Althought there is no any peek rule at step2, in the second rule a
> > final action is applied to noBumpSites (if match)
>
> Final actions at step2 do not matter when we are talking about what happens
> at step3. If a final action is applied at step2, there is no
> step3 as far as an ssl_bump configuration is concerned.

Yes, when a final action is applied at step2, ssl_bump rules are over when the previous step (if it's a final action) has matched.

> It is impossible for any transaction to be spliced at step3 with this
> configuration. Whether the transaction matches or does not match
> noBumpSites at any given step is irrelevant for this statement.

OK: In this configuration it is impossible any kind of splice at step3; but not for step2.
In fact, noBumpSites are being spliced (at least I can see the TCP_TUNNEL in logs).

> Correct. There is nothing "worse" about this case though.

With the term "worst" I wanted to mean that my intention is splice sites into the ACL (noBumpSites) , not bump.

> > Here is where I your explanation breaks my head. Here is the most
> > important confusion of all of my own other
> > confusions/misunderstanding.
>
> Final actions are "bump", "terminate", and "splice". As you can easily see, this
> statement does not depend on ACLs.
>
> An action is either final or not, by that action nature/definition. ACLs are one
> of the precondition for applying an action, but ACLs do not affect action
> "finality".

Well, Yes.
Strictly speaking final actions (and maybe any action) do not depend on the acl, let's say it is a natural function/behavior of Squid beyond any acl.
However, when a final action is present in a rule and that rule contains an ACL, the final action will apply to that ACL. At least that is the behaviour I see.
If not, Squid would not being splice'ing "noBumpSites" which is an ACL; as he is doing right now.
I say good?

> > And even with the splice action as second rule, the 3rd rule is
> > processed (Squid is still processing rules after splice noBumpSites
> > ACL).
>
> An action presence in the rules does not, on its own, stop Squid from
> processing lower rules. *Applying* a final action does.

So, why squid process the last rule which stare at step 2? He already applied the splice to the ACL sites.

> >> After Squid applies the "splice" action (in whatever context, for
> >> whatever reason), SslBump processing for that transaction is over.
> >> Same for "bump" and "terminate" actions.
>
> > What do You exactly mean with "for that transaction"? Maybe that rule?
>
> No, I do not mean "that rule". In this context, "transaction" is, roughly
> speaking, an "HTTP CONNECT request" or "TLS connection". An applied final
> action stops all ssl_bump processing for the corresponding
> transaction/request/connection, and not just one ssl_bump rule processing.
> That difference is why those actions are called "final".

OK, thank You for that clarification of misinterpreted terms.

So going back to current config:

ssl_bump peek step1
ssl_bump splice noBumpSites # I think that here the splice action is applied at step2. Even if there is no step specified. And due to previous rule.
ssl_bump stare step2

Due to I think that: the splice action happens at step2 (more checks?), and not at step 1 (less checks); This is the config the one of best fit to my necessities.

Quick reminder of the idea/need:
In the most possible "secure" way: bump to all except banks and other sensitive sites; and less possible interference to that sensitive sites.

Just a comment: Squid is working fine,but still the cache.log shows these kind or errors (quite annoying):

kid1| Error negotiating SSL connection on FD 26: error:00000001:lib(0):func(0):reason(1) (1/-1)
kid1| ERROR: negotiating TLS on FD 31: error:00000000:lib(0):func(0):reason(0) (5/-1/104)

Always or almost always are only those two types of error [reason(1) (1/-1) - (0) (5/-1/104)]

But that is another story. Apart nobody reports problems about the browsing.

> Alex.

Thank You, again.
Alex Rousskov
2018-09-26 19:41:58 UTC
Permalink
On 09/26/2018 11:40 AM, Julian Perconti wrote:

>> It is impossible for any transaction to be spliced at step3 with this
>> configuration. Whether the transaction matches or does not match
>> noBumpSites at any given step is irrelevant for this statement.
>
> OK: In this configuration it is impossible any kind of splice at step3; but not for step2.

Yes, your configuration makes splicing possible at step2 (and only at
step2).




> Strictly speaking final actions (and maybe any action) do not depend
> on the acl, let's say it is a natural function/behavior of Squid
> beyond any acl.


Correct.


> However, when a final action is present in a rule and that rule
> contains an ACL, the final action will apply to that ACL.

"apply to ACL" does not make sense.

ACLs of a [final] action rule affect when the final action is applied.
They are a necessary (but not sufficient) preconditions for applying the
action.



>> An action presence in the rules does not, on its own, stop Squid from
>> processing lower rules. *Applying* a final action does.

> So, why squid process the last rule which stare at step 2? He already
> applied the splice to the ACL sites.

For your configuration:

* If Squid applied the splice rule, then it will ignore the stare rule.

* If Squid reached but did _not_ apply the splice rule, then it will
apply the stare rule instead.

FWIW, I do not understand why you do not seem to understand this fairly
straightforward algorithm so I cannot explain it better. I can correct
your statements, but I do not know _why_ you keep making statements that
need correction. We are running in circles. It could be just a language
barrier.


> So going back to current config:
>
> ssl_bump peek step1
> ssl_bump splice noBumpSites
> ssl_bump stare step2

> Due to I think that: the splice action happens at step2 (more
> checks?), and not at step 1 (less checks);

Correct.


> This is the config the one of best fit to my necessities.

Glad you found what you were looking for.

This is minor, but replacing "step2" in the last/stare rule with "all"
would be slightly better because "all" is simpler and should be faster
to compute than "step2". This minor simplification/optimization will not
change the overall meaning of the configuration.

I added a similar configuration example to Squid wiki at
https://wiki.squid-cache.org/Features/SslPeekAndSplice


HTH,

Alex.
Alex Rousskov
2018-09-07 04:20:21 UTC
Permalink
On 09/06/2018 07:48 PM, Julian Perconti wrote:

> 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):

> (104) Connection reset by peer (TLS code: SQUID_ERR_SSL_HANDSHAKE)
> Handshake with SSL server failed: [No Error]

> 2018/09/06 22:40:36 kid1| ERROR: negotiating TLS on FD 44: error:00000000:lib(0):func(0):reason(0) (5/-1/104)

OK, so the origin server is resetting a connection when Squid talk to
it. Does that happen during the peek (step2), splice (step3), or bump
(step3) rule?

One way to answer that question is to post an ALL,9 log of the isolated
failing transaction for a developer to tell you what is going on.

Another way is to replace a suspected rule with, say, an "ssl_bump
terminate all" rule and see if anything changes (going from the last
suspected rule up towards the first one until something does change).

There are other ways as well, of course.


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

My working theory is that your noBumpSites (i.e. ssl::server_name_regex)
ACL matches at step2 but does not match at step3. That is just a guess,
and, even if it is correct, it does not fully explain what Squid does in
that case and why the peer resets the connection.


HTH,

Alex.
Loading...