RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1933036 - Documentation issues on crypto-policies and update-crypto-policies
Summary: Documentation issues on crypto-policies and update-crypto-policies
Keywords:
Status: CLOSED DUPLICATE of bug 1960266
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: crypto-policies
Version: 8.2
Hardware: x86_64
OS: Linux
medium
low
Target Milestone: rc
: ---
Assignee: Alexander Sosedkin
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-25 14:42 UTC by jtougne
Modified: 2021-06-18 14:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-06-18 14:38:11 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+


Attachments (Terms of Use)

Description jtougne 2021-02-25 14:42:07 UTC
Description of problem:
Hi,
Reading crypto-policies and update-crypto-policies, we tried to understand and encountered several difficulties.

1) It's missing the crucial information, which is to indicate the potential values a parameter can have.
For example:
- The possible values for "cipher = " are listed here:
/usr/share/crypto-policies/policies/DEFAULT.pol


2) The values for ssh_cipher = are indicated nowhere.
See for example:
 sudo less /usr/share/crypto-policies/policies/DEFAULT.pol | grep ssh

So we assumed some values, which I even think they are incomplete/incorrect.
See:
ssh_cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

I think, based on the output of this: man ssh_config | grep -i cbc
                   3des-cbc
                   aes128-cbc
                   aes192-cbc
                   aes256-cbc

We only have aes128-cbc, aes256-cbc which can be relevant for ssh_cipher.

Therefore, I provided additional useless -CAMELLIA-256-CBC -CAMELLIA-128-CBC
(the update-crypto-policies did not complain about that)


3) There is something very confusing with instructions.
It's clear there are some requirements of users to "remove CBC ciphers".
See: https://access.redhat.com/solutions/420283

We have to distinguish two type:
3.1 From the server
3.2 From SSHD process only


When reading the instructions, for example man crypto-policies, it shows:

tls_cipher: Optional; list of allowed symmetric encryption algorithms (including the modes) for use with the TLS protocol. If absent, the value is
           derived from cipher.

       ·   ssh_cipher: Optional; list of allowed symmetric encryption algorithms (including the modes) for use with the SSH protocol. If absent, the value is
           derived from cipher.

       ·   cipher: List of allowed symmetric encryption algorithms (including the modes) for use with other protocols


We understood incorrectly that it would be sufficient to create a custom policy file, modifying the DEFAULT, explicitely removing CBC related from the server.
That was not the case, it did not work.

See "How reproducible" for the details.



4) When doing this command: 
sudo update-crypto-policies --set DEFAULT:MINUSCBCCIPHER
We can verify: sudo update-crypto-policies --show 
DEFAULT:MINUSCBCCIPHER
We then modify the actual file:/etc/crypto-policies/policies/modules/MINUSCBCCIPHER.pmod, nothing shows or inform if the actual policy file (MINUSCBCCIPHER.pmod) was modified...
I think that should also be improved to avoid confusion.





Version-Release number of selected component (if applicable):
crypto-policies.noarch 20191128-2.git23e1bf1.el8




How reproducible:


We created this file:
sudo less /etc/crypto-policies/policies/modules/MINUSCBCCIPHER.pmod

cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

(again, based on the list of possible CBC related values described in /usr/share/crypto-policies/policies/DEFAULT.pol for "cipher =").
sudo update-crypto-policies --set DEFAULT:MINUSCBCCIPHER

We rebooted the server.
Based on the manpage, we saw "If absent, the value is derived from cipher.". We though it would be true and disable all CBC related cipher.

That did not work, the test proved ssh cbc cipher were not removed.
ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1 Shows information, and I was able to connect.

When the CBC cipher are not there for ssh, it should show:

Unable to negotiate with 127.0.0.1 port 22: no matching cipher found. Their offer: aes256-gcm,chacha20-poly1305,aes256-ctr,aes128-gcm,aes128-ctr



We then continue and removed tls_cipher also:

tls_cipher = -AES-256-CBC -AES-128-CBC
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

Same process, sudo update-crypto-policies --set DEFAULT:MINUSCBCCIPHER, reboot... ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1 still worked.




We came to the conclusion:
We created a policy modification: /etc/crypto-policies/policies/modules/MINUSCBCCIPHER.pmod

To remove the CBC algorith from the server, modifying the DEFAULT profile, we have to write this in that MINUSCBCCIPHER.pmod file:

tls_cipher = -AES-256-CBC -AES-128-CBC
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC
ssh_cipher = -AES-128-CBC -AES-256-CBC


To remove the CBC algorithm from the server for SSHD only, modifying the DEFAULT profile, we have to write this in that MINUSCBCCIPHER.pmod file::
ssh_cipher = -AES-128-CBC -AES-256-CBC

(Note about ssh_cipher:
ssh_cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC
 We don't specify these -CAMELLIA since they don't appear to be actually advertised or used by sshd: 
See:
 man sshd_config | grep -i cbc
                   3des-cbc
                   aes128-cbc
                   aes192-cbc
                   aes256-cbc )
3des-cbc is not advertised either from RHEL8.2 server, as seen with ssh -vv and looking at "Their offer": aes256-gcm,chacha20-poly1305,aes256-ctr,aes128-gcm,aes128-ctr)

In both cases, we have to set:
sudo update-crypto-policies --set DEFAULT:MINUSCBCCIPHER
And reboot the server, for the policy to take effect.


Thanks,


