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