> * 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 squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
