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

[Srikanth Raju]

I see, thank you for this explanation and clarification Alex!

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?

On Fri, Jun 7, 2019 at 9:04 AM Alex Rousskov <
rousskov at measurement-factory.com> 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
> http://lists.squid-cache.org/listinfo/squid-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20190610/ffae7a57/attachment.html>