[asterisk-bugs] [JIRA] (ASTERISK-25659) DTLS failure occurred on RTP instance

[Edwin Vandamme (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-25659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=228916#comment-228916 ] 

Edwin Vandamme commented on ASTERISK-25659:
-------------------------------------------

I have been looking at a lot of information in order to figure out what is actually happening and the following is a step by step walk through my thinking process, so apologies for any mistakes.

1) Test connection to see what cipher is being used with and without the previous suggested code modification.
{quote}openssl s_client -connect __MYDOMAIN__:8089{quote}
Both instances secp521r1 curve is selected not prime256v1, so this might not be a proper test but may tell us that secp521r1 is the prefered curve for SSL_CTX_set_ecdh_auto.
To find out what curves are supported :
{quote}openssl ecparam -list_curves{quote}
 This lists :
{quote} 
secp384r1 : NIST/SECG curve over a 384 bit prime field
secp521r1 : NIST/SECG curve over a 521 bit prime field
prime256v1: X9.62/SECG curve over a 256 bit prime field
{quote}
So from the earlier tests we might conclude that the order set in openssl is not important SSL_CTX_set_ecdh_auto seems to select the most stringent curve.

2) There are known limitations on RedHat EL and CentOS with openssl as RedHat is very restrictive as it comes down to openssl, which makes sense to guarantee best security and this is also the reason I would prefer to stick to this openssl version..

3) However, rebuilding openssl from source did not fix the problem.

4) The cipher can be set for Asterisk with tlscipher= in sip.conf, but that does not allow you to set the curve being used, so that is not an option.

5) So what if the curve order or the available curves could be set in Asterisk ?
Prior to executing SSL_CTX_set_ecdh_auto a curve list can be set as follows :
{quote}SSL_CTX_set1_curves_list(rtp->ssl_ctx, "P-256\:P-521\:P-384");{quote}
or as P-256 is the one required just :
{quote}SSL_CTX_set1_curves_list(rtp->ssl_ctx, "P-256");{quote}

Unfortunately this function does not exist in ssl.h for RedHat/CentOS, probably for security reasons, so I regard this as a no go in case the same issue arises on other systems.

The function exists in the openssl.org source code.

In any event, I do feel this defies the use of SSL_CTX_set_ecdh_auto.

6) Another option would be to test SSL_CTX_set_ecdh_auto and fallback to SSL_CTX_set_tmp_ecdh on communication failure, though this might overcomplicate the code.

7) The only solution I can see that will fit all installations is to forget about SSL_CTX_set_ecdh_auto altogether, yes I know that is the recommended solution.
There is the possibility to set the usage in sip.conf, but why overcomplicate the configuration as there are already too many issues with webRTC to begin with.
(Patch included if you feel this is the best solution)

As a final remark, I wish to point out that I have little experience in these openssl matters, so I might be completely in the wrong ballpark regarding the above, in which case I gladly stand corrected.


> DTLS failure occurred on RTP instance
> -------------------------------------
>
>                 Key: ASTERISK-25659
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25659
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>    Affects Versions: 13.6.0
>         Environment: Using the following on the server :
> CentOS	  	  	7.2	  	2015-11
> Asterisk	  	  	13.6	  	2015-10
> jansson  	  	  	2.7	  	2014-10-02
> PJSIP (pjproject)	2.4.5	2015-08-12
> sipML5  	  		2.0.2	2015-12
> Using the following on the client :
> CentOS  	  	  	7.2 KDE desktop
> Chrome Version  	47.0.2526.106 (64-bit) 
>            Reporter: Edwin Vandamme
>            Assignee: Edwin Vandamme
>            Severity: Minor
>         Attachments: asterisk.log
>
>
> This issue has been on the forum for over a week, but I did not get any feedback, http://forums.asterisk.org/viewtopic.php?f=1&t=96461&sid=528c724d236a38e60e868817462c6f26, so I have now escalated this as a bug report.
> Using the described environment, I get the following error in my Asterisk log :
> res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0x7fe8c8024178' due to reason 'missing tmp ecdh key', terminating
> res_rtp_asterisk.c: RTP Read error: Unspecified. Hanging up.
> An earlier bug report listed this as a problem on FireFox : ASTERISK-25265
> It is said to be fixed in 13.6
> WebRTC is not yet in production on my system, due to the constant changes, but in earlier tests everything worked fine. As far as I can tell, it all started when Chrome forced the usage of https over http.
> Dialing from a WebRTC peer to Asterisks works just fine.
> For various reasons I use sip.conf, not pjsip.conf.
> Certificates used are propper certificates, not self signed versions.
> I attached (asterisk.log) part of the Asterisk log file with "sip debug on", start of call till failure.



--
This message was sent by Atlassian JIRA
(v6.2#6252)