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

Alex Rousskov rousskov at measurement-factory.com
Fri May 20 15:15:30 UTC 2016

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


  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

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,


More information about the squid-dev mailing list