Steps to Reproduce:


Actual results:


Expected results:


Additional info:

Comment 2 jtougne 2021-03-03 13:22:38 UTC
Hi again,
I wanted to clarify on "2) The values for ssh_cipher = are indicated nowhere."

The problem is trying to find what is currently available for sshd for example.
Looking at the default configuration file /etc/ssh/sshd_config, we see: 

# Ciphers and MACs
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm,aes256-gcm,chacha20-poly1305
MACs umac-64-etm,umac-128-etm,hmac-sha2-256-etm,hmac-sha2-512-etm,hmac-sha1-etm,umac-64,umac-128,hmac-sha2-256,hmac-sha2-512,hmac-sha1


There's no traces of any CBC ciphers. The manpage hints a bit:


man sshd_config

             The supported ciphers are:

                   3des-cbc
                   aes128-cbc
                   aes192-cbc
                   aes256-cbc
                   aes128-ctr
                   aes192-ctr
                   aes256-ctr
                   aes128-gcm
                   aes256-gcm
                   chacha20-poly1305

             The default is handled system-wide by crypto-policies(7).  To see the defaults and how to modify this default, see manual page update-crypto-policies(8).

             The list of available ciphers may also be obtained using "ssh -Q cipher".


The problem is that this command only show what's available, not what is really there:

ssh -Q cipher
3des-cbc
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc.se
aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm
aes256-gcm
chacha20-poly1305


And as indicated the DEFAULT.POL does not display anything for sshd:
/usr/share/crypto-policies/policies/DEFAULT.pol | grep ssh
(nothing, there's not even ssh_cipher displayed).

The problem is that the DEFAULT.POL still uses *some* ssh_cipher, as tested with:
ssh -vv -oCiphers=aes128-cbc,aes256-cbc 127.0.0.1

Another test, this one 3des-cbc is never available:
ssh -vv -oCiphers=3des-cbc 127.0.0.1


One way to find would be this one:
ssh -vv -oCiphers=3des-cbc 127.0.0.1
Since 3des-cbc is not available, we would get the full offering, and see that only 2 cbc ciphers are used:
Their offer: aes256-gcm,chacha20-poly1305,aes256-ctr,aes256-cbc,aes128-gcm,aes128-ctr,aes128-cbc


Then I though with a much easier simplification. Why don't we simply explicitally list in the DEFAULT.POL the ssh_cipher?

That means listing the existing sshd ciphers: 
ssh_cipher = ...AES-128-CBC AES-256-CBC ...(I don't know the exact syntax for each ciphers) in /usr/share/crypto-policies/policies/DEFAULT.pol.

That way, the DEFAULT.pol will accurately list all and the users can know what is really there and how to remove unwanted ones?

Cheers

Comment 3 Alexander Sosedkin 2021-03-03 13:35:57 UTC
We could, and that wouldn't require any code changes, but that'd lead to duplication between ssh_cipher, tls_cipher and cipher.
We'd basically have the same thing spelled out thrice.
Though maybe it'll make sense to be explicit in older 8 versions about it
and come up with some newer-better-less-confusing syntax in the newer versions.

Comment 4 jtougne 2021-03-05 07:34:22 UTC
(In reply to Alexander Sosedkin from comment #3)
> We could, and that wouldn't require any code changes, but that'd lead to
> duplication between ssh_cipher, tls_cipher and cipher.
> We'd basically have the same thing spelled out thrice.
> Though maybe it'll make sense to be explicit in older 8 versions about it
> and come up with some newer-better-less-confusing syntax in the newer
> versions.

Hi,
I don't think it would be a duplication, at least not in terms of features:

when I had only this in the subpolicy, to modify the DEFAULT policy:
tls_cipher = -AES-256-CBC -AES-128-CBC
cipher = -AES-128-CBC -AES-256-CBC -CAMELLIA-256-CBC -CAMELLIA-128-CBC

The sshd was still accepting aes128-cbc and aes256-cbc (somewhere hidden and not visible from the DEFAULT policy).

It's only when I explicitly added:
ssh_cipher = -AES-128-CBC -AES-256-CBC

That the sshd removed aes128-cbc and aes256-cbc from its offering.

Therefore, it's not really the same... cipher and tls_cipher on the default don't related to sshd. It seems only the ssh_cipher, in the subpolicy to remove it, act for sshd.

In fact, I don't know what are using any CBC cipher from the list of tls_cipher, and cipher...it's something else. (If you know please inform me :) ).

Tx,

Comment 5 Alexander Sosedkin 2021-05-11 13:29:02 UTC
Upstream has merged new syntax support, deprecating derived properties like `tls_cipher` and `ssh_cipher`: https://gitlab.com/redhat-crypto/fedora-crypto-policies/-/merge_requests/92
In future versions, a single `cipher = -*-CBC` directive will be enough to cover the example above.

Comment 6 Alexander Sosedkin 2021-06-18 14:38:11 UTC
Closing this one in favor of the rebase bug bz1960266.
For <8.5, we have the docs which are confusing-but-correct and a blog post kindly written by the reporter [1].
For >=8.5, we'll have a simpler syntax which should leave less room for such confusion.

[1] https://www.redhat.com/en/blog/configuring-rhel-8-compliance-crypto-policy-related-cipher-block-chaining

*** This bug has been marked as a duplicate of bug 1960266 ***


Note You need to log in before you can comment on or make changes to this bug.