Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative

Поиск
Список
Период
Сортировка
От Daniel Gustafsson
Тема Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative
Дата
Msg-id B5E2B87D-3E8A-4597-9A7F-8489B3B67556@yesql.se
обсуждение исходный текст
Ответ на Re: [HACKERS] Support for Secure Transport SSL library on macOS as OpenSSL alternative  (Daniel Gustafsson <daniel@yesql.se>)
Ответы Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative  (Thomas Munro <thomas.munro@enterprisedb.com>)
Список pgsql-hackers
> On 03 Aug 2017, at 13:36, Daniel Gustafsson <daniel@yesql.se> wrote:
>
>> On 03 Aug 2017, at 13:06, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>>
>> Why can't you have the root certificate in the keychain, too? Just not implemented yet, or is there some fundamental
problemwith it? 
>
> Just not implemented yet, awaiting Keychain discussions.

Supported in this new patchset.

> Yeah, discussion -> documentation -> code was my plan.

Attached is an updated set of patches, rebased on top of master, with bug fixes
and additional features missing in the first set.  While not complete (yet), in
case anyone is testing this I’d rather send a fresh batch rather than sitting
on them too long while I keep hacking at the docs.  While not every part of
this rather large changeset has been touched, this includes all the patches for
completeness sake.

This patchset has certificate revocation as the main thing left.  I’ve done
work on supporting CRLs via a Keychain and a CRL policy but that needs more
work (any help is much welcome).

DH parameters are loaded via the GUC, and instead of DER format (which is what
Secure Transport wants) it uses PEM such that it can load the same precomputed
parameter as be-secure-openssl.c and the same files.

Keychains are supported for root certificates in the frontend as well and are
added to the backend for identities as a first test for how it can be
integrated.  Referencing an identity in a keychain is done by prefixing the
certificate parameter with keychain: and specifying the common name rather than
filename.  The current code doesn’t support setting the passphrase for a
Keychain, it will try with a blank password (since thats handy for testing) and
if that fails it will bring up a GUI element for the passphrase.  How to set a
passphrase in the server is open for discussion, a Keychain cannot be created
without a passphrase (it can be blank, but you still need to pass ‘’ to it).

There is a first stab at documentation included, it needs a lot more work to
fully separate generic SSL information and backend specific information but
it’s a WIP.

Additionally, a fix for an issue in the SSL tests is included which only
surface in the Secure Transport tests since it uses connstring parameters with
spaces in them.

0001: Adds support for running the SSL tests against another set of server
binaries. Not changed from previous submission, except rebased on top of master.

0002: Secure Transport support for frontend & backend.

0003: A rough first stab at updating the docs to split SSL documentation into
generic SSL information, and backend specific information.  Lot’s to do still
here but it’s a start.

0004: A fix for an issue in the SSL tests which broke Secure Transport testing.
The SELECT ‘$connstr’ clause in the test doesn’t play nice with connstrings
containing sslcert:'keychain:common name’ parameters.

cheers ./daniel


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] SCRAM salt length
Следующее
От: Dave Page
Дата:
Сообщение: Re: [HACKERS] pl/perl extension fails on Windows