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.
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
