Fwd: Automatic pooling of upstream keepalive connections (patch proposal)
mdounin at mdounin.ru
Wed Sep 11 16:32:59 UTC 2013
On Wed, Sep 11, 2013 at 06:54:00PM +0300, Greg Vishnepolsky wrote:
> However, in case of SSL connections, it is insufficient to identify a peer
> according to the sockaddr. The hostname is important. For examlple:
> https://a.host.com resolves to 220.127.116.11:443
> https://b.host.com also resoves to 18.104.22.168:443
> If the server at 22.214.171.124 holds an SSL cert _only_ for a.host.com, it would
> be wrong to use keepalive connections that were opened to this sockaddr for
> requests for b.host.com. If a connection will not be reused, during SSL
> handshake the host cert can be properly verified for each new host.
> The solution that I implemented for this is to add a "host" field to
> "ngx_http_upstream_keepalive_cache_t" and
> "ngx_http_upstream_keepalive_peer_data_t". The function
> "ngx_http_upstream_get_keepalive_peer" now also checks that the host
> matches, as well as the sockaddr to reuse a keepalive connection.
As of now, there is no SSL certificate verification in proxy, and
hence there is no need for a check here.
With ceritificate verification introduction some check will be
needed, but just a host equality check might be suboptimal - e.g., a
certificate might be for *.example.com, and both a.example.com and
b.example.com are valid hostnames for a connection, but a host
check won't allow a connection reuse. Possible solution would be
to check SSL peer name on an already established connection.
SNI will also complicate things once introduced. But much like
the certificate verification, it's a separate problem.
More information about the nginx-devel