-
Bug
-
Resolution: Unresolved
-
Minor
-
None
-
rhel-10.1
-
None
-
No
-
Low
-
rhel-security-crypto-spades
-
None
-
False
-
False
-
-
None
-
None
-
None
-
None
-
Unspecified
-
Unspecified
-
Unspecified
-
-
All
-
None
What were you trying to do that didn't work?
When we enable Brainpool without PQ support, we have the `brainpoolP256r1` keyshare to be sent in ClientHello. This is a TLS1.2 group, so the client finds it invalid and sends an empty keyshare (https://github.com/openssl/openssl/issues/28281), and then the server aboards. With the latest OpenSSL change (https://github.com/openssl/openssl/pull/28283), the client will abort right away.
TSL1.2 doesn't support keyshare, so we just need to move the asterisk to `brainpoolP256r1tls13`.
What is the impact of this issue on you?
low
Please provide the package NVR for which the bug is seen:
crypto-policies-20250804-1.git2ca4115.el10.noarch
How reproducible is this bug?:
always
Steps to reproduce
- create BRAINPOOL-FIRST subpolicy
$ echo "group = +BRAINPOOL*" > /etc/crypto-policies/policies/modules/BRAINPOOL-FIRST.pmod $ echo "sign = +*BRAINPOOL*" >> /etc/crypto-policies/policies/modules/BRAINPOOL-FIRST.pmod
- Apply the policy without any PQ on it
update-crypto-policies --no-reload --set DEFAULT:BRAINPOOL-FIRST:NO-PQ
- See the OpenSSL backend config
cat /etc/crypto-policies/back-ends/opensslcnf.config
Expected results
Asterisk will be on the TLS-1.3 group (`brainpoolP256r1tls13`)
Actual results
Asterisk is on the TLS-1.2 group (`brainpoolP256r1`)
- is cloned by
-
RHEL-116227 Wrong group in keyshares when adding brainpool support in openSSL.
-
- Planning
-