Re: [RFC] Peek and Splice

I have been just researching these situations and issues for the last
couple months as a hobby.
We can divide and conquered this issue.

A small summary from what I know about squid:

- Until some time long ago squid was a forward proxy only.
client request always first.
in a case of timeout close the connection.

- squid was upgraded to support interception(variant levels).
Apps use the intercepted port for server-first protocols.
in a case of timeout for client request still close the connection.

- later on squid intercepts ssl connections.
More apps use intercepted port for server-first protocols on port 443
This forces squid to allow the admin decide if he wants to allow other
protocols on port 443.
The above reflects on the current situation.

- squid intercepts ssl connections using ssl-server-first.
The logic of server-first is a very strict one.
This allows squid to recognize non-ssl protocols runing on the wire.
This is by a general rule per acls and Most admins will do that with a
ALL acl.

So now what squid does?
instead of bumping the client first for information on ssl like SNI etc
it bumps the server first for a SSL connection? or it just bumps for
anything using a raw TCP socket?

I think the ssl-server-first should be used in any case from the proxy
point of view to understand the connection (in specific src ports?).

There are so many Applications out there which opens 5-10 connections to
the same port and app in secs so limiting the ssl-server-first to one
connection per ttl to understand the server and decide if it's ssl or
another protocol maybe?
I know of edge cases that servers identify ssl vs not ssl request by
peeking and sending a redirection page\response in a case of
HTTP\non-ssl incoming connection.

The above ttl is might be good to prevent DDOS like tagging on the proxy
address in intercept(nat) mode.
But in tproxy mode who cares about two tcp connections one after the
other from the same client? and if so a small ACL can slow that.

I wasn't inside the ssl-server-first development so I dont know a thing
about it from squid point of view.

Maybe we can even send the ssl-server-first raw tcp socket data to a
helper(ICAP->REQMOD icap://host/reqmod?splice) that will decide the fate
of ip+port?(I know it can be a pretty bad idea in a sense of latency
sometimes).
Maybe even to do something in squid for that?
The helper can decide on a allow_for_now_raw_socket or
allow_raw_socket_for_ttl.

On 2/1/2013 6:51 PM, Alex Rousskov wrote:
> On 01/31/2013 11:24 PM, Amos Jeffries wrote:
>> On 1/02/2013 5:17 p.m., Alex Rousskov wrote:
>>> 2. How to configure two ssl_bump decisions per transaction?
>>>
>>> When Peek and Splice is known to cause problems,
>
>> What problems and how would this be known?
>
> I will answer the second part first: Problems will be detected because
> Squid will respond with error messages and/or users will complain that
> "something does not work". No new magic here. This is how current
> SslBump (and pretty much any other Squid feature) problems are detected.
>
>
> One example of a problem that will probably happen sooner or later is
> SSL cypher incompatibility: client supports cyphers A and B, Squid
> supports cyphers B and C, server supports cyphers C and D. Regular
> SslBump is possible, but Peek and Splice will fail (if Squid mimics
> client Hello when talking to the server) because client and server have
> no common cyphers. In this particular example, the non-proxied
> connection would probably have failed as well, so it is not a big deal,
> but one can imagine an SSL server that responds differently to different
> clients, making Squid look bad.
>
> Another example is non-SSL traffic that does not start with some kind of
> Hello message from the client. In this case, Squid will wait for SSL
> Hello but nothing will come. Squid will timeout. Initial Peek and Splice
> implementation will probably handle that as a regular error. Eventually,
> we will probably have to make behavior on timeouts and other soft errors
> configurable (e.g., on_peek_timeout=tunnel).
Why don't we just peek??

>
>>> ssl_bump peek safeToPeek
>>> ssl_bump none all
>>>
>>> ssl_bump_peeked server-first safeToBump
>>> ssl_bump_peeked splice all
>>>
>>> Is that the best configuration approach, or am I missing a more elegant
>>> solution?
>
>
>> What about making "peek" a flag that can optionally prefix any of the
>> ssl_bump ACL actions...
>>
>> ssl_bump client-first foo !safeToPeek
>> ssl_bump peek client-first foo
>> ssl_bump server-first !safeToPeek
>> ssl_bump peek server-first safeToBump
>> ssl_bump none all
>
> I like that, but I do not think it will work because the ACLs you want
> to use for the "to peek or not to peek?" decision are going to be
> different from the ACLs you want to use for "to bump or not to bump
> _after_ we peeked" decision. The former ACLs would use CONNECT/TCP-level
> information. The latter ACLs would use SSL certificate information.
> Thus, you do not want to use the same set of ACLs for one ssl_bump rule.
>
> In other words, the decision what to do after we peek cannot be done
> before we peek. That is why we want to peek in the first place...
>
> In your specific example, the "safeToBump" ACL cannot be evaluated until
> we peek.
Why don't we peek and start another connection if needed?

>
>> Overall the whole thing is getting complex and risks making a huge mess.
>
> I agree that this will increase code complexity. I am afraid this is a
> necessary price to pay for safer, more precise SslBump. As for the mess,
> I am not sure what you mean exactly, but I do not think Peek and Splice
> should be allowed to stay in Squid unless it works well in some
> environments and can be disabled in others.
Since squid will become a more general purpose proxy rather then HTTP
cache proxy.
Do we want that?

>
>
>> Time to reduce the options.
>
> I do not think it is realistic to expect us to be able to reduce the
> number of configuration options when adding a new optional feature. I
> would very much prefer to keep the number of options the same, but we
> need to find a way to do that. Currently, I cannot offer anything better
> than adding ssl_bump_peeked or similar, but I hope others can think of
> something.
+1

>
>
>
>> This *is* a quazi-legal feature after all.
>
> I do not like using scary but undefined terms like that. Virtually any
> feature is going to be illegal somewhere and useful elsewhere. After
> all, there are situations where unfiltered internet access is illegal
> and situations where unfiltered internet access is legal but lethal.
>
> I think that we should continue to allow features that significant
> portions of the community find useful, especially when those features do
> not violate internet protocols. Let our users decide what is legal
> and/or moral in their environment.

++1
>
>
> Thank you,
>
> Alex.
>

-- 
Eliezer Croitoru
http://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il