[squid-users] server persistent connections and cache

[Alex Rousskov]

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).
> 
> 
>     HTH,
> 
>     Alex.
> 
> 
> 
> 
> -- 
> Regards,
> Vishali Somaskanthan
> 
> 
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>