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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Subject: Re: Support for Secure Transport SSL library on macOS as OpenSSL alternative
Date: 2017-08-17 14:14:24
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

> On 03 Aug 2017, at 13:36, Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
>> On 03 Aug 2017, at 13:06, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:
>> Why can't you have the root certificate in the keychain, too? Just not implemented yet, or is there some fundamental problem with 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

Attachment Content-Type Size
0001-Allow-running-SSL-tests-against-different-binar-v2.patch application/octet-stream 8.9 KB
0002-WIP-Add-support-for-Apple-Secure-Transport-SSL-li-v2.patch application/octet-stream 110.0 KB
0003-WIP-A-first-stab-at-documentation-for-Secure-Tran-v2.patch application/octet-stream 13.4 KB
0004-Fix-SSL-tests-for-connstrings-with-spaces-v2.patch application/octet-stream 1.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2017-08-17 14:16:16 Re: pl/perl extension fails on Windows
Previous Message Robert Haas 2017-08-17 14:03:53 Re: SCRAM salt length