]> granicus.if.org Git - postgresql/commit
Don't share SSL_CTX between libpq connections.
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Fri, 7 Oct 2016 09:20:39 +0000 (12:20 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Fri, 7 Oct 2016 09:20:39 +0000 (12:20 +0300)
commit8bb14cdd33deecc6977cf5638f73e80f76ab658b
tree3fee45d5afedfcc45b26c5563b2cf886dcae2e97
parentd7eb76b908a3aac68c23c7d3553c65c80e92b823
Don't share SSL_CTX between libpq connections.

There were several issues with the old coding:

1. There was a race condition, if two threads opened a connection at the
   same time. We used a mutex around SSL_CTX_* calls, but that was not
   enough, e.g. if one thread SSL_CTX_load_verify_locations() with one
   path, and another thread set it with a different path, before the first
   thread got to establish the connection.

2. Opening two different connections, with different sslrootcert settings,
   seemed to fail outright with "SSL error: block type is not 01". Not sure
   why.

3. We created the SSL object, before calling SSL_CTX_load_verify_locations
   and SSL_CTX_use_certificate_chain_file on the SSL context. That was
   wrong, because the options set on the SSL context are propagated to the
   SSL object, when the SSL object is created. If they are set after the
   SSL object has already been created, they won't take effect until the
   next connection. (This is bug #14329)

At least some of these could've been fixed while still using a shared
context, but it would've been more complicated and error-prone. To keep
things simple, let's just use a separate SSL context for each connection,
and accept the overhead.

Backpatch to all supported versions.

Report, analysis and test case by Kacper Zuk.

Discussion: <20160920101051.1355.79453@wrigleys.postgresql.org>
src/interfaces/libpq/fe-secure-openssl.c
src/test/ssl/Makefile
src/test/ssl/README
src/test/ssl/ServerSetup.pm
src/test/ssl/ssl/client+client_ca.crt [new file with mode: 0644]
src/test/ssl/t/001_ssltests.pl