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