On 6/10/19 9:09 PM, Srikanth Raju wrote: > 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? You can certainly submit a feature request for optional pooling of connections bumped at step 2+, but I do not know whether others would support an official addition of that feature. The answer may depend on the quality of your arguments and the commonality of your use case. Alex. > On Fri, Jun 7, 2019 at 9:04 AM Alex Rousskov wrote: > > On 6/7/19 5:24 AM, Srikanth Raju wrote: > > > > > > > * The biggest reason we care about TLS termination with > bump is > > > because we think it might give us performance benefits > along some > > > critical code paths *due to connection pooling to some slow > > > upstreams within squid.* > > > * Does squid automatically do this or does it need some extra > > config. > > > I was looking at 'server_connections' config var. > > > > HTTPS connections cannot be pooled due to protocol ties at the > transport > > level between clients and servers. Once details of the TLS > handshake are > > delivered they are pinned together. > > > > Well, what I meant was, that if we use "bump" directive, it is > > effectively terminating the TLS connection from client at squid. > > If you bump at step 1 (a.k.a. client-first bumping), then yes, TLS > connections to server can be pooled. I do not know whether Squid > supports that today, but there is no fundamental reason why it cannot. > Unfortunately, in most cases, you cannot successfully bump at step 1. > > If you bump at step 2+, then the resulting client-Squid and Squid-server > connection pairs are based on the client handshake. Yes, Squid > establishes its own TLS connection to the origin server, but it does so > while mimicking TLS client properties. Reusing that server connection > for another client would be risky -- the second client can request some > TLS security features that the first client did not care about, and > Squid would have to essentially ignore the second client requirements > when talking to the origin server using a reused to-server connection > established on behalf of the first TLS client. It would be possible to > add an option that enables such risky reuse AFAICT, but that reuse > should not be done by default. > > > > And > > then squid initiates a separate TLS connection to the server. with > it's > > own shared secret. Those connections to the servers/backends can be > > pooled. This means there's a decryption/reencryption step in > between. Is > > not that what happens with squid? > > Yes, it is, but pooling is disabled (i.e. the to-server connection is > "pinned" to the from-client connection) due to security concerns > discussed above. > > Alex. > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > <mailto: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
