[squid-dev] TLS proxy-server connection optimization

[Alex Rousskov]

On 08/03/2018 06:15 PM, Vishali Somaskanthan wrote:

> [Alex] Why does Squid close the (not pinned) Squid-to-server connection
> in this case? What code/condition triggers that closure in your tests?
> 
> When the SSL-bump steps are
> 1. *peek-splice and peek-peek-splice*, 

Ah, I see. This is a tunneled connection. It is equivalent to pinning
for most purposes, but the pinning methods are not used because
tunnel.cc code operates on both connections at once. Pinning methods are
mostly needed to associate the to-server connection with the future
from-client request, but tunnel.cc does not have future requests. It
only shovels bytes.

> we observe the behavior that squid does tunneling and presume that SSL
> proxying is not happening in this case. 
> Hence, after the series of writes, /keepGoingAfterRead()/ is called
> where the following snippet triggers the closure from squid to server.
> 
> //* Only close the remote end if we've finished queueing data to it *//
> /        if (from.len == 0 && Comm::IsConnOpen(to.conn) ) {/
> /            to.conn->close();/
> 
> Here, we would to like to do the optimization where instead of closing
> them, we want to Push the connection to Pconn pool which can be used
> later for a second request.

Let's assume you did that. How would Squid know which clients can reuse
that old to-server connection? Would any client requesting a tunnel to
the same server name be eligible? Any client requesting a tunnel to the
same server IP? A client with some specific TLS Hello properties? A
client from the same IP address as the disconnected client? A client
that is authorized by some new directive? Etc.

Would the to-server connection be reusable only when the client
connection was closed with a zero-length read? Or in some other cases?

Many of the above choices would break clients and/or servers. Some may
be safe in the hands of capable sysadmins. Your proposal has to document
your choice(s), explain why they are the best (or at least good), and
analyze the associated risks/problems.


> 2. *peek-bump*
> *
> As we have discussed already in the general forum
> (http://squid-web-proxy-cache.1019090.n4.nabble.com/server-persistent-connections-and-cache-td4685973.html
> <http://squid-web-proxy-cache.1019090.n4.nabble.com/server-persistent-connections-and-cache-td4685973.html>),
> the table contains the cases where pinning happens and where not, we
> would like to achieve the SSL persistence here from squid to-server
> connection. When we unpin the connection it gets closed, and we would
> like to retain them up in the pool. Please let me know what information
> is required in this case for further validation. 

The bumping cases have pretty much the same unanswered questions as
splicing cases (and more). Bumping cases have access to HTTP-level
information (of bumped messages), but I do not know whether you need
that information to restrict reuse.

Please note that this is not so much about the code right now. It is
about deciding and documenting what you want Squid to do (differently)
at the level of detail sufficient for others to review your proposal and
make correct, informed recommendations.

Today, we do not know why you want to reuse some connections, and how
you want to map your needs to Squid configuration/functionality changes.
Thus, it is impossible to predict whether your future changes will be
accepted even if those changes are implemented correctly and beautifully.


HTH,

Alex.


> On Tue, Jul 31, 2018 at 4:29 PM, Alex Rousskov wrote:
> 
>     On 07/31/2018 05:00 PM, Vishali Somaskanthan wrote:
>     > If I peek @step1 and splice@ step2 -> The connections are **not**
>     pinned
>     > as such. However, Client-squid SSL+TCP termination results in
>     > squid-server SSL+TCP termination.
> 
>     Why does Squid close the (not pinned) Squid-to-server connection in this
>     case? What code/condition triggers that closure in your tests?
> 
> 
>     > Please provide any insights on whether this is going to be a valid
>     > optimization and if we can come up with a set of rules where this
>     > could apply.
> 
>     With enough information/analysis, we should be able to correctly
>     evaluate your proposal, but that proposal will have to be a lot more
>     specific than "We want to optimize TLS and evaluate if squid to-server
>     TLS connection can be reused for consecutive requests from multiple
>     clients". My question above is a (small) step towards formulating a
>     specific "We want to change Squid to do X instead of Y" proposal.
> 
> 
>     Thank you,
> 
>     Alex.
> 
> 
> 
> 
> -- 
> Regards,
> Vishali Somaskanthan
> 
> 
> _______________________________________________
> squid-dev mailing list
> squid-dev at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-dev
>