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::sslv3alert 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
