Vdsm should not accept connections that use non-strong ciphers. No client besides Engine or another Vdsm should contact Vdsm, and these two support HIGH ciphers.
Hi Dan, not sure SPICE display connections going through vdsm (I personally doubt it), but for SPICE we probably need configurable ciphers. Current idea is to add the cipher string to the qemu process (-spice tls-ciphers ...) which should become a libvirt configurable as well. Same will be true for the protocols (still in work upstream). Default should be TLS v1.2 and only HIGH ciphers with the option to configure this in engine via some engine-config parameter. This is mainly needed as there are still (thin) clients out there, only supporting older/outdated ciphers. So as we do not want to provide weak ciphers by default, we need an option to enable them if needed (just for SPICE connections) Thanks! Martin
We now have multiple customer complaining that vdsm port 54321 is failing their security sweeps and allowing RC4 and 3DES ciphers. I will attach both cases to this BZ. We need to make this fix a priority as these customers have a very short compliance windows.
Dan, what about Apache on the Engine? I assume it's just a configuration change?
(In reply to Yaniv Kaul from comment #3) > Dan, what about Apache on the Engine? I assume it's just a configuration > change? Seems like: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/configuring-tls
(In reply to Marina from comment #5) > (In reply to Yaniv Kaul from comment #3) > > Dan, what about Apache on the Engine? I assume it's just a configuration > > change? > > Seems like: > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ > html/linux_domain_identity_authentication_and_policy_guide/configuring-tls We know what to do, but we probably need to: 1. Test with it. 2. On new installations, use it as default.
(In reply to Yaniv Kaul from comment #3) > Dan, what about Apache on the Engine? I assume it's just a configuration > change? I don't really know. Let us ask Piotr.
It looks like it is a config change [1]. We need to make sure that it works correctly. [1] https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html
(In reply to Piotr Kliczewski from comment #9) > It looks like it is a config change [1]. We need to make sure that it works > correctly. > > [1] https://httpd.apache.org/docs/trunk/ssl/ssl_howto.html Just please be aware that Apache's ssl.conf is overwritten on each engine-setup invocation, because we already adapt it as a part of engine installation/upgrade. According to [2] we should be able to set "SSLCipherSuite HIGH", but we should open a bug to do that within engine-setup (Sandro CCed on the bug). So do we want to do that performed automatically by engine-setup? [2] https://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslciphersuite
dependent 4.2.4 bugs are ON_QA, tracker can follow suit.
All dependent 4.2.4 bugs are verified
This bugzilla is included in oVirt 4.2.4 release, published on June 26th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.4 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.