[PATCH] configure-time knob to set default ssl ciphers

Pavel Raiskup <praiskup@redhat.com> writes:

PostgreSQL server uses 'HIGH:MEDIUM:+3DES:!aNULL' cipher set by default,
but what Fedora would like to have is 'PROFILE=SYSTEM' (works with
Fedora-patched OpenSSL, so please don't waste your time with checking this
elsewhere).
...
I'd like to propose the attached patch, so we could (without downstream
patching) do
$ ./configure ... --with-openssl-be-ciphers=PROFILE=SYSTEM

Meh. This is pretty far from a complete patch: it introduces an
undocumented configure switch, and it changes the default value for a GUC
without fixing either the corresponding SGML documentation or the
postgresql.conf.sample line for it.

While it would surely be possible to build all the infrastructure to make
that work right, I'm not really sure that we want to carry around that
much baggage for a single-system hack.

A compromise that might be worth considering is to introduce

#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"

into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.

regards, tom lane

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

On 2/7/17 11:21 AM, Tom Lane wrote:

A compromise that might be worth considering is to introduce

#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"

into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.

You'd still need to patch postgresql.conf.sample somehow.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 2/7/17 11:21 AM, Tom Lane wrote:

A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.

You'd still need to patch postgresql.conf.sample somehow.

Right. The compromise position that I had in mind was to add the
#define in pg_config_manual.h and teach initdb to propagate it into
the installed copy of postgresql.conf, as we've done with other GUCs
with platform-dependent defaults, such as backend_flush_after.

That still leaves the question of what to do with the SGML docs.
We could add some weasel wording to the effect that the default might
be platform-specific, or we could leave the docs alone and expect the
envisioned Red Hat patch to patch config.sgml along with
pg_config_manual.h.

It looks like the xxx_flush_after GUCs aren't exactly fully documented
as to this point, so we have some work to do there too :-(

regards, tom lane

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

On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 2/7/17 11:21 AM, Tom Lane wrote:

A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.

You'd still need to patch postgresql.conf.sample somehow.

Right. The compromise position that I had in mind was to add the
#define in pg_config_manual.h and teach initdb to propagate it into
the installed copy of postgresql.conf, as we've done with other GUCs
with platform-dependent defaults, such as backend_flush_after.

That still leaves the question of what to do with the SGML docs.
We could add some weasel wording to the effect that the default might
be platform-specific, or we could leave the docs alone and expect the
envisioned Red Hat patch to patch config.sgml along with
pg_config_manual.h.

Thanks for quickt feedback. Just to not give up too early, I'm attaching
2nd iteration. I'm fine to fallback to pg_config_manual.h solution though,
if this is considered too bad.

I tried to fix the docs now (crucial part indeed) so we are not that
"scrict" and there's some space for per-distributor change of ssl_ciphers
default.

From the previous mail:

I'm not really sure that we want to carry around that much baggage for a
single-system hack.

Accepted, but still I'm giving a chance. OpenSSL maintainers predict this (or
something else in similar fashion) is going to be invented in OpenSSL upstream.
So there's still some potential in ./configure option.

Thanks!
Pavel

It looks like the xxx_flush_after GUCs aren't exactly fully documented
as to this point, so we have some work to do there too :-(

regards, tom lane

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

On Wednesday, February 8, 2017 1:29:19 PM CET Pavel Raiskup wrote:

On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 2/7/17 11:21 AM, Tom Lane wrote:

A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.

You'd still need to patch postgresql.conf.sample somehow.

Right. The compromise position that I had in mind was to add the
#define in pg_config_manual.h and teach initdb to propagate it into
the installed copy of postgresql.conf, as we've done with other GUCs
with platform-dependent defaults, such as backend_flush_after.

That still leaves the question of what to do with the SGML docs.
We could add some weasel wording to the effect that the default might
be platform-specific, or we could leave the docs alone and expect the
envisioned Red Hat patch to patch config.sgml along with
pg_config_manual.h.

Thanks for quickt feedback. Just to not give up too early, I'm attaching
2nd iteration. I'm fine to fallback to pg_config_manual.h solution though,
if this is considered too bad.

I tried to fix the docs now (crucial part indeed) so we are not that
"scrict" and there's some space for per-distributor change of ssl_ciphers
default.

From the previous mail:

I'm not really sure that we want to carry around that much baggage for a
single-system hack.

Accepted, but still I'm giving a chance. OpenSSL maintainers predict this (or
something else in similar fashion) is going to be invented in OpenSSL upstream.
So there's still some potential in ./configure option.

