[squid-users] server persistent connections and cache

[Alex Rousskov]

On 07/26/2018 05:47 PM, Vishali Somaskanthan wrote:

> By re-use I meant to say that the server-connection S (TCP + SSL) is
> re-used across 2 client connections (C1 and C2), from the same client
> one after the other is torn down. I, presume that
> “/server_persistent_connection on/” allows for such a use-case.

server_persistent_connection controls whether a single Squid-to-server
connection can carry more than one request. It does not (or should not)
control re-pinning.


> Is my
> understanding that Pinning means binding C1 to S and then if C1 is
> closed, we unpin and then later if C2 is created, we can pin it again to S?

IIRC, a lot of code assumes that pinning ties C1 and S connection
lifetimes together. I do not know whether all code assumes that. I do
not know whether there is consensus that "same lifetimes" is the correct
approach for all pinned connections.


> There is some confusion in my understanding this statement – “pinning
> _all_ SslBump connections is easier than pinning some of them”, because
> I see different behaviors when I bump at Step 1 (case 1) vs bump at Step
> 2 (case 2).

Just because something is easier in retrospect, does not mean it was
easy or even clear to the developers writing bits and pieces of that
code. There are a lot of inconsistencies (and bugs) that we are slowly
weeding out.


> Case 1: We see that no pinning happens i.e. pinConnection() is not
> called at all. C1->S gets established, C1 is closed and then C2 re-uses S
> 
> Case 2: We see that pinning happens i.e. httpsPeeked() calls
> pinConnection(). Here, C1->S gets established. Closing C1 from the
> client brings down S. Later, opening C2 opens a new server-connection S.
> 
> Is this the expected behavior?

The code just happens to work this way (evidently). It is not something
I would rely on until the matter is discussed and settled.


HTH,

Alex.


> On Thu, Jul 26, 2018 at 2:13 PM, Alex Rousskov wrote:
> 
>     On 07/26/2018 02:49 PM, Vishali Somaskanthan wrote:
> 
>     > 1. Are there any security reasons behind /pinning the connection/
>     when a
>     > peek is done at Step1
> 
>     I doubt there is some fundamental _security_ reason to pin if you bump
>     without forwarding the TLS client information to the server. The reasons
>     to pin in that case include:
> 
>     * honoring client and server blind tunneling expectations
>       (which may result in better compatibility or even security);
> 
>     * development convenience (pinning _all_ SslBump connections is easier
>       than pinning some of them).
> 
> 
>     > Why is that done?
> 
>     I speculate it was done for the reasons stated in the above bullets.
> 
> 
>     > 2.a)  what is the scenario where a pinned connection can be reused? 
> 
>     When a previously established Squid-to-server connection is used for the
>     next request on the corresponding client-to-Squid connection.
> 
> 
>     >    b) Which configure option is used to enable /#if
>     STRICT_ORIGINAL_DST ?/
> 
>     There is no user-friendly way to control that macro AFAICT. You may
>     define it when building Squid from sources (e.g., by passing
>     -DSTRICT_ORIGINAL_DST=1 to the compiler via CPPFLAGS). Please do not
>     misinterpret my response as an indication that this is an officially
>     supported feature.
> 
> 
>     HTH,
> 
>     Alex.
> 
> 
> 
>     > On Wed, Jul 18, 2018 at 5:00 PM, Alex Rousskov wrote:
>     >
>     >     On 07/18/2018 03:03 PM, Vishali Somaskanthan wrote:
>     >
>     >     > I had a problem after sending too many requests to the same
>     server where
>     >     > my persistence stopped working suddenly.
>     >
>     >     Please note that there are many reasons why a proxy may close a
>     >     connection. For pinned to-server connections (like those
>     created by
>     >     SslBump), it may not be possible to open a new to-server
>     connection so
>     >     Squid should close both from-client and to-server connections.
>     >
>     >     In general, a client should not rely on a connections staying
>     persistent
>     >     except in some very unusual/special circumstances.
>     >
>     >
>     >     > 1. What is the relationship between the caching and the
>     persistence
>     >     > connection established?
>     >
>     >     Virtually none. Caching decisions are done primarily based on
>     request
>     >     and response headers.
>     >
>     >
>     >     > 2. When will squid use cached results and when will it not
>     if the cache
>     >     > deny all directive weren't specified.
>     >
>     >     Squid will deliver a response from the cache when HTTP rules
>     and Squid
>     >     configuration allow a hit. The details are too complex to
>     document here.
>     >
>     >
>     >     > 3. However, this didn't work fully. Even with /cache deny all/
>     >     > directive, persistence wasn't working when I peeked at the
>     sslBump step
>     >     > 1 and then Bumped. 
>     >     > Persistence worked only when I directly did sslbump allow
>     all (without
>     >     > peeking at first step).
>     >
>     >     Bumping step should not affect connection persistence AFAICT.
>     I do not
>     >     know why it does in your case. This could be a Squid bug or a
>     >     misunderstanding. If you can reproduce, Squid logs should contain
>     >     reasons for each connection closure (but it may be difficult
>     to find).
>     >
>     >