Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
The DEFAULT crypto policy does not consistently list the client side SSH KEX algorithms, host key algorithms, ciphers, and MACs in strength (preference) order.
How reproducible:
Always
Steps to Reproduce:
1. ssh -i somekey -vvv someuser
2. Review local client KEXINIT proposal to see the preference order specified by the client.
Actual results:
See additional info below.
Expected results:
See additional info below.
Additional info:
See /etc/crypto-policies/back-ends/openssh.config
See https://www.mankier.com/5/ssh_config under Ciphers, HostKeyAlgorithms, KEX Algorithms, MACs et cetera.
Here is an excerpt from an SSH session using -vvv option on a RHEL 8.4 client:
debug2: local client KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256,curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01,ecdsa-sha2-nistp384-cert-v01,ecdsa-sha2-nistp521-cert-v01,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01,rsa-sha2-512-cert-v01,rsa-sha2-256-cert-v01,ssh-rsa-cert-v01,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: aes256-gcm,chacha20-poly1305,aes256-ctr,aes256-cbc,aes128-gcm,aes128-ctr,aes128-cbc
debug2: ciphers stoc: aes256-gcm,chacha20-poly1305,aes256-ctr,aes256-cbc,aes128-gcm,aes128-ctr,aes128-cbc
debug2: MACs ctos: hmac-sha2-256-etm,hmac-sha1-etm,umac-128-etm,hmac-sha2-512-etm,hmac-sha2-256,hmac-sha1,umac-128,hmac-sha2-512
debug2: MACs stoc: hmac-sha2-256-etm,hmac-sha1-etm,umac-128-etm,hmac-sha2-512-etm,hmac-sha2-256,hmac-sha1,umac-128,hmac-sha2-512
I am not an expert in all the of nuances of the various algorithms, ciphers, et cetera, but I would expect that the same algorithms using larger bit sizes would be specified (preferred) first.
EXAMPLES:
KEX: Currently these algorithms are listed in preference order as ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521.
host key: Currently these algorithms are listed in preference order as ecdsa-sha2-nistp256-cert-v01, ecdsa-sha2-nistp384-cert-v01, ecdsa-sha2-nistp521-cert-v01.
MACS: Currently these algorithms are listed in preference order as hmac-sha2-256-etm, hmac-sha2-512-etm.
Is there a reason that these are not specified in strength order? Or is there something fundamental I am missing?
Version-Release number of selected component (if applicable):
Comment 1Alexander Sosedkin
2021-09-01 11:15:10 UTC
> I am not an expert in all the of nuances of the various algorithms, ciphers, et cetera, but I would expect that the same algorithms using larger bit sizes would be specified (preferred) first.
>
> Is there a reason that these are not specified in strength order? Or is there something fundamental I am missing?
I cannot answer the specifics either, but, in general, strength has to be balanced with performance (which doesn't even always scale monotonically with inverse strength).
With performance considerations in mind, I'd actually expect a baseline strength to be set, and order to be closer to "fastest for baseline strength; then stronger ones we need for forward compat; then weaker ones we'd need for backwards compat". Thus, what I see is less surprising for me than for you, and I would kindly decline your request in its generic form of reordering everything based on strength alone.
If you have more specific suggestions for reordering, ideally in form of "algorithm X is both more secure than Y and faster on my machine, but Y is prioritized for some reason, please promote X", I'd like to suggest you to open separate specific bugs both against RHEL and/or SSH upstream. Ideally we'd prefer for the change to be done upstream first.
Upstream priorities, for reference: https://github.com/openssh/openssh-portable/blob/cb37e2f0c0ca4fef844ed7edc5d0e3b7d0e83f6a/myproposal.h