search

ome / omero-certificates

OMERO server certificate management plugin
https://www.openmicroscopy.org/omero
GNU General Public License v2.0
0 stars 7 forks source link

Existing configuration properties may need to be overwritten. Document or add option. #3

Open manics opened 4 years ago

manics commented 4 years ago

See https://forum.image.sc/t/omero-icessl-unable-to-set-ciphers/30704/33

In this case omero.glacier2.IceSSL.Ciphers=HIGH:ADH:@SECLEVEL=0 had been previously set but was causing problems. This plugin avoids overwriting existing config with omero.glacier2.IceSSL.Ciphers=HIGH.

We should either document this or add an --overwrite option

joshmoore commented 4 years ago

I'd vote for failing if there's a conflict and using -f/--force to overwrite like bin/omero config load.

manics commented 4 years ago

We definitely shouldn't fail. There are many reasons to want to change the defaults, for example to use a stricter minimum TLS version, or limiting ciphers by name instead of just HIGH.

joshmoore commented 4 years ago

Yes, but the user should know that something is being overwritten, e.g.:

ERROR: properties already set:

  omero.glacier2.IceSSL.Ciphers=HIGH:ADH:@SECLEVEL=0

Re-run with `omero certificates -f` to overwrite.
chris-allan commented 2 years ago

I know this issue is two years old now but in working with @sbesson on #26 and #27 along with ome/omero-py#336 I think we've established that having this plugin set HIGH is effectively a no-op. We've had SSLv3 disabled in the default configuration for nearly 8 years; since ome/openmicroscopy@ae8e10a66cbcb006083c5936265391d0bfb207c9 (released in OMERO 5.0.6 to address 2014-SV4).

The oldest version of OpenSSL shipping on a platform we still support is 1.0.2k on CentOS 7. Dropping all the SSLv3 ciphers gives us the following diff:

$ cat /etc/redhat-release
CentOS Linux release 7.9.2009 (Core)
$ openssl version
OpenSSL 1.0.2k-fips  26 Jan 2017
$ diff -Nau <(openssl ciphers -v 'DEFAULT:!SSLv3' | sort) <(openssl ciphers -v 'HIGH:!SSLv3' | sort)
--- /dev/fd/63  2022-10-13 08:44:07.455325526 +0000
+++ /dev/fd/62  2022-10-13 08:44:07.455325526 +0000
@@ -1,3 +1,7 @@
+ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
+ADH-AES128-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
+ADH-AES256-GCM-SHA384   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(256) Mac=AEAD
+ADH-AES256-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(256)  Mac=SHA256
 AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
 AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
 AES256-GCM-SHA384       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(256) Mac=AEAD

Since one of the fundamental results of running omero certificates is making RSA keys available for the Elliptic Curve Diffie Hellman, Diffie Hellman, or RSA key exchange algorithms I don't see a reason for us to be complicating our lives setting omero.glacier2.IceSSL.Ciphers=HIGH; that's in the spirit of ome/omero-py#336. On newer versions of OpenSSL HIGH can add cryptographically questionable ciphers.

I'd propose we close this issue. On #26 I'll add a set of changes that I think we should make before moving the functionality of this repository up into omero-py.