config TLSv1.3 key exchange groups where supported

[gstrauss]

config TLSv1.3 key exchange groups where supported

The reason to explicitly configure Groups is due to OpenSSL 3.0 adding ffdhe* groups to the defaults, potentially exposing servers supporting TLSv1.3 and OpenSSL 3.0 to DHEater attacks. (See #162)

Note: .hbs additions have been made from the documentation and have not been tested on the all the server apps.
Some slight syntax adjustment may turn out to be needed.

Note: This PR exposes the TLS curves that are already defined in the guidelines. This is not a change to the guidelines. However, the curves were not previously exposed in ssl-config-generator configs. This PR implements the Groups/Curves config in server apps that have config support.

[gstrauss]

Repeating from my #270 (comment):

IANA TLS Supported Groups (see "Recommended" column in the table)
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8

The recommended groups are currently X25519:P-256:P-384:X448.
(P-256 is also known as secp256r1 and as prime256v1)
(P-384 is also known as secp384r1)
Note: different TLS libraries may recognize some of the string aliases, but might not recognize all of the string aliases.
Aside: OpenSSL, GnuTLS, mbedTLS, WolfSSL support X448; whereas NSS, BoringSSL, LibreSSL do not support X448

---

The ssl-config-generator guidelines contains X25519:prime256v1:secp384r1.

While the ssl-config-generator guidelines should consider adding X448, the current recommendations otherwise match the list of recommended IANA TLS Supported Groups.

[...]

Aside: the order of groups listed matters. X25519:prime256v1:secp384r1 is a reasonable ordering (for numerous reasons not expounded here) and matches the ordering in some existing TLS libraries, e.g. the order in mbedTLS -- though mbedTLS recognizes string secp256r1 and does not recognize prime256v1 or P-256, and mbedTLS recognizes lowercase x25519 string.

---

The following was true in 2016:

https://www.rfc-editor.org/rfc/rfc7919 (Aug 2016)

Section 8.3
[...]
Measured by computational cost to the TLS peers, ECDHE appears today
to offer a much stronger key exchange mechanism than FFDHE.

A future update of the ssl-config-generator guidelines should continue to omit ffdhe* Groups, absent new data suggesting otherwise. Even though DHE keys have sufficient security strength (if appropriately sized, e.g. minimum 2048 bits today), key exchange using elliptic curves (using smaller keys of equivalent strength to much larger DHE keys) are more CPU efficient, memory efficient, and more space efficient (smaller network packet size) than key exchange using DHE.

[gstrauss]

Almost half of the servers in ssl-config-generator do not support configuring a list of Groups/Curves in their config files:

• no config for Groups/Curves
  AWSALB, AWSELB, MySQL, OracleHTTP, Redis

• likely configurable in XML (or on command line) depending on underlying java TLS provider
  Jetty, Tomcat

• config option for single curve (recommend: prime256v1, but Squid has additional limitations)
  Coturn, Squid

Of note, configuring a curve in Squid disables DHE key exchange. It is one or the other, and the default is DHE, not EC. This is a serious limitation. If someone files a bug upstream with Squid, please reference here.

[gstrauss]

Some servers added support to configure Groups only in recent versions. Select examples (incomplete list):

• postgresql supports a single curve in ssl_ecdh_curve before postgresql 18.0.0
  postgresql 18.0.0 supports a list of curves in ssl_groups
  All Postresql versions use "prime256v1" as the default if ssl_ecdh_curve or ssl_groups is not specified
• exim 4.86+ supports a single curve in tls_eccurve, and a list of curves is supported in exim 4.97
  https://bugs.exim.org/show_bug.cgi?id=2955

[gstrauss]

In OpenSSL, very old openssl versions had an interface allowing configuration of a single curve. A comment in nginx code describes this well: https://github.com/nginx/nginx/blob/master/src/event/ngx_event_openssl.c#L1366

    /*
     * OpenSSL 1.0.2+ allows configuring a curve list instead of a single
     * curve previously supported.  By default an internal list is used,
     * with prime256v1 being preferred by server in OpenSSL 1.0.2b+
     * and X25519 in OpenSSL 1.1.0+.
     *
     * By default a curve preferred by the client will be used for
     * key exchange.  The SSL_OP_CIPHER_SERVER_PREFERENCE option can
     * be used to prefer server curves instead, similar to what it
     * does for ciphers.
     */

as does Exim https://www.exim.org/exim-pdf-current/doc/spec.pdf description of tls_eccurve (starting on page 219)

tls_eccurve Use: main Type: string Default: list
This option selects EC curves for use by Exim when used with OpenSSL. It has no effect when Exim
is used with GnuTLS (the equivalent can be done using a priority string for the tls_require_ciphers
option).
After expansion it must contain one or (only for OpenSSL versiona 1.1.1 onwards) more EC curve
names, such as prime256v1, secp384r1, or P-521. Consult your OpenSSL manual for valid
curve names.
For OpenSSL versions before (and not including) 1.0.2, the string auto selects prime256v1. For
more recent OpenSSL versions auto tells the library to choose.

[gstrauss]

boringssl and libressl do not support ffdhe key exchange with TLSv1.3.
This fails: openssl s_client -tls1_3 -groups ffdhe2048 -connect google.com:443
The same command tested on my local machine (changing google.com:443 to localhost:443) works with openssl 3.2.2, but again, does not work with boringssl or libressl.

[gstrauss]

Aside: some notes for configuring TLS in Java, specifically jdk.tls.namedGroups,
Note: not implemented in ssl-config-generator for Jetty or Tomcat

Java
https://www.java.com/en/configure_crypto.html
Disabling weak named curves by default in TLS, CertPath, and Signed JARs
...
Curves that will remain enabled are: secp256r1, secp384r1, secp521r1, X25519, and X448.
...
Adding support for the x25519 and x448 named elliptic curve groups to TLS
The named elliptic curve groups x25519 and x448 will be available for JSSE key agreement in TLS versions 1.0 to 1.3, with x25519 being the most preferred of the default enabled named groups. After this change, the default ordered list will be:
x25519, secp256r1, secp384r1, secp521r1, x448, ffdhe2048, ffdhe3072, ffdhe4096,
ffdhe6144, ffdhe8192
The default list can be overridden using the system property jdk.tls.namedGroups.

https://docs.oracle.com/en/java/javase/23/security/transport-layer-security-tls-protocol-overview.html#GUID-C6554A00-CF26-4661-991D-EA1B9EA6CCBE
https://docs.oracle.com/en/java/javase/23/security/java-secure-socket-extension-jsse-reference-guide.html#GUID-A41282C3-19A3-400A-A40F-86F4DA22ABA9

Tomcat also has option to use tcnative (Tomcat Native) library to use OpenSSL as a replacement for JSSE to support TLS connections. https://tomcat.apache.org/native-doc/

[gstrauss]

Golang has different names for Groups than OpenSSL. Instead of providing a mapping, this PR hard-codes the list of Groups in caddy.hbs, go.hbs, traefik.hbs. Caddy documents a different spelling from Go and Traefik for Groups permitted in Caddy config curves: https://caddyserver.com/docs/caddyfile/directives/tls

[gstrauss]

• openssl 1.1.1 TLSv1.3 support
• openssl 3.0.0 TLSv1.3 support with DHE key exchange using ffdhe* Groups
  (ffdhe* Groups added to openssl ssl/t1_lib.c:supported_groups_default[]
  (renamed from ssl/t1_lib.c:eccurves_default[]))
  openssl/openssl@9aaecbf
  TLS1.3 FFDHE Support openssl/openssl#8178
• Note: configuring Groups also affects TLSv1.2 kECDHE ciphers