Argh :( ! Attaching now and sorry.

Pavel

On 08 Feb 2017, at 13:31, Pavel Raiskup <praiskup@redhat.com> wrote:

On Wednesday, February 8, 2017 1:29:19 PM CET Pavel Raiskup wrote:

On Wednesday, February 8, 2017 1:05:08 AM CET Tom Lane wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

On 2/7/17 11:21 AM, Tom Lane wrote:

A compromise that might be worth considering is to introduce
#define PG_DEFAULT_SSL_CIPHERS "HIGH:MEDIUM:+3DES:!aNULL"
into pg_config_manual.h, which would at least give you a reasonably
stable target point for a long-lived patch.

You'd still need to patch postgresql.conf.sample somehow.

Right. The compromise position that I had in mind was to add the
#define in pg_config_manual.h and teach initdb to propagate it into
the installed copy of postgresql.conf, as we've done with other GUCs
with platform-dependent defaults, such as backend_flush_after.

That still leaves the question of what to do with the SGML docs.
We could add some weasel wording to the effect that the default might
be platform-specific, or we could leave the docs alone and expect the
envisioned Red Hat patch to patch config.sgml along with
pg_config_manual.h.

Thanks for quickt feedback. Just to not give up too early, I'm attaching
2nd iteration. I'm fine to fallback to pg_config_manual.h solution though,
if this is considered too bad.

I tried to fix the docs now (crucial part indeed) so we are not that
"scrict" and there's some space for per-distributor change of ssl_ciphers
default.

From the previous mail:

I'm not really sure that we want to carry around that much baggage for a
single-system hack.

Accepted, but still I'm giving a chance. OpenSSL maintainers predict this (or
something else in similar fashion) is going to be invented in OpenSSL upstream.
So there's still some potential in ./configure option.

Argh :( ! Attaching now and sorry.

Since we hopefully will support more SSL libraries than OpenSSL at some point,
and we don’t want a torrent of configure options, wouldn’t this be better as
--with-server-ciphers=STRING or something similar?

+   --with-openssl-be-ciphers=STRING
+                           Replace the default list of server-supported ciphers

Each SSL implementation would then be responsible for handling it appropriately.

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

Daniel Gustafsson <daniel@yesql.se> writes:

Since we hopefully will support more SSL libraries than OpenSSL at some point,
and we don’t want a torrent of configure options, wouldn’t this be better as
--with-server-ciphers=STRING or something similar?

One of the reasons I'm not very excited about exposing this as a configure
option is exactly that I'm not sure what happens when we get multiple TLS
library support. The cipher list we've got at the moment seems like it
is probably OpenSSL-specific (but maybe not?). If we did have code for
multiple libraries, perhaps some people would want to compile all the
variants at once; in which case overloading a single option to be used for
all the libraries would be a problem.

This would all be a lot clearer if we already had that code, but since
we don't, I'm inclined to be conservative about exposing new features
that make assumptions about how it will be.

regards, tom lane

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

Tom Lane wrote:

Daniel Gustafsson <daniel@yesql.se> writes:

Since we hopefully will support more SSL libraries than OpenSSL at some point,
and we don’t want a torrent of configure options, wouldn’t this be better as
--with-server-ciphers=STRING or something similar?

One of the reasons I'm not very excited about exposing this as a configure
option is exactly that I'm not sure what happens when we get multiple TLS
library support. The cipher list we've got at the moment seems like it
is probably OpenSSL-specific (but maybe not?).

Maybe the list of ciphers is not OpenSSL-specific, but the *syntax* most
likely is. Particularly the abbreviations such as !eNULL and !MD5, etc.

If we did have code for multiple libraries, perhaps some people would
want to compile all the variants at once; in which case overloading a
single option to be used for all the libraries would be a problem.

Hmm, I don't think our abstraction would allow for compiling more than
one at a time. ISTM that all that work has been considering that you'd
choose at most one at compile time. I'm not sure it's useful to have
more than one anyway. If you choose one SSL implementation at configure
time, it's on your head to specify a ssl-ciphers that that
implementation accepts (of course, we would choose a working default if
you don't specify one.)

(I was going to suggest --with-ssl-ciphers but the protocol is called
TLS nowadays, so maybe not a great idea.)

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

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

Alvaro Herrera <alvherre@2ndquadrant.com> writes:

Tom Lane wrote:

If we did have code for multiple libraries, perhaps some people would
want to compile all the variants at once; in which case overloading a
single option to be used for all the libraries would be a problem.

Hmm, I don't think our abstraction would allow for compiling more than
one at a time. ISTM that all that work has been considering that you'd
choose at most one at compile time.

Very possibly it'll end up that way. But I'm not eager to pre-judge that
decision, especially if we're doing it only to support a system-specific
hack that could be handled in other ways.

regards, tom lane

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