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

[Srikanth Raju]

>   * 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. 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?



> Instead Squid delivers what https:// responses it can from cache, which
> is the next best thing.
>
>
> > [Currently we
> >     roughly follow the config in the AWS Guide]
> >     <
> https://aws.amazon.com/blogs/security/how-to-add-dns-filtering-to-your-nat-instance-with-squid/
> >
> >
>
> Please be aware that config is unsafe. It effectively makes an
> open-proxy setup. Any client anywhere in the world can abuse the proxy
> as a relay to reach any AWS hosted site.
>

Ah, interesting, thank you for pointing out that detail. We're just testing
and playing around with it right now, so we're safe luckily :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20190607/042fedce/attachment.html>