Thread: [HACKERS] [PATCH] configure-time knob to set default ssl ciphers
Hi hackers, in Fedora, there's crypto initiative where people try to consolidate ssl cipher settings for (majority of) Fedora services (PostgreSQL is included). 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). What that really does is: kEECDH:kRSA:kEDH:kPSK:kDHEPSK:kECDHEPSK:!EXP:!DES:!RC4:!RC2:!IDEA\ :!SEED:!eNULL:!aNULL:!MD5:!SSLv2 .. but that's just for the record (should be subset of upstream default); more info in RH bug [1]. I'd like to propose the attached patch, so we could (without downstream patching) do $ ./configure ... --with-openssl-be-ciphers=PROFILE=SYSTEM [1] https://bugzilla.redhat.com/show_bug.cgi?id=1348125 Thanks for considering! Pavel -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Attachment
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
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
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
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 >
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 > 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
Attachment
> 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
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
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
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