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:
Version-Release number of selected component (if applicable):
How reproducible:
Steps to Reproduce:
1.
2.
3.
Actual results:
Expected results:
Additional info:
[Sorry, hit return too soon]
Description of problem:
After upgrading openssl.x86_64 0:1.0.1e-30.el6_6.8 to openssl.x86_64 0:1.0.1e-30.el6_6.9, I noticed outgoing mail failing with the message "TLS handshake failed" to a few sites.
Version-Release number of selected component (if applicable):
openssl.x86_64 0:1.0.1e-30.el6_6.9
How reproducible:
Steps to Reproduce:
1. Upgrade sendmail client system to openssl version above
2. Attempt to send mail to (for example) Dartmouth.edu or umn.edu
3. Watch it fail
Actual results:
Messages fail, remain in queue
Expected results:
The sendmail TLS negotiation should either work or fail; in either case the mail should proceed.
Additional info:
That means the servers use seriously insecure DH parameters (shorter than 768 bits).
Can you specify the TLS ciphersuite string in the client? If so, just set DEFAULT:!EDH:!DHE as the ciphersuites and you should be able to connect.
Thank you Tomas. I've tested the workaround in Comment 3, and it seems to be safe and effective. Just in case an equally hapless sendmail admin happens across this report, the magic involves appending
LOCAL_CONFIG
O CipherList=DEFAULT:!EDH:!DHE
to your sendmail.mc file (where the LOCAL_CONFIG line is only necessary if you don't already have one). Rebuild sendmail.cf, restart sendmail.
I originally thought this only affected client connections. Looking more closely at our logs, I see it also caused server connections to fail.
According to https://weakdh.org/ 14.8% of SMTP servers are vulnerable to LOGJAM. Given that this is (more or less) the sendmail default behavior, I'm surprised it's not more.