[asterisk-bugs] [JIRA] (ASTERISK-29272) chan_iax2: Full URIs don't implement secure media checks properly

Thu Feb 4 12:58:59 CST 2021

     [ https://issues.asterisk.org/jira/browse/ASTERISK-29272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

George Joseph updated ASTERISK-29272:
-------------------------------------

    Assignee: N A
      Status: Waiting for Feedback  (was: Triage)

Can you test this again with the new patch and see if it changes anything?  The CHANNEL variables do work for me now.

> chan_iax2: Full URIs don't implement secure media checks properly
> -----------------------------------------------------------------
>
>                 Key: ASTERISK-29272
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29272
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Channels/chan_iax2
>    Affects Versions: 18.2.0
>         Environment: Debian 10, Asterisk 18.2. Same issue occurred with Asterisk 13.38, so presumably all Asterisk versions are affected.
>            Reporter: N A
>            Assignee: N A
>            Severity: Major
>
> According to: https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Specifics
> ${CHANNEL(secure_signaling)} and ${CHANNEL(secure_media)} allow for a per-call forceencrypt=yes setting.
> However, when I try to do this, the call fails with the error **Call terminated. No secret given and force encrypt enabled**.
> This occurs whether or not the provided secret is valid and even whether or not the provided hostname is valid. I tried with both the actual IAX2 endpoint as well as literally what is below, and I get the same exact results each time:
> ```
> [Jan 31 11:07:23]     -- Executing [18 at vsc:1] Set("Local/*18 at from-internal-000003b0;2", "__forcesecurechannel=1") in new stack
> [Jan 31 11:07:23]     -- Executing [18 at vsc:2] ExecIf("Local/*18 at from-internal-000003b0;2", "1?Set(CHANNEL(secure_bridge_signaling)=1)") in new stack
> [Jan 31 11:07:23]     -- Executing [18 at vsc:3] ExecIf("Local/*18 at from-internal-000003b0;2", "1?Set(CHANNEL(secure_bridge_media)=1)") in new stack
> [Jan 31 11:07:23]     -- Executing [18 at vsc:4] Dial("Local/*18 at from-internal-000003b0;2", "IAX2/main:somesecret at example.com/3475001,,g") in new stack
> [2021-01-31 11:07:23] WARNING[28425][C-00000417]: chan_iax2.c:5122 iax2_call: Call terminated. No secret given and force encrypt enabled
> [Jan 31 11:07:23]     -- Couldn't call IAX2/main:somesecret at example.com/3475001
> [Jan 31 11:07:23]     -- Hungup 'IAX2/93.184.216.34:4569-1658'
> [Jan 31 11:07:23]   == Everyone is busy/congested at this time (0:0/0/0)
> [Jan 31 11:07:23]     -- Executing [18 at vsc:5] NoOp("Local/*18 at from-internal-000003b0;2", "CHANUNAVAIL HANGUP CAUSE: 0") in new stack
> ```
> This makes no sense, as I am providing a secret and it literally says "No secret given". This seems to be a bug where Asterisk is preemptively ending the call where it (erroneously) detects no secret has been provided.
> A Digium developer tested a scenario out using these variables with calling an IAX2 destination and said it worked, confirming this functionality is supported for IAX2: https://issues.asterisk.org/jira/browse/ASTERISK-29264?focusedCommentId=253674&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-253674
> The example there was:
> ```
> exten = 9998,1,NoOp(Incoming to ${EXTEN} from ${CALLERID(all)})
> same  = n,Set(CHANNEL(secure_bridge_signaling)=1)
> same  = n,Set(CHANNEL(secure_bridge_media)=1)
> same  = n,Dial(IAX2/ernie:testing at jac73/${EXTEN})
> same  = n,Hangup()
> ```
> The only difference is jac73 appears to have a local iax.conf entry. In this case, that is not true, as all the info is in the dial string, with no local iax.conf entry.
> One thing that comes to mind is that Asterisk doesn't know at this point whether the secret on the remote peer is MD5 or plaintext, since the format is identical for both. But it can't know that without negotiating, and clearly it is not negotiating to determine that, and preemptively ends the call. The result is that IAX2 calling with a full IAX URI fails.
> To investigate, I created a local iax.conf user for the dial peer, just for kicks and giggles.
> With this user defined:
> [testing]
> type=friend
> context=main
> host=redacted.com
> it still did not work.
> With this user defined:
> [testing]
> type=friend
> context=main
> auth=md5
> host=redacted.com
> it still did not work.
> With THIS user defined:
> [testing]
> type=friend
> context=main
> auth=md5
> secret=thesecret
> host=redacted.com
> The call worked as expected - note however that a full IAX2 URI with the exact same information still fails:
> [Jan 31 11:18:13]     -- Executing [18 at vsc:4] Dial("Local/*18 at from-internal-000003bc;2", "IAX2/thesecret at redacted.com/3475001,,g") in new stack
> [2021-01-31 11:18:13] WARNING[29101][C-00000421]: chan_iax2.c:5122 iax2_call: Call terminated. No secret given and force encrypt enabled
> [Jan 31 11:18:13]     -- Couldn't call IAX2/main:thesecret at redacted.com/3475001
> [Jan 31 11:18:13]     -- Hungup 'IAX2/testing-3697'
> [Jan 31 11:18:13]   == Everyone is busy/congested at this time (0:0/0/0)
> [Jan 31 11:18:13]     -- Executing [18 at vsc:5] NoOp("Local/*18 at from-internal-000003bc;2", "CHANUNAVAIL HANGUP CAUSE: 0") in new stack
> [Jan 31 11:18:13]     -- Executing [18 at vsc:6] Dial("Local/*18 at from-internal-000003bc;2", "IAX2/main:thesecret at testing/3475001,,g") in new stack
> [Jan 31 11:18:13]     -- Called IAX2/thesecret at testing/3475001
> [Jan 31 11:18:13]     -- Call accepted by REDACTED:4569 (format ulaw)
> So, secure calling with IAX2 only seems to work if there is a locally defined user in iax.conf with both the auth method and the secret. IAX2 URIs do not work with secure calling at all. It seems Asterisk is preemptively ending the call if there is no iax.conf user, *even if a secret is provided in the dial string*. This bug prevents the ability to force a secure call when the IAX2 endpoint is an arbitrary IAX2 dial string as opposed to something predefined and preexisting in iax.conf, referenced by its local iax.conf name.
> Thus, currently, the ability to force encrypt an IAX2 call using the full URI is either buggy or nonexistent. This is a major loss in capability, since it is not always possible for there to be a corresponding iax.conf entry with the correct secret and what not for every call we might wish to make.
> The ideal behavior here as I see it would be to a) NOT preemptively and prematurely fail the call if there is no iax.conf entry and an IAX2 URI is provided *IF* a secret is provided and the call can negotiate as MD5 (if it's RSA, a dial string can't be used, and if it's plaintext, the call is not encrypted so it should presumably fail anyways... thus, such a call must be MD5).

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