Fwd: Automatic pooling of upstream keepalive connections (patch proposal)

[Greg Vishnepolsky]

Hi there,

While I agree that precise host comparison is suboptimal, I think that in
this case it's better to chose the strictest (and simplest) approach for
the sake of security.

Here is a slightly revised version of the patch:
https://gist.github.com/gregvish/6572002/raw/4664ac0d3a81473086f185075a1f67c1e02b5877/v3_default_keepalive_patch

I've attempted to think of a nice way to decouple the code, but I couldn't
think of anything pretty. At this point I've put some ifdefs around the
code that references the keepalive module from the proxy and upstream
modules.
This coupling is similar to the existing coupling of the
"ngx_http_upstream_round_robin" module with the upstream module. In that
case, the round robin balancer is used as a default for "un-resolved"
upstreams.
I guess the right solution for the problem at hand should involve
configuring both the balancer and keepalive (and other upstream options)
for the default case.

Thanks,
Greg


On Wed, Sep 11, 2013 at 7:32 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:

> Hello!
>
> 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 1.1.1.1:443
> > https://b.host.com also resoves to 1.1.1.1:443
> > If the server at 1.1.1.1 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.
>
> --
> Maxim Dounin
> http://nginx.org/en/donation.html
>
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20130915/41a8838a/attachment.html>