[PATCH] Keepalive: add new option "keepalive_ssl_respect_sni"

[Maxim Dounin]

Hello!

On Tue, Mar 16, 2021 at 05:42:01PM +0300, geniuss99 wrote:

> > SSL sessions are cached in the context of the upstream{} block (or an implicit upstream when using an IP address or a DNS name)
> Oh, I didn't think of that. I guess this can be solved by patching the
> ngx_http_upstream_round_robin module and saving many sessions per each
> upstream peer.
> 
> > No, thank you. The issues as observed in the tickets linked should be resolved by using distinct upstream blocks instead.
> So what was the reason you rejected the previous patch? Was it because
> of breaking ssl sessions caching mechanism?
> Or you just didn't see it fit for nginx from the design
> (architectural) point of view?

>From the design point of view, upstream{} blocks expect all 
connections to a peer to be equivalent.  At the same time,
these connections might be established with different 
connection-specific settings, such as:

- proxy_bind
- proxy_socket_keepalive
- proxy_ssl_certificate
- proxy_ssl_certificate_key
- proxy_ssl_ciphers
- proxy_ssl_conf_command
- proxy_ssl_crl
- proxy_ssl_name
- proxy_ssl_protocols
- proxy_ssl_server_name
- proxy_ssl_trusted_certificate
- proxy_ssl_verify
- proxy_ssl_verify_depth

Trying to conditionally "respect" some of these settings, such as 
proxy_ssl_name, by caching connections based on the name in 
addition to the peer's address, looks wrong.  The same applies to 
configurable caching key, as suggested in the previous patch.

I think that two principal approaches are possible here:

1. Respect all the existing connection-specific settings 
automatically, and avoid using cached connections and/or saved SSL 
sessions if any of the settings does not match.

2. Assume that the configuration is written in a way which 
prevents misuse of cached connections / saved SSL sessions.

Current approach is (2).  That is, connections to the same peer 
should be equivalent (in most cases this can be achieved by using 
distinct upstream blocks if you have to use different 
connection-specific settings), or keepalive connections shouldn't 
be enabled (and SSL session reuse should be disabled as 
appropriate).

Switching to (1) is possible, but will require significant effort, 
and have no obvious benefits for common configurations.

IMHO, the only compelling reason to implement (1) is introduction 
of some form of default keepalive connections cache, but this is 
not something nginx supports.

-- 
Maxim Dounin
http://mdounin.ru/