<div dir="ltr"><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt">Hi,</span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt">FYI, in all my examples below, one have the same client and same server<span></span></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt"><span> </span></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt">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 “<i>server_persistent_connection on</i>” 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?<span></span></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt"><span> </span></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt">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).<span></span></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt">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<span></span></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt">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.<span></span></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt"><span> </span></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt">Is this the expected behavior? Please explain.</span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt"><br></span></p><p class="MsoNormal" style="margin:0in 0in 0.0001pt;font-size:12pt;font-family:Calibri,sans-serif;color:rgb(0,0,0)"><span style="font-size:11pt">Thank you.</span></p><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 26, 2018 at 2:13 PM, Alex Rousskov <span dir="ltr"><<a href="mailto:rousskov@measurement-factory.com" target="_blank">rousskov@measurement-factory.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 07/26/2018 02:49 PM, Vishali Somaskanthan wrote:<br>
<br>
> 1. Are there any security reasons behind /pinning the connection/ when a<br>
<span class="">> peek is done at Step1<br>
<br>
</span>I doubt there is some fundamental _security_ reason to pin if you bump<br>
without forwarding the TLS client information to the server. The reasons<br>
to pin in that case include:<br>
<br>
* honoring client and server blind tunneling expectations<br>
  (which may result in better compatibility or even security);<br>
<br>
* development convenience (pinning _all_ SslBump connections is easier<br>
  than pinning some of them).<br>
<br>
<br>
> Why is that done?<br>
<br>
I speculate it was done for the reasons stated in the above bullets.<br>
<br>
<br>
> 2.a)  what is the scenario where a pinned connection can be reused? <br>
<br>
When a previously established Squid-to-server connection is used for the<br>
next request on the corresponding client-to-Squid connection.<br>
<br>
<br>
>    b) Which configure option is used to enable /#if STRICT_ORIGINAL_DST ?/<br>
<br>
There is no user-friendly way to control that macro AFAICT. You may<br>
define it when building Squid from sources (e.g., by passing<br>
-DSTRICT_ORIGINAL_DST=1 to the compiler via CPPFLAGS). Please do not<br>
misinterpret my response as an indication that this is an officially<br>
supported feature.<br>
<br>
<br>
HTH,<br>
<br>
Alex.<br>
<div><div class="h5"><br>
<br>
<br>
> On Wed, Jul 18, 2018 at 5:00 PM, Alex Rousskov wrote:<br>
> <br>
>     On 07/18/2018 03:03 PM, Vishali Somaskanthan wrote:<br>
> <br>
>     > I had a problem after sending too many requests to the same server where<br>
>     > my persistence stopped working suddenly.<br>
> <br>
>     Please note that there are many reasons why a proxy may close a<br>
>     connection. For pinned to-server connections (like those created by<br>
>     SslBump), it may not be possible to open a new to-server connection so<br>
>     Squid should close both from-client and to-server connections.<br>
> <br>
>     In general, a client should not rely on a connections staying persistent<br>
>     except in some very unusual/special circumstances.<br>
> <br>
> <br>
>     > 1. What is the relationship between the caching and the persistence<br>
>     > connection established?<br>
> <br>
>     Virtually none. Caching decisions are done primarily based on request<br>
>     and response headers.<br>
> <br>
> <br>
>     > 2. When will squid use cached results and when will it not if the cache<br>
>     > deny all directive weren't specified. <br>
> <br>
>     Squid will deliver a response from the cache when HTTP rules and Squid<br>
>     configuration allow a hit. The details are too complex to document here.<br>
> <br>
> <br>
>     > 3. However, this didn't work fully. Even with /cache deny all/<br>
>     > directive, persistence wasn't working when I peeked at the sslBump step<br>
>     > 1 and then Bumped. <br>
>     > Persistence worked only when I directly did sslbump allow all (without<br>
>     > peeking at first step).<br>
> <br>
>     Bumping step should not affect connection persistence AFAICT. I do not<br>
>     know why it does in your case. This could be a Squid bug or a<br>
>     misunderstanding. If you can reproduce, Squid logs should contain<br>
>     reasons for each connection closure (but it may be difficult to find).<br>
> <br>
> <br>
>     HTH,<br>
> <br>
>     Alex.<br>
> <br>
> <br>
> <br>
> <br>
> -- <br>
> Regards,<br>
> Vishali Somaskanthan<br>
> <br>
> <br>
</div></div>> ______________________________<wbr>_________________<br>
> squid-users mailing list<br>
> <a href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.<wbr>org</a><br>
> <a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/<wbr>listinfo/squid-users</a><br>
> <br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div>Regards,</div>Vishali Somaskanthan</div></div>
</div></div>