Re: [RFC] Peek and Splice

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

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

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

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

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

Thank you,

Alex.
Received on Fri Feb 01 2013 - 16:51:17 MST