Re: BUG #14329: libpq doesn't send complete client certificate chain on first SSL connection

On Tue, 4 Oct 2016 21:55:52 +0300
Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> 1. Since the SSL context is shared between all connections and all
> threads, there's a race condition if two threads try to open a
> connection at the same time. The SSL_CTX_use_certificate_chain_file()
> call, and SSL_CTX_load_verify_locations() later in the function, are
> protected by the global mutex, but we only hold the mutex for the
> duration of those calls. It doesn't protect from the fact that while one
> thread is opening a connection with one set of options, another thread
> opens a connection with different options. They might get mixed up.
> That's a problem if the connections use different sslcert or sslrootcert
> settings.
>
> 2. Even with a single thread, using different sslrootcert options in
> different PQconnectdb() calls fails outright, with error:
>
> SSL error: block type is not 01
>
> I got that with a test program that simply calls:
>
> PQconnectdb(<connection string 1>);
> PQfinish();
> PQconnectdb(<connection string 2>);
> PQfinish();

> I'm starting to feel that using the same SSL_CTX object for multiple
> connections is just too fragile. Perhaps we could share one SSL_CTX
> object for all the connections with no sslcert and no sslrootcert, but
> I'm not sure if even that is worth it.
>
> In quick testing, calling SSL_CTX_new() for each connection adds about
> 3% of overhead to establishing a new connection, with the default
> OpenSSL settings (seems to use ECDHE-RSA-AES256-GCM-SHA384 cipher here).
> I also tested memory usage with a program that opens 10000 connections,
> and it used about 15% more memory, when SSL_CTX_new() is called for each
> connection. I think that's acceptable. Barring objections, I'm going to
> write a patch to use a separate SSL context for every connection.

What about keeping a table of connection strings and SSL contexts so that all
connections using the same connection string could share the SSL context? It
seems likely that most applications reuse the same connection string and
could avoid the penalty.

-dg

--
David Gould 510 282 0869 daveg(at)sonic(dot)net
If simplicity worked, the world would be overrun with insects.