Bug 2139235

Summary:	unlike other CNV components, Kubevirt uses its own cipher for tls 1.2
Product:	Container Native Virtualization (CNV)	Reporter:	Denys Shchedrivyi <dshchedr>
Component:	Virtualization	Assignee:	ffossemo
Status:	CLOSED ERRATA	QA Contact:	zhe peng <zpeng>
Severity:	high	Docs Contact:
Priority:	high
Version:	4.12.0	CC:	acardace, sgott, zpeng
Target Milestone:	---
Target Release:	4.13.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	hco-bundle-registry-container-v4.13.0.rhel9-1689	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	2153527 (view as bug list)		Environment:
Last Closed:	2023-05-18 02:55:41 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2153527

Description Denys Shchedrivyi 2022-11-01 22:45:27 UTC

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

Comment 1 sgott 2022-11-02 12:14:15 UTC

I'm guessing that the severity is "high". Rationale being we should err on the safe side.

Comment 3 ffossemo 2023-01-25 14:36:24 UTC

@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.

Comment 4 sgott 2023-01-30 18:32:20 UTC

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?

Comment 5 ffossemo 2023-01-31 11:03:30 UTC

Thanks, agreed! Summarizing:
All the CNV components will use the ECDSA signature, resulting in enabling only the *ECDSA*subset of ciphers.
Thanks

Comment 6 ffossemo 2023-02-09 16:09:21 UTC

Pushed PR to use ECDSA instead of RSA https://github.com/kubevirt/kubevirt/pull/9127

Comment 7 zhe peng 2023-03-23 09:35:36 UTC

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.

Comment 10 errata-xmlrpc 2023-05-18 02:55:41 UTC

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