Description of problem: HCO and SSP need to have ECDHE-ECDSA-AES128-GCM-SHA256 cipher enabled But Kubevirt needs ECDHE-RSA-AES128-GCM-SHA256 Not sure if it is by design, but personally I would think we need adhere to the same standard. Currently, we have to be sure that both of these ciphers are present, otherwise some components become non-responding Version-Release number of selected component (if applicable): 4.12 Actual results: CNV components use different ciphers Expected results: CNV components use the same cipher
I'm guessing that the severity is "high". Rationale being we should err on the safe side.
@acardace @sgott The difference in supported ciphers is due to the type of signatures the certificates have. Basically, up to tls1.2, some ciphers have the distinction based on the type of authentication used(RSA/ECDSA). The certificates used by HCO and SSP are ECDSA(https://github.com/operator-framework/operator-lifecycle-manager/blob/2a49a4dddeb3e0fc38b44925bf9bd0d3931d4ff4/pkg/controller/certs/certs.go#L31:L34), while Kubevirt uses RSA(https://github.com/kubevirt/kubevirt/blob/098332472df0b3740dc68000794a140b5d1984fc/pkg/certificates/triple/triple.go#L28:L31) certificates. Hence the difference in the exposed ciphersuite. That said, I am not sure it is a bug in this respect. Exposing both cipher types(ECDSA and RSA) on both the Kubevirt and HCO/SSP sides requires associating a new certificate per component (RSA on the HCO/SSP side, ECDSA on the Kubevirt side). From my point of view, probably the best approach will be to agree to use the same signature on all the components.
This might sound counterintuitive, but in general allowing multiple certificates can in theory make things less secure overall because it gives an attacker the option to deliberately select a cipher with a known vulnerability. Note that this is a theoretical statement only in the sense that there's currently no known vulnerability with either algorithm in general. Recent developments in quantum cryptography suggest that factoring numbers might be possible sooner than anticipated: https://www.schneier.com/blog/archives/2023/01/breaking-rsa-with-a-quantum-computer.html I suggest that it's likely a sane course of action to move KubeVirt to use ECDSA. Are there upgrade considerations to that?
Thanks, agreed! Summarizing: All the CNV components will use the ECDSA signature, resulting in enabling only the *ECDSA*subset of ciphers. Thanks
Pushed PR to use ECDSA instead of RSA https://github.com/kubevirt/kubevirt/pull/9127
I can reproduce this verify with build: CNV-v4.13.0.rhel9-1766 check all cnv components service ciphers( hco-webhook-service, kubevirt-operator-webhook, ssp-operator-service, virt-api) .... ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (secp256r1) - A test both FIPS enabled and non-FIPS, get same result. move to verified.
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 (Moderate: OpenShift Virtualization 4.13.0 Images security, bug fix, and enhancement update), 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/RHSA-2023:3205