[squid-dev] [RFC] simplifying ssl_bump complexity

[Alex Rousskov]

On 11/19/2016 03:07 AM, Amos Jeffries wrote:

> I propose going back to the older config style where each step has its
> own directive name which self-documents what it does.

IIRC, SslBump has never used step-specific directives: First
implementations applied all ssl_bump actions during step1 and the
current implementation applies various ssl_bump actions at various
steps, but no Squid version had steps with dedicated directive names
AFAICT: http://www.squid-cache.org/Doc/config/ssl_bump/


> That will reduce
> the confusion about what is going on at each 'step', and allow us a
> chance to have clearly documented default actions for each step.

Why do you think that moving the step name into the directive name,
i.e., essentially replacing

  ssl_bump action stepN ...

with

  ssl_bump_stepN action ...

will "reduce the confusion about what is going on at each step, and
allow us a chance to have clearly documented default actions for each
step"? I see no correlation between the proposed change and the expected
result.


There have been cases were being explicit about steps resulted in worse
or broken configurations. There have been cases were being explicit
about steps resulted in better configurations. The exact outcome usually
depends on the level of admin's understanding and specific use cases.
Steps are helpful in some cases and harmful in others. If the consensus
is that explicit steps are usually helpful, we can encourage their use
[without forcing them on all the admins, in all cases].

IMO, the steps are not the core problem; their set will change
long-term; and they should not be the focus of the configuration. The
core problems lie elsewhere:

* The available information varies widely and may (or may not!) change
with each step. Even today, the information available at step1 varies
depending on the bumping environment. It is difficult to deal with
changing information using traditional "fixed" ACLs. We need to arm the
admin with server_name and similar "dynamic" ACLs. A related
"information" problem is server certificate validation: The admins are
surprised to learn that Squid validates the server certificate, and it
is often not clear when Squid does that and how to control whether Squid
should validate.

* The "price" (or side effects) of obtaining more information grows with
each step. For example, one can learn the origin server CN, but only at
the cost of establishing a TCP connection with the origin server and
precluding future splicing (or bumping). There is currently no good way
to tell Squid how much the admin is willing to "pay" for more
information [in the context of the current transaction state].

* Exception handling: When things go wrong, the admins are surprised to
learn that Squid bumps the client (to send an error message). There are
different kinds of errors and Squid reaction to each kind is controlled
by a different configuration directive. It is often not clear what Squid
will do in a particular situation, even when the current step is known.

These problems are fundamental SslBump properties that will not change
regardless of the configuration approach. The best configuration
approach should focus on these fundamental properties rather than on the
[still evolving] "steps" mechanics. The current configuration abilities
have many weak spots, but the proposed changes seem like a step in the
wrong direction to me because they focus on the mechanics rather than on
these fundamentals. They force the admins to detail what should not be
important.



> For example:
>  tls_new_connection
>   - default: peek all
>   - or run ssl_bump check if that directive exists
> 
>  tls_client_hello
>   - default: splice all
>   - or run ssl_bump check if that directive exists
> 
>  tls_server_hello
>   - default: terminate all
>   - or run ssl_bump check if that directive exists


To illustrate why your proposal will be better than the existing
approach, please compare an old configuration with a new configuration
for a few common use cases. Please do your best to be unbiased in your
comparison -- do not just pick the cases that benefit your proposal.


Also, I suggest to separate naming from the functionality changes. If we
agree to change the functionality, we can then discuss how to name the
new configuration knobs. For now, I am not going to discuss the problems
with the proposed naming scheme.



> The main consideration here is that the default behaviour/actions are
> both a) that legal in almost all jurisdictions users will be working in,

Please do not bring legality and jurisdictions into this. If there is
quorum, then we are unlikely to reach consensus if we start discussing
what is "legal" and where one "jurisdiction" ends and another begins.
Said that, the existing default behavior is probably already legal in
all jurisdictions so there seems to be no difference here anyway.


> and b) let client connections work if the admin does not configure
> anything different (ie peek + splice).

How is that different from today? Client connections already work if the
admin configures nothing: Splicing is the default when nothing is
configured. If it is not the default, it should be (and we can certainly
fix that bug if it exists).


Thank you,

Alex.
P.S.
> Since ssl_bump directive went in my original opinion of it as being too
> complicated and confusing has pretty much been demonstrated as correct
> by the vast amount of misconfigurations and failed attempts [to use it].

I envy your confidence but do not know why you started your RFC with
this flawed attempt to prove some vaguely defined opinion to be correct.
I tried to avoid this distraction and focus on the RFC parts that deal
with reducing ssl_bump configuration complexity instead. If you meant to
discuss why we happen to be where we are today, and who has predicted
what, please start a dedicated email thread.