Hi, FYI, in all my examples below, one have the same client and same server
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. 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? 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). 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? Please explain. Thank you. On Thu, Jul 26, 2018 at 2:13 PM, Alex Rousskov < rouss...@measurement-factory.com> 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). > > > > > > HTH, > > > > Alex. > > > > > > > > > > -- > > Regards, > > Vishali Somaskanthan > > > > > > _______________________________________________ > > squid-users mailing list > > squid-users@lists.squid-cache.org > > http://lists.squid-cache.org/listinfo/squid-users > > > > -- Regards, Vishali Somaskanthan
_______________________________________________ squid-users mailing list squid-users@lists.squid-cache.org http://lists.squid-cache.org/listinfo/squid-users
