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