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). > > > > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
