Uploaded image for project: 'RHEL'
  1. RHEL
  2. RHEL-7724

Connect pcsd TLS configuration to RHEL crypto policies

XMLWordPrintable

    • pcs-0.11.6-6.el9
    • None
    • Moderate
    • rhel-sst-high-availability
    • ssg_filesystems_storage_and_HA
    • 13
    • 19
    • 3
    • QE ack
    • False
    • Hide

      None

      Show
      None
    • Yes
    • None
    • Enhancement
    • Hide
      .TLS cipher list now defaults to system-wide crypto policy

      Previously, the `pcsd` TLS cipher list was set to `DEFAULT:!RC4:!3DES:@STRENGTH` by default. With this update, the cipher list is defined by the system-wide crypto policy by default. The TLS ciphers accepted by the `pcsd` daemon might change with this upgrade, depending on the currently set crypto policy. For more information about the crypto policies framework, see the `crypto-policies`(7) man page.
      Show
      .TLS cipher list now defaults to system-wide crypto policy Previously, the `pcsd` TLS cipher list was set to `DEFAULT:!RC4:!3DES:@STRENGTH` by default. With this update, the cipher list is defined by the system-wide crypto policy by default. The TLS ciphers accepted by the `pcsd` daemon might change with this upgrade, depending on the currently set crypto policy. For more information about the crypto policies framework, see the `crypto-policies`(7) man page.
    • Done
    • None

      Description of problem:
      Currently, it is possible to configure TLS ciphers and other options used by pcsd in /etc/sysconfig/pcsd. There is a default value hardcoded in pcsd source. RHEL (and Fedora) provides a system-wide crypto policies framework, which allows to configure TLS settings in one place for the entire OS and all applications. This has a benefit of easy management, when disabling a weak cipher can be done in a single place. Pcsd should connect to this framework.

      Version-Release number of selected component (if applicable):
      pcs-0.11.7

      How reproducible:
      always, easily

      Steps to Reproduce:
      1. update-crypto-policies --set DEFAULT
      2. nmap -p 2224

      {pcsd node} --script +ssl-enum-ciphers
      3. update-crypto-policies --set FIPS
      4. nmap -p 2224 {pcsd node}

      --script +ssl-enum-ciphers

      Actual results:
      TLS ciphers used by pcsd do not depend on the current crypto policy

      Expected results:
      TLS ciphers used by pcsd are set by the current crypto policy

      Additional info:
      nmap-7.91-12.el9 doesn't show TLSv1.3, use nmap-7.93-2.fc38

      Proposed solution:
      Make 'PROFILE=SYSTEM' the default for PCSD_SSL_CIPHERS

            [RHEL-7724] Connect pcsd TLS configuration to RHEL crypto policies

            Errata Tool added a comment -

            Since the problem described in this issue should be resolved in a recent advisory, it has been closed.

            For information on the advisory (Moderate: pcs security 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-2024:2113

            Errata Tool added a comment - Since the problem described in this issue should be resolved in a recent advisory, it has been closed. For information on the advisory (Moderate: pcs security 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-2024:2113

            Steven Levine added a comment -

            Making very slight editorial change in the release note following a peer review. (IBM style uses "might" instead of "may", "by default" moved to the end of sentences which avoids breaking up a phrase – a small thing, but I'll go with the suggestion from the reviewer.)

            Steven Levine added a comment - Making very slight editorial change in the release note following a peer review. (IBM style uses "might" instead of "may", "by default" moved to the end of sentences which avoids breaking up a phrase – a small thing, but I'll go with the suggestion from the reviewer.)

            Gabriela Fialova added a comment -

            Release Note Type changed to Enhancement in order to fix the Release Notes build in Pantheon.

            Gabriela Fialova added a comment - Release Note Type changed to Enhancement in order to fix the Release Notes build in Pantheon.

            Tomas Jelinek added a comment -

            slevine@redhat.com :

            TLS cipher list now defaults to system-wide crypto policy
            Previously the `pcsd` TLS cipher list by default was set to 'DEFAULT:!RC4:!3DES:@STRENGTH'. With this update, the cipher list is by default defined by the system-wide crypto policy. The TLS ciphers accepted by the `pcsd` daemon may change with this upgrade, depending on the currently set crypto policy. For more information about the crypto policies framework, see the crypto-policies(7) man page.

            Looks good to me. If I had to choose between the two, I would say this is an enhancement.

            Tomas Jelinek added a comment - slevine@redhat.com : TLS cipher list now defaults to system-wide crypto policy Previously the `pcsd` TLS cipher list by default was set to 'DEFAULT:!RC4:!3DES:@STRENGTH'. With this update, the cipher list is by default defined by the system-wide crypto policy. The TLS ciphers accepted by the `pcsd` daemon may change with this upgrade, depending on the currently set crypto policy. For more information about the crypto policies framework, see the crypto-policies(7) man page. Looks good to me. If I had to choose between the two, I would say this is an enhancement.

            Steven Levine added a comment -

            tojeline@redhat.com: This is my suggestion for a release note. Is this really a bug fix, or would you consider it an enhancement?

            TLS cipher list now defaults to system-wide crypto policy

            Previously the `pcsd` TLS cipher list by default was set to 'DEFAULT:!RC4:!3DES:@STRENGTH'. With this update, the cipher list is by default defined by the system-wide crypto policy. The TLS ciphers accepted by the `pcsd` daemon may change with this upgrade, depending on the currently set crypto policy. For more information about the crypto policies framework, see the crypto-policies(7) man page.

            Steven Levine added a comment - tojeline@redhat.com : This is my suggestion for a release note. Is this really a bug fix, or would you consider it an enhancement? TLS cipher list now defaults to system-wide crypto policy Previously the `pcsd` TLS cipher list by default was set to 'DEFAULT:!RC4:!3DES:@STRENGTH'. With this update, the cipher list is by default defined by the system-wide crypto policy. The TLS ciphers accepted by the `pcsd` daemon may change with this upgrade, depending on the currently set crypto policy. For more information about the crypto policies framework, see the crypto-policies(7) man page.

            Michal Mazourek added a comment -

            AFTER FIX:

            [root@virt-032 ~]# rpm -q pcs
pcs-0.11.6-6.el9.x86_64 

             

            Checking current crypto policy

            [root@virt-032 ~]# update-crypto-policies --show
FIPS

             

            Using nmap from different machine to initiates TLS connections on pcsd port and scan which ciphers are accepted.

            [root@virt-033 ~]# nmap -p 2224 virt-032 --script +ssl-enum-ciphers
Starting Nmap 7.92 ( https://nmap.org ) at 2023-12-13 16:40 CET
Nmap scan report for virt-032 (10.37.166.159)
Host is up (0.00050s latency).
Other addresses for virt-032 (not scanned): 2620:52:0:25a4:1800:ff:fe00:20
rDNS record for 10.37.166.159: virt-032.cluster-qe.lab.eng.brq.redhat.com
PORT     STATE SERVICE
2224/tcp open  efi-mg
| ssl-enum-ciphers: 
|   TLSv1.3: 
|     ciphers: 
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_AKE_WITH_AES_128_CCM_SHA256 (secp256r1) - A
|     cipher preference: server
|_  least strength: A
MAC Address: 1A:00:00:00:00:20 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 6.87 seconds

             

            Changing current crypto policy to DEFAULT

            [root@virt-032 ~]# update-crypto-policies --set DEFAULT
Warning: Using 'update-crypto-policies --set' in FIPS mode will make the system
         non-compliant with FIPS.
         It can also break the ssh access to the system.
         Use 'fips-mode-setup --disable' to disable the system FIPS mode.
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
[root@virt-032 ~]# echo $?
0

            > As the warning message hints, FIPS need to be disabled to preserve ssh connection

             

            [root@virt-032 ~]# fips-mode-setup --check
FIPS mode is enabled.
The current crypto policy (DEFAULT) neither is the FIPS policy nor is based on the FIPS policy.
Inconsistent state detected.
[root@virt-032 ~]# fips-mode-setup --disable
Kernel initramdisks are being regenerated. This might take some time.
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
FIPS mode will be disabled.
Please reboot the system for the setting to take effect.
[root@virt-032 ~]# echo $?
0
[root@virt-032 ~]# reboot
 

            Checking changed crypto policy

            [root@virt-032 ~]# update-crypto-policies --show
DEFAULT

             

            Using nmap from different machine to initiates TLS connections on pcsd port and scan which ciphers are accepted.

            [root@virt-033 ~]# nmap -p 2224 virt-032 --script +ssl-enum-ciphers
Starting Nmap 7.92 ( https://nmap.org ) at 2023-12-13 16:50 CET
Nmap scan report for virt-032 (10.37.166.159)
Host is up (0.00065s latency).
Other addresses for virt-032 (not scanned): 2620:52:0:25a4:1800:ff:fe00:20
rDNS record for 10.37.166.159: virt-032.cluster-qe.lab.eng.brq.redhat.com
PORT     STATE SERVICE
2224/tcp open  efi-mg
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CCM (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_CCM (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.3: 
|     ciphers: 
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_CCM_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A
MAC Address: 1A:00:00:00:00:20 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 6.91 seconds
 

            > OK: Many more accepted ciphers are now visible without FIPS policy while scanning pcsd port. Pcsd automatically connected to the system-wide crypto policies framework, without any manual manipulation with pcs or pcsd config.

             

            Trying another crypto policy and checking, if pcsd reacts to it

            [root@virt-032 ~]# update-crypto-policies --set FUTURE
Setting system policy to FUTURE
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
[root@virt-032 ~]# echo $?
0
[root@virt-032 ~]# reboot
[root@virt-032 ~]# update-crypto-policies --show
FUTURE
[root@virt-033 ~]# nmap -p 2224 virt-032 --script +ssl-enum-ciphers
Starting Nmap 7.92 ( https://nmap.org ) at 2023-12-13 17:37 CET
Nmap scan report for virt-032 (10.37.166.159)
Host is up (0.00034s latency).
Other addresses for virt-032 (not scanned): 2620:52:0:25a4:1800:ff:fe00:20
rDNS record for 10.37.166.159: virt-032.cluster-qe.lab.eng.brq.redhat.com
PORT     STATE SERVICE
2224/tcp open  efi-mg
| ssl-enum-ciphers: 
|   TLSv1.2: 
|     ciphers: 
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     compressors: 
|       NULL
|     cipher preference: server
|   TLSv1.3: 
|     ciphers: 
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A
MAC Address: 1A:00:00:00:00:20 (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 6.88 seconds

            > OK: pcsd reacted to the changed crypto policies, allowed ciphers with FUTURE policy differ from the FIPS and DEFAULT policies.

             

            [root@virt-032 ~]# cat /etc/sysconfig/pcsd | grep PROFILE=SYSTEM -B 2
# In case you are running a system with crypto-policies (such as RHEL, CentOS
# Stream or Fedora), you can set pcsd to use the configured policy:
#PCSD_SSL_CIPHERS='PROFILE=SYSTEM'

            > OK: The behavior is mentioned in the pcsd config

             

            Verified for pcs-0.11.6-6.el9.

            Michal Mazourek added a comment - AFTER FIX: [root@virt-032 ~]# rpm -q pcs pcs-0.11.6-6.el9.x86_64    Checking current crypto policy [root@virt-032 ~]# update-crypto-policies --show FIPS   Using nmap from different machine to initiates TLS connections on pcsd port and scan which ciphers are accepted. [root@virt-033 ~]# nmap -p 2224 virt-032 --script +ssl- enum -ciphers Starting Nmap 7.92 ( https: //nmap.org ) at 2023-12-13 16:40 CET Nmap scan report for virt-032 (10.37.166.159) Host is up (0.00050s latency). Other addresses for virt-032 (not scanned): 2620:52:0:25a4:1800:ff:fe00:20 rDNS record for 10.37.166.159: virt-032.cluster-qe.lab.eng.brq.redhat.com PORT     STATE SERVICE 2224/tcp open  efi-mg | ssl- enum -ciphers:  |   TLSv1.3:  |     ciphers:  |       TLS_AKE_WITH_AES_256_GCM_SHA384 (secp256r1) - A |       TLS_AKE_WITH_AES_128_GCM_SHA256 (secp256r1) - A |       TLS_AKE_WITH_AES_128_CCM_SHA256 (secp256r1) - A |     cipher preference: server |_  least strength: A MAC Address: 1A:00:00:00:00:20 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 6.87 seconds   Changing current crypto policy to DEFAULT [root@virt-032 ~]# update-crypto-policies --set DEFAULT Warning: Using 'update-crypto-policies --set' in FIPS mode will make the system          non-compliant with FIPS.          It can also break the ssh access to the system.          Use 'fips-mode-setup --disable' to disable the system FIPS mode. Setting system policy to DEFAULT Note: System -wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. [root@virt-032 ~]# echo $? 0 > As the warning message hints, FIPS need to be disabled to preserve ssh connection   [root@virt-032 ~]# fips-mode-setup --check FIPS mode is enabled. The current crypto policy (DEFAULT) neither is the FIPS policy nor is based on the FIPS policy. Inconsistent state detected. [root@virt-032 ~]# fips-mode-setup --disable Kernel initramdisks are being regenerated. This might take some time. Setting system policy to DEFAULT Note: System -wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. FIPS mode will be disabled. Please reboot the system for the setting to take effect. [root@virt-032 ~]# echo $? 0 [root@virt-032 ~]# reboot   Checking changed crypto policy [root@virt-032 ~]# update-crypto-policies --show DEFAULT   Using nmap from different machine to initiates TLS connections on pcsd port and scan which ciphers are accepted. [root@virt-033 ~]# nmap -p 2224 virt-032 --script +ssl- enum -ciphers Starting Nmap 7.92 ( https: //nmap.org ) at 2023-12-13 16:50 CET Nmap scan report for virt-032 (10.37.166.159) Host is up (0.00065s latency). Other addresses for virt-032 (not scanned): 2620:52:0:25a4:1800:ff:fe00:20 rDNS record for 10.37.166.159: virt-032.cluster-qe.lab.eng.brq.redhat.com PORT     STATE SERVICE 2224/tcp open  efi-mg | ssl- enum -ciphers:  |   TLSv1.2:  |     ciphers:  |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A |       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A |       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A |       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A |       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 3072) - A |       TLS_RSA_WITH_AES_256_CCM (rsa 3072) - A |       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 3072) - A |       TLS_RSA_WITH_AES_128_CCM (rsa 3072) - A |       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 3072) - A |       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 3072) - A |       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A |       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A |     compressors:  |       NULL |     cipher preference: server |   TLSv1.3:  |     ciphers:  |       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A |       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A |       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A |       TLS_AKE_WITH_AES_128_CCM_SHA256 (ecdh_x25519) - A |     cipher preference: server |_  least strength: A MAC Address: 1A:00:00:00:00:20 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 6.91 seconds   > OK: Many more accepted ciphers are now visible without FIPS policy while scanning pcsd port. Pcsd automatically connected to the system-wide crypto policies framework, without any manual manipulation with pcs or pcsd config.   Trying another crypto policy and checking, if pcsd reacts to it [root@virt-032 ~]# update-crypto-policies --set FUTURE Setting system policy to FUTURE Note: System -wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. [root@virt-032 ~]# echo $? 0 [root@virt-032 ~]# reboot [root@virt-032 ~]# update-crypto-policies --show FUTURE [root@virt-033 ~]# nmap -p 2224 virt-032 --script +ssl- enum -ciphers Starting Nmap 7.92 ( https: //nmap.org ) at 2023-12-13 17:37 CET Nmap scan report for virt-032 (10.37.166.159) Host is up (0.00034s latency). Other addresses for virt-032 (not scanned): 2620:52:0:25a4:1800:ff:fe00:20 rDNS record for 10.37.166.159: virt-032.cluster-qe.lab.eng.brq.redhat.com PORT     STATE SERVICE 2224/tcp open  efi-mg | ssl- enum -ciphers:  |   TLSv1.2:  |     ciphers:  |       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A |       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A |     compressors:  |       NULL |     cipher preference: server |   TLSv1.3:  |     ciphers:  |       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A |       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A |     cipher preference: server |_  least strength: A MAC Address: 1A:00:00:00:00:20 (Unknown) Nmap done: 1 IP address (1 host up) scanned in 6.88 seconds > OK: pcsd reacted to the changed crypto policies, allowed ciphers with FUTURE policy differ from the FIPS and DEFAULT policies.   [root@virt-032 ~]# cat /etc/sysconfig/pcsd | grep PROFILE=SYSTEM -B 2 # In case you are running a system with crypto-policies (such as RHEL, CentOS # Stream or Fedora), you can set pcsd to use the configured policy: #PCSD_SSL_CIPHERS= 'PROFILE=SYSTEM' > OK: The behavior is mentioned in the pcsd config   Verified for pcs-0.11.6-6.el9.

            Michal Pospisil added a comment -

            DevTestResults:

            In retrospect, the steps in this test could be reversed to save time if the tested OS is in FIPS mode at the start of the test. The same result could be obtained by scanning in the FIPS mode first and then turning it off and doing the second scan.

            Important! Just changing the crypto policies without running fips-mode-setup made my VM stop accepting my SSH connections after a reboot. It also didn't produce a different cipher list in the scan. The test was adjusted to use a more standard procedure of enabling/disabling FIPS which also changes crypto policies and didn't have these issues.

            Executing the test on r09-04-a.vm where RHEL was installed in FIPS mode. Pcsd is enabled on startup. Disable FIPS (crypto policy set to DEFAULT):

            [root@r09-04-a ~]# rpm -q pcs
pcs-0.11.6-6.el9.x86_64

[root@r09-04-a ~]# fips-mode-setup --disable
Setting system policy to DEFAULT
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
FIPS mode will be disabled.
Please reboot the system for the setting to take effect.

[root@r09-04-a ~]# reboot

            Scanning supported ciphers on pcsd port from another VM:

            [root@build-f38-2 ~]# nmap -p 2224 r09-04-a.vm --script +ssl-enum-ciphers
Starting Nmap 7.93 ( https://nmap.org ) at 2023-11-23 12:34 CET
Nmap scan report for r09-04-a.vm (192.168.123.36)
Host is up (0.00060s latency).

PORT     STATE SERVICE
2224/tcp open  efi-mg
| ssl-enum-ciphers:  
|   TLSv1.2:  
|     ciphers:  
|       TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A
|       TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A
|       TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CCM (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_CCM (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 3072) - A
|       TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A
|       TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A
|     compressors:  
|       NULL
|     cipher preference: server
|   TLSv1.3:  
|     ciphers:  
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
|       TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
|       TLS_AKE_WITH_AES_128_CCM_SHA256 (ecdh_x25519) - A
|     cipher preference: server
|_  least strength: A
MAC Address: 52:54:00:90:01:23 (QEMU virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds

            Turn FIPS on again on r09-04-a.vm (crypto policy set to FIPS):

            [root@r09-04-a ~]# fips-mode-setup --enable
Setting system policy to FIPS
Note: System-wide crypto policies are applied on application start-up.
It is recommended to restart the system for the change of policies
to fully take place.
FIPS mode will be enabled.
Please reboot the system for the setting to take effect.

[root@r09-04-a ~]# reboot

            Scanning supported ciphers on pcsd port from another VM:

            [root@build-f38-2 ~]# nmap -p 2224 r09-04-a.vm --script +ssl-enum-ciphers
Starting Nmap 7.93 ( https://nmap.org ) at 2023-11-23 12:41 CET
Nmap scan report for r09-04-a.vm (192.168.123.36)
Host is up (0.00020s latency).

PORT     STATE SERVICE
2224/tcp open  efi-mg
| ssl-enum-ciphers:  
|   TLSv1.3:  
|     ciphers:  
|       TLS_AKE_WITH_AES_256_GCM_SHA384 (secp256r1) - A
|       TLS_AKE_WITH_AES_128_GCM_SHA256 (secp256r1) - A
|       TLS_AKE_WITH_AES_128_CCM_SHA256 (secp256r1) - A
|     cipher preference: server
|_  least strength: A
MAC Address: 52:54:00:90:01:23 (QEMU virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 0.51 seconds

            Michal Pospisil added a comment - DevTestResults: In retrospect, the steps in this test could be reversed to save time if the tested OS is in FIPS mode at the start of the test. The same result could be obtained by scanning in the FIPS mode first and then turning it off and doing the second scan. Important! Just changing the crypto policies without running fips-mode-setup made my VM stop accepting my SSH connections after a reboot. It also didn't produce a different cipher list in the scan. The test was adjusted to use a more standard procedure of enabling/disabling FIPS which also changes crypto policies and didn't have these issues. Executing the test on r09-04-a.vm where RHEL was installed in FIPS mode. Pcsd is enabled on startup. Disable FIPS (crypto policy set to DEFAULT): [root@r09-04-a ~]# rpm -q pcs pcs-0.11.6-6.el9.x86_64 [root@r09-04-a ~]# fips-mode-setup --disable Setting system policy to DEFAULT Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. FIPS mode will be disabled. Please reboot the system for the setting to take effect. [root@r09-04-a ~]# reboot Scanning supported ciphers on pcsd port from another VM: [root@build-f38-2 ~]# nmap -p 2224 r09-04-a.vm --script +ssl-enum-ciphers Starting Nmap 7.93 ( https://nmap.org ) at 2023-11-23 12:34 CET Nmap scan report for r09-04-a.vm (192.168.123.36) Host is up (0.00060s latency). PORT STATE SERVICE 2224/tcp open efi-mg | ssl-enum-ciphers: | TLSv1.2: | ciphers: | TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (ecdh_x25519) - A | TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (ecdh_x25519) - A | TLS_RSA_WITH_AES_256_GCM_SHA384 (rsa 3072) - A | TLS_RSA_WITH_AES_256_CCM (rsa 3072) - A | TLS_RSA_WITH_AES_128_GCM_SHA256 (rsa 3072) - A | TLS_RSA_WITH_AES_128_CCM (rsa 3072) - A | TLS_RSA_WITH_AES_256_CBC_SHA256 (rsa 3072) - A | TLS_RSA_WITH_AES_128_CBC_SHA256 (rsa 3072) - A | TLS_RSA_WITH_AES_256_CBC_SHA (rsa 3072) - A | TLS_RSA_WITH_AES_128_CBC_SHA (rsa 3072) - A | compressors: | NULL | cipher preference: server | TLSv1.3: | ciphers: | TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A | TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A | TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A | TLS_AKE_WITH_AES_128_CCM_SHA256 (ecdh_x25519) - A | cipher preference: server |_ least strength: A MAC Address: 52:54:00:90:01:23 (QEMU virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.59 seconds Turn FIPS on again on r09-04-a.vm (crypto policy set to FIPS): [root@r09-04-a ~]# fips-mode-setup --enable Setting system policy to FIPS Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place. FIPS mode will be enabled. Please reboot the system for the setting to take effect. [root@r09-04-a ~]# reboot Scanning supported ciphers on pcsd port from another VM: [root@build-f38-2 ~]# nmap -p 2224 r09-04-a.vm --script +ssl-enum-ciphers Starting Nmap 7.93 ( https://nmap.org ) at 2023-11-23 12:41 CET Nmap scan report for r09-04-a.vm (192.168.123.36) Host is up (0.00020s latency). PORT STATE SERVICE 2224/tcp open efi-mg | ssl-enum-ciphers: | TLSv1.3: | ciphers: | TLS_AKE_WITH_AES_256_GCM_SHA384 (secp256r1) - A | TLS_AKE_WITH_AES_128_GCM_SHA256 (secp256r1) - A | TLS_AKE_WITH_AES_128_CCM_SHA256 (secp256r1) - A | cipher preference: server |_ least strength: A MAC Address: 52:54:00:90:01:23 (QEMU virtual NIC) Nmap done: 1 IP address (1 host up) scanned in 0.51 seconds

            gitlab-bot added a comment -

            Michal Pospíšil mentioned this issue in a merge request of Red Hat / centos-stream / rpms / pcs on branch 9.4-pre3:

            pcs-0.11.6-6

            gitlab-bot added a comment - Michal Pospíšil mentioned this issue in a merge request of Red Hat / centos-stream / rpms / pcs on branch 9.4-pre3 : pcs-0.11.6-6

            pm-rhel added a comment -

            This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

            Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

            To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

            "Bugzilla Bug" = 1234567

            In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues@redhat.com. You can also visit https://access.redhat.com/articles/7032570 for general account information.

            pm-rhel added a comment - This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues@redhat.com. You can also visit https://access.redhat.com/articles/7032570 for general account information.

            pm-rhel added a comment -

            Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

            pm-rhel added a comment - Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

              cluster-qe Cluster QE
              tojeline@redhat.com Tomas Jelinek
              Tomas Jelinek Tomas Jelinek
              Michal Mazourek Michal Mazourek
              Steven Levine Steven Levine
              Votes:
              0 Vote for this issue
              Watchers:
              13 Start watching this issue

                Created:
                Updated:
                Resolved: