Summary: | ASTERISK-16867: [patch] Hold/Unhold not possible with SIP using SRTP | ||
Reporter: | Bernhard S (bernhards) | Labels: | patch |
Date Opened: | 2010-10-25 03:31:36 | Date Closed: | 2011-05-13 13:06:29 |
Priority: | Major | Regression? | No |
Status: | Closed/Complete | Components: | Channels/chan_sip/SRTP |
Versions: | Frequency of Occurrence | ||
Related Issues: | |||
Environment: | Attachments: | ( 0) replay_protection.patch ( 1) res_srtp_unhold.patch | |
Description: | 2 phones connected with SIP on Asterisk. Both are configured with SRTP. Call from phone A to phone B. Then A press "hold" and after 20 seconds, A press unhold. Then there is no voice from A to B and also no voice from B to A. On the console I get the error: res_srtp.c:338 ast_srtp_unprotect: SRTP unprotect: replay check failed (index too old) If the hold time is less (e.g. not 20 seconds but 2 seconds) it does _sometimes_ work. | ||
Comments: | By: Bernhard S (bernhards) 2010-10-27 04:06:16 Please find attached a patch. The patch does simply re-establish the SRTP session and add all the policies to it again. Maybe just a "try" to show how the real fix should look like. By: frank koster (notthematrix) 2010-11-04 12:19:24 Installed the patch , see if it also iliminates certain whitenoice carbage situation in thge middele of a call.... Because If I remeber correctly , internet hickups can put asterisk in (hold) for a very short wile and comming back when RTP flow is restored... Using granstream ht-50x in (TCP)TLS / SRTP forced.. By: Bernhard S (bernhards) 2010-12-01 02:50:41.000-0600 Patch does work for more than a month on our system. By: Digium Subversion (svnbot) 2011-05-13 13:04:51 Repository: asterisk Revision: 318919 U branches/1.8/res/res_srtp.c ------------------------------------------------------------------------ r318919 | bbryant | 2011-05-13 13:04:51 -0500 (Fri, 13 May 2011) | 10 lines This patch fixes an issue with SRTP which makes HOLD/UNHOLD impossible when too much time has passed between sending audio. (closes issue ASTERISK-16867) Reported by: bernhardsi Patches: res_srtp_unhold.patch uploaded by bernhards (license 1138) Tested by: bernhards, notthematrix ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=318919 By: Digium Subversion (svnbot) 2011-05-13 13:06:29 Repository: asterisk Revision: 318920 _U trunk/ U trunk/res/res_srtp.c ------------------------------------------------------------------------ r318920 | bbryant | 2011-05-13 13:06:28 -0500 (Fri, 13 May 2011) | 16 lines Merged revisions 318919 via svnmerge from https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r318919 | bbryant | 2011-05-13 14:04:50 -0400 (Fri, 13 May 2011) | 10 lines This patch fixes an issue with SRTP which makes HOLD/UNHOLD impossible when too much time has passed between sending audio. (closes issue ASTERISK-16867) Reported by: bernhardsi Patches: res_srtp_unhold.patch uploaded by bernhards (license 1138) Tested by: bernhards, notthematrix ........ ------------------------------------------------------------------------ http://svn.digium.com/view/asterisk?view=rev&revision=318920 By: Alexander Traud (traud) 2019-01-03 06:41:55.800-0600 The [code change|https://github.com/asterisk/asterisk/commit/085b7b212a1ff3a343b16a7b803527f2afd6ac1f] disabled the [Replay Protection|http://tools.ietf.org/html/rfc3711#section-3.3.2] of sRTP in general. Unfortunately, I cannot see attachments of this issue report. Were they lost with the transition from Mantis to Jira? Because of this, I cannot look into a packet trace to analyze the actual cause of this issue. Furthermore, I do not have a Grandstream HT502 or Grandstream HT503 to test the latest firmware. However, with a [VTech VDP600|https://businessphones.vtech.com/pd/2546] (Snom M200 SC, Alcatel IP2215 aka ATLINKS IP2215), I saw issues with the sequence number of the media packets (RTP-SEQ): It resets the stream because of a SIP Session Timer. This is a software bug of this device. By this, a new RTP-SEQ is randomly chosen as starting point. If a lower RTP-SEQ was taken, Asterisk resets its stream as well. Because of this, the two match again and the call/audio continues. This code change killed the Replay Protection and even worse allows an attacker to turn down long-lasted calls (when the RTP-SEQ wrapped from 0xffff to 0x0, libSRTP increased a roll-over counter sRTP-ROC internally; Asterisk resets the stream, which resets the ROC to 0, and therefore the correct audio is not authenticated anymore). In the past, Asterisk has seen several enhancements when it comes to sRTP, like ASTERISK-20194 which handles re-INVITEs with new key material. Therefore, it is questionable whether this change is still needed nowadays. With my device, it is a software bug which cannot be repaired by Asterisk (if not a lower but a higher RTP-SEQ was taken randomly, Asterisk does not reset its stream). I attached a patch which disables this code change and therefore re-enables Replay Protection. Not sure if I have the time, to test all my devices against this. We have three options: a) leave the code as is; concerned users applies my patch manually b) remove the code and add a statement to the document CHANGES c) add a new configuration setting to change state of Replay Protection at runtime in general (perhaps to RTP.conf) or on a peer level (\[pj\]sip.conf). |