> * 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 :)
_______________________________________________ squid-users mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-users
