[squid-users] Questions about connection pooling to origins when using squid as a HTTPS forward egress proxy

[Alex Rousskov]

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 at lists.squid-cache.org
>     <mailto:squid-users at lists.squid-cache.org>
>     http://lists.squid-cache.org/listinfo/squid-users
>