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

Amos Jeffries squid3 at treenet.co.nz
Wed Dec 31 01:19:43 UTC 2014


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31/12/2014 7:30 a.m., Alex Rousskov wrote:
> 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.

nasty - horrible, mean (but not cruel), very annoying.

Henrik and I had a discussion about directive naming years back and
decided that long and "nasty" names like this should be reserved for
directives that we really, really did not want people using but there
was actually a rare use case for. Emphasis being on rare and not
using. The length and horribleness of the name helping to discourage
use, not documenting being another.

IMO this directive needs to be friendly and clear as its going to be
somewhat popular.

> 
> BTW, on_first_request_error does not name an access list.
> 

By access list I mean a multi-line directive, whose line ordering is
meaningful, using the syntax:

  directive_name action acl [acl ...]

Christos configuration sketch:
"
   # tunnel if we think the client waits for the server to talk first:
   on_first_request_error tunnel serverTalksFirstProtocol

   # in all other error cases, just send an HTTP "error page" response:
   on_first_request_error respond all
"

The name reads like the value is a one-liner / event handler. i.e. an
action without ACL list. Like we have one-liner directives
"error_directory /foo/", "enable_icmp on/off", etc.

The "on_error" as you say is already fairly well known. In particular
its known as an event handler hook in JavaScript and other languages.
Like I said above squid.conf is more a declarative language than those.

So in detail:

1) "on_" - all directives in Squid.conf are essentially declarative
and access control could almost all be prefixed with "on_". This adds
no value but makes the directive longer and harder to write.

2) "first_request_error" as a declarative statement - implies the
value *is* the error to be supplied on first request. It is actually
declaring an action to perform *instead* of producing errors ... and
the ACL tests to determine that action.

3) due to legacy Squid being HTTP-oriented the directives we have
without explicit component names (http_, ftp_, dns_, ssl_, icp_htcp_,
wccp_ etc) are implying http_ relevance.
 This directive is not relevant to HTTP, but to SSL/TLS. So something
like ssl_ or tls_ or tcp_ is more appropriate.

4) is that "error on first request", or "first request with errors"?
the name is not clear.

Coming back to this now (and accepting your scope narrowing from tcp_
to ssl_) we should probably call this ssl_unknown_protocol. Since
anything on port 443 which is syntactically HTTP but has some
invalidity is rightfully responded with an error, no need to ask the
admin at that point.


PS. can we please agree to start using tls_ instead of ssl_? even
SSLv3 is a dead duck now and everybody knows it. At least on new
directives.

> 
>>> 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.
> 

It also depends on where the decision is taking place. And needs to be
agnostic of TLS.

If the decision is to allow/deny TCP tunneling it's rightfully called
"tcp_tunnel allow/deny" regardless of how many pathways lead to that
decision point. i.e. we do not have 9 different protocol-specific
ways/names to define cache_peer_access just because 9 protocols (HTTP,
HTTPS, FTP, Gopher, Wais, tunnel, ICP, HTCP and ICMP) can all use
peers - we have one and its tested by each component as and when
necessary.


> 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.
> 

Okay. Then with the narrow scope ssl_unknown_protocol is better
naming. Or can you think of a better word than "protocol" for that noun ?

[accepting the narrowing of scope, shelving the discussion about
tcp_tunnel]

> 
>> 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?

Mosly I am waiting to see an updated patch. The blocker was on waiting
for Parser-NG request handling re-write which is now in.

PS. Since this involves UI alteration it is a 3.6 feature and we can
rename/alias the directive if we find a better name for it.

Amos

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (MingW32)

iQEcBAEBAgAGBQJUo08uAAoJELJo5wb/XPRjmdAH/0ikflRxKevEPOYQ8i+IEYhS
9t5l4Uedx9rjCMNNsgMvJGLYvOtgAvKRZhd3qfYI1BE6xVbON30WMvIgp0JbU5ZY
NdZfpKT38oBBKnqDb5rOokO9zUSQzrdVhKayNMO1le4DAJDdhkl2TeZWyQIDe4tl
jw8sTojlsqHKQWNXYGgBn6IpxXPLBS8iUP1qWOv4bt4TE7wmtzVzp7QY8yhhqjqO
dTvQEWJi8kET7KC6EFYM9ipyF3k6GOS0Rcp6ry/yA9GE9Rab2QBcdUcQG3g8As2z
J4aQrSKdmRSZKjSDGfPtyFQxmRowPOdTMzPAIpBUmWtKlVA3/GygNK5gqELv0do=
=FpvI
-----END PGP SIGNATURE-----


More information about the squid-dev mailing list