[asterisk-dev] [Code Review] 2554: Pimp my SIP: alwaysauthreject

[Olle E. Johansson]

7 jun 2013 kl. 14:37 skrev Matthew Jordan <mjordan at digium.com>:

> On 05/25/2013 02:15 AM, Olle E. Johansson wrote:
>> 
>> 24 maj 2013 kl. 23:39 skrev Kevin Harwell <reviewboard at asterisk.org
>> <mailto:reviewboard at asterisk.org>>:
>> 
>>> Adds support for 'alwaysauthreject' to the new SIP channel driver.  When the 'alwaysauthreject' option is set to 'yes' (default) and no matching endpoint is found for the incoming request, after challenging, Asterisk will respond with a 401 Unauthorized regardless of the reason it rejects the request.
>>> 
>> Alwaysauthreject was a fix for a bug that existed in asterisk. We had to
>> keep the old behaviour being afraid of breaking stuff out there.
>> 
>> Why are we replicating the bug and the fix in a *new* channel driver? It
>> doesn't make much sense. We have no old versions of this channel driver
>> that's broken in production anywhere.
>> 
>> Are there any use cases for discovery of sip accounts by getting a 404
>> for non-existing accounts?
>> 
> 
> Forgetting for a second the current alwaysauthreject setting and how it
> came to be...
> 
> As I understand it, the goal for Asterisk should be to prevent a
> malicious attacker from enumerating valid endpoints in its SIP stack. If
> I'm said malicious attacker, and I send a request for 1000, then 1001,
> then 1002, etc. - I should get back the same responses for each
> particular endpoint - even if they exist.
> 
> In general, if 1001 existed and 1002 did not exist - and we had no
> setting to control this behaviour - then I would get a 401/403 (assuming
> they didn't have the correct authentication) for 1001 and a 404 for
> 1002. I would thus know that 1001 existed.
> 
> The proposal is to always send the 401/403 pair when some setting is
> enabled as opposed to the 404 response. I think Asterisk providing some
> mechanism to make the responses all look the same is a useful security
> setting, regardless of what we call it.
> 
> Is there a reason we shouldn't be doing this?

401/403 ==> 401/407 - right?
Asterisk is an end point and should never send a proxy authenticate, so please don't copy that part of the code.

I asked if there are any use cases for getting a 404 above.  I don't think so. 

The new channel driver should not have an option to turn it on in my opinion - which is why
I think the code in the code review should not be committed. 

Now, I would like to see a document that is readable that describes the object matching in chan_pjsip.
Start with a request coming in and how that is matched with the object model and configuration file.

Let's make a solid foundation this time and not the mish-mash we've built during more than 10 years
of chan_sip hacking ;-)

/O