<div dir="ltr"><div>I see, thank you for this explanation and clarification Alex!<br><br></div>Would you like me to file a bug report for this and is this work you think that might be of interest to others who use squid?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jun 7, 2019 at 9:04 AM Alex Rousskov <<a href="mailto:rousskov@measurement-factory.com">rousskov@measurement-factory.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 6/7/19 5:24 AM, Srikanth Raju wrote:<br>
> <br>
> <br>
>     >   * The biggest reason we care about TLS termination with bump is<br>
>     >     because we think it might give us performance benefits along some<br>
>     >     critical code paths *due to connection pooling to some slow<br>
>     >     upstreams within squid.*<br>
>     >   * Does squid automatically do this or does it need some extra<br>
>     config.<br>
>     >     I was looking at 'server_connections' config var.<br>
> <br>
>     HTTPS connections cannot be pooled due to protocol ties at the transport<br>
>     level between clients and servers. Once details of the TLS handshake are<br>
>     delivered they are pinned together.<br>
> <br>
> Well, what I meant was, that if we use "bump" directive, it is<br>
> effectively terminating the  TLS connection from client at squid.<br>
<br>
If you bump at step 1 (a.k.a. client-first bumping), then yes, TLS<br>
connections to server can be pooled. I do not know whether Squid<br>
supports that today, but there is no fundamental reason why it cannot.<br>
Unfortunately, in most cases, you cannot successfully bump at step 1.<br>
<br>
If you bump at step 2+, then the resulting client-Squid and Squid-server<br>
connection pairs are based on the client handshake. Yes, Squid<br>
establishes its own TLS connection to the origin server, but it does so<br>
while mimicking TLS client properties. Reusing that server connection<br>
for another client would be risky -- the second client can request some<br>
TLS security features that the first client did not care about, and<br>
Squid would have to essentially ignore the second client requirements<br>
when talking to the origin server using a reused to-server connection<br>
established on behalf of the first TLS client. It would be possible to<br>
add an option that enables such risky reuse AFAICT, but that reuse<br>
should not be done by default.<br>
<br>
<br>
> And<br>
> then squid initiates a separate TLS connection to the server. with it's<br>
> own shared secret. Those connections to the servers/backends can be<br>
> pooled. This means there's a decryption/reencryption step in between. Is<br>
> not that what happens with squid?<br>
<br>
Yes, it is, but pooling is disabled (i.e. the to-server connection is<br>
"pinned" to the from-client connection) due to security concerns<br>
discussed above.<br>
<br>
Alex.<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>