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 1352941 - Backport automatic selection of curves for ECDHE in DTLS
Summary: Backport automatic selection of curves for ECDHE in DTLS
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: openssl
Version: 7.2
Hardware: All
OS: All
unspecified
medium
Target Milestone: rc
: ---
Assignee: Tomas Mraz
QA Contact: Stefan Dordevic
URL: https://issues.asterisk.org/jira/brow...
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-07-05 14:33 UTC by Alexander Traud
Modified: 2017-08-01 18:16 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 18:16:10 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)
Backport for DTLS; tested on CentOS Linux 7 (747 bytes, patch)
2016-07-05 14:33 UTC, Alexander Traud 		no flags Details | Diff
View All


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1080128 0 low CLOSED Backport automatic selection of curves for ECDHE 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2017:1929 0 normal SHIPPED_LIVE openssl bug fix and enhancement update 2017-08-01 18:08:01 UTC

Internal Links: 1080128

Description Alexander Traud 2016-07-05 14:33:19 UTC 
Created attachment 1176464 [details]
Backport for DTLS; tested on CentOS Linux 7

Description of problem:
This is not a feature request but report about a introduced regression of 1080128. 1080128 implemented this feature for TLS/SSL but not for DTLS, because in OpenSSL 1.0.2 there is no separation between TLS and DTLS anymore. Or stated differently, in OpenSSL 1.0.2, ssl3_send_server_key_exchange(.) handles both TLS and DTLS. In OpenSSL 1.0.1, DTLS is still handled via dtls1_send_server_key_exchange(.). There in that method, no change was made with the change of 1080128. Consequently, SSL_CTX_set_ecdh_auto(.) creates error 311 (SSL_R_MISSING_TMP_ECDH_KEY) later on a DTLS handshake.

Version-Release number of selected component (if applicable):
openssl-1.0.1e-51.el7_2.5.x86_64

How reproducible:
Puh. That is a difficult one because I am not aware of any other approach than a complete DTLS setup. With the VoIP/SIP server Asterisk 13, you setup an HTTPs server for SIP-over-Secure-WebSockets (wss://). Then, you have to register the WebRTC client to Asterisk. Furthermore, the WebRTC server has to call the WebRTC client, so Asterisk is the DTLS server. Not the other way around. A starting point might be https://wiki.asterisk.org/wiki/display/AST/WebRTC+tutorial+using+SIPML5

Expected results:
no error, the first supported Elliptic Curve of the DTLS client should be selected

Actual results:
on DTLS handshake, error 311 (SSL_R_MISSING_TMP_ECDH_KEY): "missing tmp ecdh key"

Additional info:
This issue was reported by an user of Asterisk (since version 11.20.0 and version 13.6.0) in CentOS Linux 7.2 (1511). Please, see the URL for additional information.
Comment 4 Karel Srot 2016-07-13 05:02:19 UTC 
Unfortunately we were not able to address the issue in development phase therefore we postpone it to next minor product update. If you consider the issue important and urgent please escalate the issue through a customer support.
Comment 5 Alexander Traud 2016-07-16 08:45:52 UTC 
Is there a webpage which explains the difference between "development phase" and "(minor) product update"? I am not sure, I understand that terms yet but sounds OK. Or are you about "minor release", so this patch ends up in 7.4? OK for me.

Anyway, just to re-interate not to create any misunderstanding:
1a) any project which uses SSL_CTX_set_ecdh_auto or
1b) any project which uses SSL_set_ecdh_auto or
1c) any project which uses SSL_CTRL_SET_ECDH_AUTO, and
2) uses DTLS as server
is not able to establish any connection. TLS connections are fine (backport works there). DTLS client connections are fine. Just all DTLS servers are affected. By now, all DTLS server implementations should have been updated to use ECDHE and therefore fulfill condition 1 always. Consequently, all state-of-the-art DTLS server implementations are broken in the RHEL 7.2 world. Because that backport was not correct/complete.

Here, the attached patch fixes this. Additionally, the Asterisk issue shows a way to workaround the issue from within the DTLS server implementation side (always set_tmp_ecdh, even when you set_ecdh_auto).

If anyone is interested in this fix, please, follow the advice of Karel because I am just an external contributor not even using RHEL or CentOS Linux actually.
Comment 6 Tomas Mraz 2016-07-18 09:05:51 UTC 
Yes, this is going to be fixed in RHEL-7.4 if all goes well.
Comment 7 Tomas Mraz 2017-04-03 14:25:46 UTC 

*** This bug has been marked as a duplicate of bug 1276310 ***
Comment 11 errata-xmlrpc 2017-08-01 18:16:10 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, 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/RHBA-2017:1929
Note You need to log in before you can comment on or make changes to this bug.