[asterisk-bugs] [JIRA] (ASTERISK-22961) [patch] DTLS-SRTP not working with SHA-256

[Lorenzo Miniero (JIRA)]

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

Lorenzo Miniero commented on ASTERISK-22961:
--------------------------------------------

Hi Matt,

I'd be really glad to contribute to make DTLS support better for Asterisk, whether for Asterisk 13 or current versions as well. To address your points:

* If PJNATH isn't used anymore, then I agree there's definitely no need to patch it. Besides, as I mentioned this was fixed in Firefox in the meanwhile, as it was most probably a fault on their side. In fact, other libraries (e.g., libnice) tend to behave the same way, so PJNATH wasn't doing anything wrong I guess.

* Your approach to the separation of RTCP features sounds reasonable, and would definitely help in getting DTLS to work in the non-muxing case. On a related note, is support for rtcp-mux planned in Asterisk instead? Muxing RTP and RTCP would remove the need for two different DTLS handshakes in the first place.

* The sequence bits are mostly related to some flags I added (icedone, dtlsdone, etc.), and I also added a callback that is invoked by PJNATH when ICE is done. I then used those flags to make sure media packets wouldn't be sent if DTLS wasn't completed yet, and in turn the DTLS handshake wouldn't be started before ICE was complete as well. This of course if DTLS was enabled: without DTLS, it would be "no media before ICE". The code for that should be easily extractable from the overall patch: I'll try and prepare one earler next week. Should I post it here or somewhere else?

* About the "DTLS always enabled", what I noticed is that, when DTLS is enabled in the configuration, it is negotiated by default for all outgoing calls (unless disabled for some specific peers). If I recall correctly (but I may be wrong here, I'll have to check), it also made insecure (RTP/AVP) calls fail because no secure context was provided. Considering I was interested in both type of calls, I used that ugly hack to quickly enable DTLS (using some predefined values and not the config, right) only for incoming calls that negotiated it. It's definitely not the right way to fix the issue, if any, but it worked for me.
                
> [patch] DTLS-SRTP not working with SHA-256
> ------------------------------------------
>
>                 Key: ASTERISK-22961
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-22961
>             Project: Asterisk
>          Issue Type: Improvement
>      Security Level: None
>          Components: Channels/chan_sip/SRTP, Channels/chan_sip/WebSocket
>    Affects Versions: 11.6.0, 12.0.0-beta2
>            Reporter: Jay Jideliov
>         Attachments: asterisk_dtls.patch, res_rtp_asterisk.c
>
>
> Recently it became possible to use websocket on asterisk without a proxy previously necessary to make calls from the web browser. Although partial support has been added, full browser cross-operability has not been achieved yet. However, it seems to be a relatively easy task.
> Tested on Chrome+SIPML5+Asterisk 11, the connection can be established and works fine. However, due to the fact that Firefox sends SHA-256 packets which are not supported by asterisk, hence the support for this browser is limited by this issue.
> Step 1: Adding certificates to support DTLS
> dtlsenable = yes
> dtlsverify = no
> dtlscertfile=/etc/asterisk/keys/softphone.pem
> dtlsprivatekey=/etc/asterisk/keys/key.pem
> dtlscafile=/etc/asterisk/keys/key.pem
> Step 2: Making a call
> [Nov 25 15:05:50] WARNING[5628][C-0000005c]: chan_sip.c:11034 process_sdp_a_dtls: Unsupported fingerprint hash type 'sha-2' received on dialog '38f43a1f-15cd-ad69-c2b3-72c21b9de5fd'

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira