[squid-dev] Bumping after peek and Splicing after stare

[Amos Jeffries]

On 21/05/2016 3:15 a.m., Alex Rousskov wrote:
> On 05/20/2016 05:12 AM, Christos Tsantilas wrote:
>> On 05/20/2016 12:26 PM, Amos Jeffries wrote:
>>> I would really like to see in the long
>>> term is peeking always at clientHello.
> 
>> This is what fast-sni does! For the step1-to-step2 does not involved any
>> openSSL code.
> 
> What Amos means is doing step1 unconditionally/always, eliminating the
> need to mention it in squid.conf.
> 
> 
>> But I am not sure that we can completely remove the step1. Splice on
>> step1 required for non SSL related protocols.
> 
> Yes, non-SSL protocols and SSL traffic incompatible with our SSL parser
> are the reasons why we need this "Should Squid do SslBump step #1?"
> checkpoint. In other words, today step1 is needed _not_ because we want
> to do step1, but because we want to be able to _avoid_ doing step1 (and
> the following steps).
> 
> With more work, this checkpoint can and should be replaced with the
> equivalent on_unsupported_protocol-driven functionality. So, long-term,
> I agree with Amos that step1 should be done automatically with
> on_unsupported_protocol allowing the admin to control Squid actions when
> step1 parsing fails.
> 
> Just like catching exceptions is the best way to handle most parsing
> errors in C++ code, using special/dedicated configuration options is the
> best way to configure Squid behavior in exceptional situations. Our
> on_unsupported_protocol is such a configuration option.
> 
> 
>>> the action would not lead to the above problem.
> 
> The problem Christos discusses is different and will exist regardless of
> whether we always do step1 or not. adjustSSL() hack allows
> 
>   ssl_bump peek step2
>   ssl_bump bump all
> 
> and
> 
>   ssl_bump stare step2
>   ssl_bump splice all
> 
> combinations to work in _some_ cases. In other cases, it either breaks
> SSL negotiation or crashes Squid. The number of non-working cases and
> their unpredictability has increased so much that we are proposing to
> remove this hack even though there are probably some admins in
> old/controlled deployment environment that benefit from it (possibly
> unknowingly).
> 
> For example, today, Squid trunk may not be able to stare during step2
> when built with the latest OpenSSL v1.0 releases because adjustSsl()
> screws up OpenSSL state. We do not know the exact mechanism, but suspect
> that the internal OpenSSL buffer layout has changed. Going forward,
> OpenSSL v1.1 releases contain lots of drastic changes in that area.
> 
> 
> Hope this clarifies,
> 

Yes.

IMO, if its a hack and causing trouble we should remove it. But as you
are the one who will probably be the one fixing it if it stays, thats
your call Chhristos.

If you want to experiment, you could "#if 0" it for next weeks release
and see what feedback we get.

Amos