[asterisk-bugs] [JIRA] (ASTERISK-29128) res_srtp: Authentication failure after hold/unhold

[Alexander Traud (JIRA)]

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

Alexander Traud commented on ASTERISK-29128:
--------------------------------------------

bq. wireshark trace won't tell you much

Asterisk logs are terribly difficult to read because I cannot filter. Who started the call, who is involved:
* You used Blink on a Linux machine and started the call.
* You use the channel driver PJSIP and the usual ‘Dial’ command in your dialplan (extensions.conf).
* You call a Snom D715 with firmware 8.9.3.80.
* On your Snom, you put the call on hold.
* On your Snom, you unhold the call again.
* Now, that RTP stream coming from the Snom is marked as unauthenticated; and just that stream (not the one coming from Blink).

*First question*: Is that correct?
*Second question*: What happens when you start the call the other way around: Snom calls Blink, not Blink but still the Snom puts the call on hold?

In your last log, I found something fascinating:
In the beginning, your Snom is accepting SHA1_80. When the Snom puts the call on hold, it reuses the existing crypto-key but changes the crypto-suite to SHA1_32. I have to find a way to reproduce that (today is not test day here).

*Third question*: On your Snom → Web interface → Identity x → RTP → SRTP Auth-Tag: [AES-80|https://service.snom.com/display/wiki/user_auth_tag]: Does that workaround the issue? If yes, let us undo the authentication tag on your Snom to its default AES-32. Then,
*Fourth question*: On your Asterisk, in the configuration file {{pjsip.conf}}, in the endpoint(s) of your Snom(s), set {{srtp_tag_32=yes}}: Does that workaround the issue as well?

I know, these are just (possible) workarounds and not a solution. Nevertheless, those four answers would help me to reproduce your scenario.

bq. 8.9.3.80 … scrub sensitive information

I see. Thanks for double-checking firmware .60. But no worry, I try to catch-up with your scenario.
Not related to this issue, but just for your information: Newer firmware introduce security updates as well. Actually, the firmware released on the 1st of December 2020 included a security fix for SIP over TLS. Since day one, Snom was using a wrong, possible manipulated domain to check the server name in the TLS certificate. If you face showstopper bugs, did you discuss those with the Snom support already? Anyway, for the sack of simplicity and because I am able to reproduce that scenario, let us stay with Snom 8.9.3.80 for now.

bq. recommend to stick with 1.5.4 

I know that Wiki entry. However, it is bad advice because it does not explain what was wrong with older versions exactly; and it does not explain why libSRTP 2.x is not tested. Furthermore, it is uncertain whether libSRTP 1.5.x is still maintained and ‘secure’. Actually, it would be the job of the one giving such advice to double-check that (again and again because that can change on a daily basis). libSRTP 2.3 works here without problems. And the community should use the latest to make sure the code in Asterisk stays compatible. Anyway, for the sack of simplicity and because I am able to reproduce that scenario, let us stay with libSRTP 1.5.4 for now.

> res_srtp: Authentication failure after hold/unhold
> --------------------------------------------------
>
>                 Key: ASTERISK-29128
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29128
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_srtp
>    Affects Versions: 16.13.0
>            Reporter: laszlovl
>         Attachments: filtered.log, snom-srtp-debug-filtered.log
>
>
> As simple as the title indicates. Put an SRTP call on hold, unhold it, and Asterisk starts logging "SRTP unprotect failed on SSRC 1509410849 because of authentication failure" afterwards. No more audio is transmitted.
> Traced the problem to commit https://github.com/asterisk/asterisk/commit/c00b032bbfc14f40537989477229f189a1b529d7 (ASTERISK-28903), without it everything works fine.
> Asterisk 16.13, libsrtp 1.5.4.



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