Bug 2228420

Summary:	Enforce EMS in Java in FIPS mode
Product:	Red Hat Enterprise Linux 9	Reporter:	Alexander Sosedkin <asosedki>
Component:	crypto-policies	Assignee:	Alexander Sosedkin <asosedki>
Status:	NEW ---	QA Contact:	BaseOS QE Security Team <qe-baseos-security>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	9.3	CC:	ahughes, fferrari
Target Milestone:	rc	Flags:	ahughes: needinfo? (fferrari)
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		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:

Description Alexander Sosedkin 2023-08-02 11:14:19 UTC

I've learned of jdk.tls.allowLegacyMasterSecret=false option's existence.

Should I set it in FIPS mode? What are the downsides?
Which of the JDK versions we ship have this option working?
Will it be simply ignored by those that don't have it working?

Comment 1 Andrew John Hughes 2023-08-03 16:48:08 UTC

I see this property is present in all currently supported JDKs (8, 11, 17).  In all three, it defaults to 'true' (i.e. a legacy master secret is allowed) and indeed, this is unchanged in trunk (future JDK 22).

I've added a NEEDINFO for more information from Francisco who works on the FIPS support. It's not clear to me from this bug why you would want to set this to false. Perhaps I'm missing some context for this bug.

It's also worth noting that this is a system property so it wouldn't currently be controlled by the crypto policies (which this bug is currently filed against). I know we added some support for the crypto policies to list system properties as well, but this is not currently utilised by the JDK support. I'm not sure adding such support is the right direction to go. It would seem preferable to allow the same options to be toggled by security properties as well. I think that might get more traction upstream than trying to override system properties.