From: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
---|---|
To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
Cc: | xx Z <xxz030811(at)gmail(dot)com>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: How to configure client-side TLS ciphers for streaming replication? |
Date: | 2025-08-27 19:59:18 |
Message-ID: | 8611DCDB-C0C7-4080-9E34-97E19E4F8CF5@yesql.se |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> On 26 Aug 2025, at 22:16, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> wrote:
>
> On Tue, 2025-08-26 at 20:34 +0800, xx Z wrote:
>> Thanks for your suggestion.
>> But I still want to know why we can't set "ssl_ciphers" on the client side.
>
> I'd say because nobody implemented it, perhaps because nobody felt the need.
I think the former is a highly likely suspect here.
>> This is still considered a security issue in some cases, and PostgreSQL has
>> mature capabilities on the master side to implement this functionality.
>
> That sounds to me like some moderately clueful security auditor is looking
> for a nit to pick. If you do streaming replication, and you control the
> ciphers on the primary server, what added security benefit do you get by
> controlling the ciphers on the standby server (the client) as well?
I would place this above nitpicking, but I also don't have a clear idea of an
attack (if I did I'd fix it..). TLS is riddled with weird cases involving
network middleboxes (usually very enterprisy) so insisting on control isn't
necessarily a bad thing.
--
Daniel Gustafsson
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Sabino Mullane | 2025-08-27 22:12:48 | Re: psql --html and to_char() |
Previous Message | Dimitrios Apostolou | 2025-08-27 16:10:58 | Re: In-order pg_dump (or in-order COPY TO) |