Re: Supporting Windows SChannel as OpenSSL replacement
От | Heikki Linnakangas |
---|---|
Тема | Re: Supporting Windows SChannel as OpenSSL replacement |
Дата | |
Msg-id | 53EA546E.6020404@vmware.com обсуждение исходный текст |
Ответ на | Re: Supporting Windows SChannel as OpenSSL replacement (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Supporting Windows SChannel as OpenSSL replacement
Re: Supporting Windows SChannel as OpenSSL replacement Re: [HACKERS] Supporting Windows SChannel as OpenSSL replacement |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: