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

[Amos Jeffries]

On 7/06/19 9:30 pm, Srikanth Raju wrote:
> Hello!
> We are planning to use squid as a forward egress proxy to whitelist
> domains. In general, we configured it to whitelist/blacklist domains
> based on the examples in the site and this seems to work with peek and
> splice on our preliminary tests as a transparent egress proxy. We're
> doing this with an AWS VPC using the standard techniques documented in
> their blogs
> 
> I had a few questions about the setup for some additional features
> 
>   * We want to have the ability to connection pool certain HTTPS calls
>     going externally within from within squid. This would be
>     specifically for some external partners that we know have slow
>     connection setup time and or in case of misbehaving libraries.
>   * WIth "peek and splice" method for HTTPS, this doesn't make sense,
>     since it's a TCP tunnel basically. There shouldn't be a way to
>     replay the handshake, hence it's impossible to pool at the squid layer.

Your conclusion is correct. But the true reason is that splice sets up
an end-to-end relationship for the client and server. Squid has no part
of anything happening inside the tunnel. There is *literally* no way to
coordinate N clients to share a tunnel.


>   * We need to consider 'bump' for some use cases along with our own
>     intermediate CA, which we're ok with, since we can choose the
>     domains to 'splice' and domains to 'bump'/

Correct.

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

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.


> 
> Another thing we cared about , with a much lower priority, was HTTP/2
> translation. We would like to reap the benefits of HTTP/2 on external
> services that do support it and we connect to, but our application does
> not yet have any production-safe http2 clients(python).
> Is there any roadmap for when that will land on Squid master?
> 

HTTP/2 is not being directly worked on at present. I go back to it
occasionally, but most of my time has been taken up with improving the
HTTPS support.


Amos