Description of problem: Currently there is no way for customers to select/de-select which TLS versions and TLS-ciphers they wish to allow or disallow. Version-Release number of selected component (if applicable): RHV 4.2.X Additional info: This is related to work being down in the following BZs: https://bugzilla.redhat.com/show_bug.cgi?id=1562212 https://bugzilla.redhat.com/show_bug.cgi?id=1562213 https://bugzilla.redhat.com/show_bug.cgi?id=1562214
May or may not require a host redeploy - pending design decision on libvirt side. Since this setting make sense as a system-wide policy it's likely going to be a vdc_option
Should this be on a z stream milestone? If not, can you remove the flag?
removing zstream request after review with mgoldboi
we plan to make "secure" the default, and supply ansible role to push other (weak) config if required for b/w compatibility e.g. with ancient Windows
we also provide ansible role to customize the ciphers list
Verified on: ovirt-engine-4.3.0-0.0.master.20181026202125.git65125e2.el7.noarch Steps: 1. Create a yaml file in /usr/share/ovirt-engine/playbooks. - name: oVirt - setup weaker SPICE encription for old clients hosts: <HOST> vars: host_deploy_spice_cipher_string: 'DEFAULT:-RC4:-3DES:-DES' roles: - ovirt-host-deploy-spice-encryption 2. Set the host and ssh-key to use in /etc/ansible/hosts [change_tls] <HOST> ansible_ssh_private_key_file=<PATH_TO_SSH_KEY> 3. In the host, see the current (default) tls in /etc/pki/tls/spice.cnf CipherString = kECDHE+FIPS:kDHE+FIPS:kRSA+FIPS:!eNULL:!aNULL 4. Run in the engine: # ansible-playbook -l <HOST> <YAML_PATH> 5. Check again the tls in the host: # less /etc/pki/tls/spice.cnf CipherString = DEFAULT:-RC4:-3DES:-DES And there is backup file for the old cipher - spice.cnf.<DATE>.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:1085