Summary:ASTERISK-20973: Insecure=very does not work if callerId found in extention
Reporter:Badalian Vyacheslav (slavon)Labels:
Date Opened:2013-01-22 23:35:50.000-0600Date Closed:2013-03-07 10:18:21.000-0600
Versions: Frequency of
Description:Hello all.

Bug Example:

I use FreePBX (but i belive that bug in asterisk) and have 1 peer and 10 extentions (assigned numbers is 100-110)
Host configuration like this:


If i call from [ext-ats] to * and my CallerID is 100 (i have extention 100 in asterisk) i get message like "Auth failed", "username and digest mismatch", but if i call from number Callerid 1000 (i don't have extention 1000 in asterisk) param "insecure" is work as it must. In older version (1.4-1.6) insecure does not check callerid, only host and port.

Comments:By: Rusty Newton (rnewton) 2013-01-23 09:54:09.017-0600

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Please post an Asterisk full log with VERBOSE and DEBUG messages enabled to demonstrate the issue.

This issue is very likely configuration related. We'll take a quick look at the debug, but you may be referred back to user forums or mailing lists where you can get further help to narrow down the issue.

By: David Woolley (davidw) 2013-01-28 05:39:02.896-0600

You seem to be referring to insecure=invite, i.e. the port option is not relevant.

Although widely recommended by ITSPs, insecure=port,invite is rarely the most appropriate setting.  This is a case of when presented with a security feature that is getting in the way, disable it completely, rather than using a least privilege approach.

insecure never controlled the matching by extension (URI in method line).  In fact it doesn't control the match at all (which is done based on IP address or From: header); it controls whether or not, once matched, a 401 response is sent if there is no authentication data on the request, but there is on the sip.conf entry.  Extension matching is performed against extensions.conf, not sip.conf.

The subject is misleading, because insecure=very, itself, is now ignored by Asterisk.

By: Walter Doekes (wdoekes) 2013-02-18 15:02:19.956-0600

I don't think you're showing us your entire {{sip.conf}}.

If you did, I think we'd see type=user/friend entries named [100]. And that would present a problem for asterisk:

- is the device calling from (the IP) now [100] or [ext-ats] ?
- let's ask the device to authenticate
- ext-ats will send something, and it probably won't match the CLI (see match_auth_username=yes to fix that)

When the CLI is 1000, asterisk doesn't find a user/friend and will then immediately conclude that the device must be [ext-ats] => now things will work like expected.

By: Matt Jordan (mjordan) 2013-03-07 10:18:16.131-0600

Suspended due to lack of activity. Please request a bug marshal in #asterisk-bugs on the IRC network irc.freenode.net to reopen the issue should you have the additional information requested.  Further information can be found at http://www.asterisk.org/developers/bug-guidelines