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

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-22961:
----------------------------------------

Just some thoughts on aspects of this patch. In general, I think having it targeted for Asterisk trunk makes a lot of sense, and would be a great addition for Asterisk 13.

{quote}
    There's a small hack in PJNATH, specifically in ice_session.c. Firefox at the time (a few months ago) replied with a 401 everytime it got a connectivity check for a session that wasn't ready yet. PJNATH failed immediately when receiving a 401 and everything stopped there. I changed the PJNATH behaviour to NOT fail when getting a 401 and retrying again indefinitely (I should have placed a timeout there, I know ), until everything was set up correctly in Firefox as well. Anyway, this has apparently been fixed in Firefox in the meanwhile, so this may not be needed anymore.
{quote}

Since PJSIP (including PJNATH) has been pulled out of Asterisk in 12+, it's obviously preferable not to have to change code in those libraries. If it's not needed, it'd be nice to leave out.

Alternatively, we could make a pull request against PJSIP, and see what Teluu thinks - but I'd treat that as something completely separate.

{quote}
    In res_rtp_asterisk.c there are a LOT of hacks. The main one is that I "cloned" the DTLS code related to RTP to have it used for RTCP as well. In fact, Asterisk does not support rtcp-mux, which means RTP and RTCP are on different "channels". This requires a separate DTLS handshake for both of them, something that in Asterisk originally didn't happen, causing the call to fail immediately (no DTLS handshake for RTCP happening). I placed code to do so, but beware that this currently does NOT get SRTCP to actually work: in fact, while there is a correct DTLS handshake for RTCP, the SRTP session for SRTCP cannot be setup, as RTP and RTCP currently share the same crypto context in Asterisk. This separate handshake requires their contexts to be separated, something that would require a deeper change in Asterisk than the hacks I placed now. Anyway, this proved sufficient in getting the call to work, at least.
{quote}

Yeah... RTCP in res_rtp_asterisk. :-(

For a long time I've wanted to restructure the object in there (and did a small amount of that in 12); that's especially true with Olle's RTCP work in pinefrog. Looking at this patch, it's even more true. I think at this point, it makes more sense than ever to break res_rtp_asterisk up into some bite sized chunks. Probably one to deal with RTCP, and another to deal with DTLS. Something to think about.

{quote}
    I then had to make sure the proper sequence of steps was followed, that is 1. ICE complete, 2. DTLS handshake, 3. media. In the Asterisk code I had this was not respected, and so you could see media being sent before, for instance, the DTLS handshake was completed, thus possibly confusing the browser on the other side. To do so I added some flags to the RTP/RTCP sessions, and a callback that is part of the PJNATH API to know when ICE is done.
{quote}

Arguably, this is a bug. If you could extract this portion out of the SHA-256 work, I think we could treat it as such for Asterisk 11.

{quote}
    I changed the hashing mechanism from SHA-1 to SHA-256, which is what both Firefox and Chrome are negotiating right now. I also added a verification callback that does nothing but return a success: this is needed to have the DTLS handshake work when verification is requested, as this forces the peer to send its certificate, which can then be validated by manually checking the fingerprint (all certificates are self signed which means a formal verification would inevitably fail).

    Then, I added a LOT of debug on the console that described what the code is doing. I did so in order to understand what was happening, especially when things didn't work for me. This debug is controllable by means of a new cli command called "dtls set debug".
{quote}

Debug is always good. DTLS is hard to debug when things go wrong.

{quote}
    Finally, for what concerns the code in chan_sip.c, it is mostly aimed at fixing a couple of behaviours that were in the way for Firefox. First of all, I made sure SHA-256 could be parsed, and that it was generated when creating SDP (as that's what I did use in res_rtp_asterisk.c). Then, I moved all DTLS initialization after the RTCP setup, since as explained DTLS needed to be set up for RTCP as well. Then, I placed some really ugly code to force DTLS with some default parameters everytime a 'fingerprint' attribute was found in SDP: in fact, Asterisk now needs DTLS to be enabled in the configuration, but this then mandates DTLS for ALL calls, which is something I didn't want. So I disabled DTLS in the configuration and only enabled it programmatically when needed (which worked for me since, as I explained in my report at the time, I only received calls and never originated any).
{quote}

Hm. I'm not sure I understand why the second part of this is necessary, i.e., always enabling DTLS. Was it just so that you didn't have to worry about configuring DTLS in sip.conf?
                
> [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
>
>
> 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