Red Hat Bugzilla – Bug 1352941
Backport automatic selection of curves for ECDHE in DTLS
Last modified: 2017-08-01 14:16:10 EDT
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.
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.
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.
Yes, this is going to be fixed in RHEL-7.4 if all goes well.
*** This bug has been marked as a duplicate of bug 1276310 ***
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