Allow TLS 1.3 and use ffdhe2048 DHE group

[chris-allan]

The community ^1 has begun to notice issues connecting to servers with the 1024-bit prime used by OpenSSL 1.0.2 on RHEL 7. Specifically, errors such as dh key too small coming from newer Debian derived OpenSSL versions ^2 or DH ServerKeyExchange does not comply to algorithm constraints (https://github.com/ome/omero-blitz/pull/139#issuecomment-1653103414) from the JVM.

The reasons for this stem from crypto community research culminating in the logjam attack being detailed and following the publication of the Snowden documents suggesting that the NSA may already be exploiting 1024-bit Diffie-Hellman to decrypt VPN traffic. This work was published ^3 in late 2015 and a supplementary website ^4 was built detailing scope and exposure as well as providing mitigations and advice. This advice includes a recommendation that you generate a 2048-bit group.

To understand what "a 2048-bit group" is I recommend watching the following two YouTube videos (there are many dozens on the topic if you find them unhelpful; key search terms are "diffie hellman key exchange", "diffie hellman groups", "discrete logarithm problem"):

• https://www.youtube.com/watch?v=M-0qt6tdHzk
• https://www.youtube.com/watch?v=SL7J8hPKEWY

and follow that up by reading these two Wikipedia pages:

• https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange
• https://en.wikipedia.org/wiki/Safe_and_Sophie_Germain_primes

The key take homes are:

1. A group consists of a primitive root or generator g and a prime p
2. The group is considered public information and is exchanged in the clear, publicly with anyone who asks
3. Generating even a 2048-bit group by deriving a safe prime is computationally expensive and must be done correctly to not compromise security
4. Given [3], the exchanged group is explicitly trusted as it is computationally unreasonable for a client to check a group contains a safe prime during each TLS handshake

I expect we can all agree that the NSA is unlikely to be interested in the encrypted traffic flowing between clients and our OMERO servers so we probably don't care that we are using 1024-bit primes but we also don't want to make the security of our cryptosystem worse by using unsafe or poorly derived ones. It is also nearly 8 years on from the logjam paper and the community has done lots of great work since then.

Consequently, this PR uses the predefined ffdhe2048 group from RFC 7919 ^5 which is consistent with the work from other communities such as IKE group 14 ^6 and is already used by the JVM ^7. It also performs the long overdue work of enabling TLS 1.3 by default on all platforms other than RHEL 7 and removes support for the outdated TLS 1.0 and 1.1 protocols. Their use is already disabled by all the major web browsers ^8 and is forbidden by most organizational security policies. To fully utilize the TLS work, clients will need ome/omero-py#377 and ome/omero-blitz#139 which should be released in the next couple of months.

For people who want to use the ffdhe2048 group by performing the work by hand on existing systems I recommend:

curl https://ssl-config.mozilla.org/ffdhe2048.txt > /OMERO/certs/ffdhe2048.pem
omero config set omero.glacier2.IceSSL.DH.2048 ffdhe2048.pem

For reference:

• https://doc.zeroc.com/ice/3.6/property-reference/icessl#id-.IceSSL.*v3.6-IceSSL.DH.bits

If you are on macOS where SecureTransport is used rather than OpenSSL you will need to convert from PEM to DER format and use a different OMERO server configuration option:

openssl dhparam -in ffdhe2048.pem -out ffdhe2048.der -outform DER
omero config set omero.glacier2.IceSSL.DHParams ffdhe2048.der

For reference:

• https://doc.zeroc.com/ice/3.6/property-reference/icessl#id-.IceSSL.*v3.6-IceSSL.DHParams

Special thanks to @erickmartins, @JulianHn, and @sbesson for all the existing work surrounding this issue!

[imagesc-bot]

This pull request has been mentioned on Image.sc Forum. There might be relevant details there:

https://forum.image.sc/t/omero-login-ssl-error-dh-key/79574/17

[chris-allan]

Bonus for anyone who wants to learn more and have some fun validating ffdhe2048 or their own generated groups themselves:

• https://www.redhat.com/en/blog/understanding-and-verifying-security-diffie-hellman-parameters

[chris-allan]

Several staff are out during the beginning of August so this PR will likely not receive substantial comment or review until mid-August.

[chris-allan]

Added a warning for RHEL 7 and updated the readme. Once we've released and made a blog post or announcement about these changes I'd definitely concur with @sbesson that we should update the upgrade documentation page. I'd also recommend we add a check to the OMERO server admin plugin for the presence of TLS 1.0 and/or 1.1 legacy configuration and point to the relevant documentation just like we did for omero.db.poolsize back in omero-py 5.7.0 (ome/omero-py#218).

[sbesson]

WARNING:omero_certificates.certificates:Your Linux distribution has been detected as RHEL 7 which will reach end of life in June 2024.  TLS 1.3 cannot be enabled and upgrading is recommended.
See https://www.openmicroscopy.org/2023/07/24/linux-distributions.html for more information.
OpenSSL 1.0.2k-fips  26 Jan 2017
Generating RSA private key, 2048 bit long modulus
........................................................................................................+++
.............................................................+++
e is 65537 (0x10001)
certificates created: /OMERO/certs/server.key /OMERO/certs/server.pem /OMERO/certs/server.p12

:+1: