Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uqo62-00DSEF-Nv for pgsql-general@arkaria.postgresql.org; Tue, 26 Aug 2025 07:28:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uqo62-002TwU-5T for pgsql-general@arkaria.postgresql.org; Tue, 26 Aug 2025 07:27:58 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uqo61-002TtL-RJ for pgsql-general@lists.postgresql.org; Tue, 26 Aug 2025 07:27:58 +0000 Received: from mail-ej1-x643.google.com ([2a00:1450:4864:20::643]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uqo5y-001nfB-2A for pgsql-general@lists.postgresql.org; Tue, 26 Aug 2025 07:27:57 +0000 Received: by mail-ej1-x643.google.com with SMTP id a640c23a62f3a-afcb7347e09so899581866b.0 for ; Tue, 26 Aug 2025 00:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1756193273; x=1756798073; darn=lists.postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=eH8RpfHBVAJUE0SUGjGaS36cEpftUPhJ3EFFq2vrIzU=; b=LkVJWTAWfOby68YCFovnWUO9LT4NzYwJ8YjgUvHKB3tjEpU73R1cvL+7xVN6Chrtuw Ey4Phk/jaQr704ByhKzaKqKvRvVDNYshu5q8UDWrn4eLzCBPUuvNflbVVqLSv74RHdsQ xIvIXJCTA5b61QaWEAf6TphK+gXIYh1D+E+IOBHWXCHcuQZcyuuOcMGeyK+SXZer1qPF z7GnYzjNsoNnlvR5elIQYyjVZe8jV1NJ5N6zfktpnFLZknnyOn9/29C9KaWBgt6kdoPR Lss8WUEnUekbs7psE4UHBXG05vh+0hQyZstcKlGM5fDtyvA+/yos+ZvtxsAEVLspkMh/ 0AlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1756193273; x=1756798073; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=eH8RpfHBVAJUE0SUGjGaS36cEpftUPhJ3EFFq2vrIzU=; b=LS1A6KDMsUcHTSUWwZKA48I1rHRG3cxN8BQPuhyy5+2Lz8wCtkeBHraH5TCydhzDr1 CzzmJmXJbsDYyjjhavuPiMxZ4rdAPXC1VCocGC2EHArO7H+3G1KpCFKu/4conn2pBgVQ WEuG1usdj1Bl2Zfi+C5jAeAbXpNHypXnAX0sdQ5ZHpuyLS209/ZWDLGWgC1LEtzWk7Pb 7N9m0y6SiSVqADnTzihTFlacnVIIzxtd4ZCDR98yktlHZhDyhVSsUaEPhnRqemcr0bPw xE/YUgrM/unD/OQHMxQq6uNi1earwUwop/tm4ixabbC9AxrVHtwaRUiSjvaNxZvpYDRn /pSw== X-Gm-Message-State: AOJu0Yxkc0lUz1PjIcD1B/Obypib5/3ztR2/FQnjrAIQZHMpomfg5A2m 8xYOb/Jx1dMqZEiPB+kcnpsxuyTEMq8EMfASUO756Pwf7KlqKMRSVjW1xrdMSZxCjhI4oZosz8z cJmHRcL71+0I7a1bdJ2l1ySBk6Mz5jNnb+EqC0LXiZA== X-Gm-Gg: ASbGnctxdR5CzLK1oJ3Jy/Kj/zMGXve3luvo51ncQ4tdt2/3hEIQS7hT3kLGeSos9uZ KozD0af3Ed0bG4xG4wPMlDaSFX2gspSWWxsEzKCS9UiijRHMfek/Dx5FYgHSykD7waXKc3CrP1h lzh6329ljPgKbP2DZwiP5GWi5Dyzyay79sLOVVqzH7+OJNublVMuuLAh1lMVEimJFHs/Y+fSEOO R5fVq1d X-Google-Smtp-Source: AGHT+IGwFfrvg+HS1gaIUj426zHWohfb/2s16xw77qB7hWXn6Yr4d3cKREzVpR8w8T8x4/pHGobqMW7fUJO0tBfn2iE= X-Received: by 2002:a17:907:6e92:b0:afd:d9e8:47b with SMTP id a640c23a62f3a-afe296e50d5mr1113905266b.64.1756193272788; Tue, 26 Aug 2025 00:27:52 -0700 (PDT) MIME-Version: 1.0 From: xx Z Date: Tue, 26 Aug 2025 15:27:40 +0800 X-Gm-Features: Ac12FXy3DAtaf6sbXgF7yHmWf1dk2SWmzHSS3Tjj_jkuoiZxOxV5xlXLy12B_7E Message-ID: Subject: Feature request: A method to configure client-side TLS ciphers for streaming replication To: pgsql-general@lists.postgresql.org Content-Type: multipart/alternative; boundary="0000000000002e7ea9063d3f9c1c" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002e7ea9063d3f9c1c Content-Type: text/plain; charset="UTF-8" Hello PostgreSQL community, I have a question regarding the configuration of streaming replication. When setting up streaming replication over TLS, I've noticed that while the primary server can restrict its supported encryption algorithms using the ssl_ciphers parameter, there doesn't seem to be a corresponding method for the standby (client) side of the replication connection. The standby appears to use all the default ciphers supported by the system's OpenSSL library. For security compliance, we need to restrict the ciphers used by the client. Is there a way to configure the list of supported TLS ciphers on the standby for the replication connection? If this functionality does not currently exist, I would like to request it as a new feature. It would be very helpful to have a connection parameter in primary_conninfo to specify the client-side cipher list. Postgresql version: 15.2 Thank you for your time and consideration. Best regards, Yunfei Zhou --0000000000002e7ea9063d3f9c1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello PostgreSQL community,

I = have a question regarding the configuration of streaming replication.
=

When setting up streaming rep= lication over TLS, I've noticed that while the primary server can restr= ict its supported encryption algorithms using the ssl_ciphers parameter, th= ere doesn't seem to be a corresponding method for the standby (client) = side of the replication connection. The standby appears to use all the defa= ult ciphers supported by the system's OpenSSL library.

For security compliance, we need to rest= rict the ciphers used by the client. Is there a way to configure the list o= f supported TLS ciphers on the standby for the replication connection?

If this functionality does n= ot currently exist, I would like to request it as a new feature. It would b= e very helpful to have a connection parameter in primary_conninfo to specif= y the client-side cipher list.

Postgresql version: 15.2

Thank you for your time and consideration.

Best regards,

Yunfei Zhou
--0000000000002e7ea9063d3f9c1c--