[squid-dev] [PATCH] Non-HTTP bypass

[Alex Rousskov]

On 10/21/2014 11:29 AM, Tsantilas Christos wrote:
>>>    - Adds "on_first_request_error", a new ACL-driven squid.conf
>>> directive
>>> that can be used to establish a blind TCP tunnel which relays all bytes
>>> from/to the intercepted connection to/from the intended destination
>>> address. See the sketch above.
>>> The on_first_request_error directive supports fast ACLs only.

>> What a nasty name for an access list.

Please try to be more specific, especially when you are being negative
about others work. "Nasty" can mean many things to many people. In this
particular case, your comment carries no [positive] value at all. It is
difficult for the code author to make something "less nasty" because
they do not know what "nasty" means to you in this context.

BTW, on_first_request_error does not name an access list.


>> I believe tcp_tunnel or tunnel_transparent would be more descriptive of
>> the test is *checking* for.

* If we want to tell Squid when to tunnel, then tcp_tunnel is a good
solution (but this is not what this proposal tries to do).

* If we want to tell Squid what to do with connections it does not
recognize, then tcp_tunnel is the worst alternative of the three I can
think of (see below for details).


The "tcp_tunnel" idea currently lacks context: Is it applied when we
accept a connection, when we authenticate the user, when we parse 10th
request, etc.? There are many very different cases where we may want to
start tunneling, for many different reasons. This lack of specifics
makes the idea look simple and, hence, appealing, but the devil is
usually revealed in the details.

The implemented "on_first_request_error" feature is much smaller and has
relatively narrow context: When Squid realizes that it does not
recognize the connection, it consults the proposed directive for
instructions. The "on_error" concept is not new in IT and should be
familiar to many admins.


The suggested feature can be converted into a tcp_tunnel feature if:

* we add a hard-coded first_request_error ACL

* agree that tcp_tunnel rules are evaluated when Squid realizes that it
does not recognize the first request on a connection (at least).

Then, instead of writing:

  on_first_request_error tunnel some
  on_first_request_error respond other
  on_first_request_error future_action yet_another

folks will write:

  tcp_tunnel on_first_request_error some
  respond_with_error on_first_request_error other
  future_action on_first_request_error yet_another

which is clearly (I hope!) worse from configuration clarity and
convenience point of view. However, folks would also be able to write:

  tcp_tunnel some_other_error some
  respond_with_error some_other_place other
  future_action some_other_category yet_another

which is an improvement over the more rigid on_first_request_error
scheme that restricts application to only certain kinds of errors in
certain places.


The design space can be summarized like this:

  # extreme left: general-purpose on-error handling:
  on_error <action> error_kind_acl acl ...

  # proposed feature: unrecognized connection handling;
  # the error_kind_acl is implicit in this design:
  on_first_request_error <action> acl ...

  # suggested extreme right: general-purpose actions:
  tcp_tunnel error_detection_acl acl ...
  ssl_tunnel error_detection_acl acl ...
  respond_with_error error_detection_acl acl ...
  terminate error_detection_acl acl ...


Since many Squid actions are likely to be appropriate under the same
conditions (tunnel, respond with an error, terminate, ssl-tunnel, etc.)
I do not think the suggested extreme is the best design. We should
either move left to the general on_error configuration or stay with the
proposal currently under review.


>> The "only checked on first request failure" detail can be left in the
>> directive documentation.

It would be wrong to provide a general-looking "tcp_tunnel" option that
can only be applied in one specific case. The initial implementation may
be restricted to one case, of course, but a general feature needs enough
knobs to be usable in many contexts. In this case, this means a group of
hard-coded ACL guards that only match in some specific supported
contexts (see above for examples). At the end of your email, you have
already identified an error-unrelated case where the tcp_tunnel
directive would be required...


>> I also suspect that is a false statement since
>> anything we do with a CONNECT body that fails will need a matching check
>> applied.

Not sure what you mean here, but please note that the first request
inside a bumped CONNECT tunnel is still the first request as far as the
proposed feature is concerned.

To avoid misunderstanding, I am not saying that on_first_request_error
name or its description is perfect. Better alternatives are more than
welcome (and similar names/descriptions would be needed even if we move
towards a more general on_error design)!


>> ssl-bump calls its version of tunnelling "ssl_bump splice". So if we are
>> continuing with the splice vs tunnel terminology the syntax would look
>> something like this:
>>
>>   tcp_tunnel deny localhost
>>   tcp_tunnel splice all


This does not work because "deny" does not tell the admin what is going
to happen and if you replace "deny" with more specific "respond" or
"serve_error", then the tcp_tunnel name becomes inappropriate (those
actions are not about tunneling at all!). To make this work, you have to
add more actions (see above for more examples):

    respond_with_error localhost
    tcp_tunnel !localhost

which is an inferior (IMO) alternative as detailed above.


>> After this change goes in there will undoubtedly be requests to extend
>> it so that we do not waste time waiting for a parse error and just allow
>> a transparent port to tunnel selected connections right from accept().
>> So lets be prepared for that with the right naming and scope from the
>> start.

I agree that the proposed feature does not address all expected needs,
but I do not think tcp_tunnel (or any single directive!) can address all
those needs. Error handling should be separated from primary actions.
Whether we add more primary actions or not, is a separate issue.


> The tcp_tunnel is not a bad name.
> Lets see if Alex has a different opinion on see...

tcp_tunnel is a good name, but not for the problem we are trying to
solve. I suspect we will eventually add a "tunnel tcp" or "tcp_tunnel"
directive, which will be applied at certain processing points. However,
we would still benefit from an on_error directive, before and after
tcp_tunnel is added.


Amos, if on_first_request_error is converted into on_error with a
first_request (or similar) ACL, would you continue to block this
frequently-requested bypass feature?


Thank you,

Alex.