Re: Supporting Windows SChannel as OpenSSL replacement

Heikki Linnakangas <hlinnakangas@vmware.com>

From: Heikki Linnakangas <hlinnakangas@vmware.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Andreas Karlsson <andreas@proxel.se>, Martijn van Oosterhout <kleptog@svana.org>, Magnus Hagander <magnus@hagander.net>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2014-08-12T17:52:46Z
Lists: pgsql-hackers

Attachments

On 08/06/2014 08:37 PM, Jeff Janes wrote:
> But now it looks like 0002 needs a rebase....

I've committed the refactoring patch, and here's a rebased and improved 
version of the Windows SChannel implementation over that.

Server-side support is now implemented too, but it's all very crude and 
work-in-progress. CRLs are not supported, intermediary CAs are not 
supported, and probably many other bells and whistles are missing too. 
But the basics work, including cert authentication. Consider this a 
Proof of Concept.

One issue came up with managing private keys: In the server, it's 
necessary to import the private key into a permanent key container 
that's managed by the Windows Crypto API. That can be done 
programmatically (as I do in the patch), but the keys are permanently 
stored in the system (in the user's profile). They will be left behind 
even if you completely delete the data directory. That's not the end of 
the world, but it would be nicer if we could use some kind of a 
temporary key container that only lives in memory, but the Crypto API 
doesn't seem to have such a concept. You can acquire an ephemeral 
context by passing the CRYPT_VERIFYCONTEXT flag to CryptAcquireContext 
function, and that's exactly what I'm doing in the client, but that 
method doesn't seem to work when acting as an SSL server.

Also, the key container needs to be given a name, or we can use the 
default container, but either way all the keys are shared among all 
applications that use the same container. We'll have to figure out how 
to set that up so that there are no conflicts, if you try to use the 
same server certificate for two PostgreSQL instances running on the same 
host (useful while developing/testing replication).

This isn't a showstopper, but needs some thought. As the patch stands, 
it uses a single key container called "PostgreSQL server key container", 
and makes no attempt to delete the keys after they're no longer used. 
That works, but it leaves the key lying on the system.

- Heikki