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

Wed Dec 11 05:21:03 CST 2013

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

Lorenzo Miniero edited comment on ASTERISK-22961 at 12/11/13 5:19 AM:
----------------------------------------------------------------------

Hi again,

I prepared a quick patch (for Asterisk 11.1.2) that should work. I verified it has everything DTLS related from my code, and that it compiles file, but I didn't have time to test it yet, sorry...

As you can see, the patch is quite ugly right now, but considering that code works for me now I'll describe what it does so that this may help solving the issue for good:

* 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.

* 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.

* 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.

* 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".

* 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).

I may be forgetting something but I guess that's all. If there's any explaination or clarification you need about my code feel free to ask.

Lorenzo

      was (Author: lminiero):
    Hi again,

I prepared a quick patch that should work. I verified it has everything DTLS related from my code, and that it compiles file, but I didn't have time to test it yet, sorry...