Message-ID: <580fc76b-21ae-4ecc-a255-84eef8379161@kaltenbrunner.cc>
Date: Thu, 23 Nov 2023 21:04:01 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: Misconfiguration on SSL for download.postgresql.org ?
To: =?UTF-8?Q?Frank_B=C3=BCttner?= <frank.buettner@mdc-berlin.de>
References: <618816f6-d07a-4d1b-88ad-ef2113e463af@mdc-berlin.de>
Content-Language: en-US
From: Stefan Kaltenbrunner <stefan@kaltenbrunner.cc>
Cc: pgsql-bugs@lists.postgresql.org,
 PostgreSQL WWW <pgsql-www@lists.postgresql.org>
In-Reply-To: <618816f6-d07a-4d1b-88ad-ef2113e463af@mdc-berlin.de>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/580fc76b-21ae-4ecc-a255-84eef8379161%40kaltenbrunner.cc>
Precedence: bulk

On 11/23/23 09:21, Frank Büttner wrote:
> Hi at all,

Hi Frank!

> since some day's all our servers can't download updates for the RPM 
> packages of PostgreSQL.

the current TLS configuration has been in place for a long time now - so 
I suspect the issue started when you constrained your local TLS client 
in terms of elliptic curves...

> 
> Error:
> Errors during downloading metadata for repository 'pgdg-common':
>    - Curl error (35): SSL connect error for 
> https://download.postgresql.org/pub/repos/yum/common/redhat/rhel-9-x86_64/repodata/repomd.xml [error:0A000410:SSL routines::sslv3 alert handshake failure]
> Fehler: Failed to download metadata for repo 'pgdg-common': Cannot 
> download repomd.xml: Cannot download repodata/repomd.xml: All mirrors 
> were tried
> 
> After checking the site via nmap:
> nmap -p 443 download.postgresql.org  --script ssl-enum-ciphers
> |   TLSv1.3:
> |     ciphers:
> |       TLS_AKE_WITH_AES_256_GCM_SHA384 (secp384r1) - A
> |       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (secp384r1) - A
> |       TLS_AKE_WITH_AES_128_GCM_SHA256 (secp384r1) - A
> 
> 
> I found the problem, the "x25519" ciphers are missing.
> |   TLSv1.3:
> |     ciphers:
> |       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
> |       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
> 
> 
> Which are need on systems where the NIST curves are blocked for security 
> reasons.
> 
> 
> So please re enable the x25519 curve.

I would kinda argue that your current configuration is in direct 
violation of RFC8446(TLS 1.3) as well as 7748(elliptic curves for 
security) which explicitly state that x25519 only a SHOULD while 
supporting secp256r1 is declared a MUST and a mandatory supported key 
exchange so it seems a bit of a stretch to consider us not supporting it 
a "misconfiguration".

However we have now modified our TLS configuration to fall back to the 
embedded curves list within openssl (which among other things) enables 
x25519.


Stefan