[Freeswitch-dev] Issue with Sofia SIP: username and colons

[Lorenzo Miniero]

2017-06-21 20:49 GMT+02:00 Michael Jerris <mike at jerris.com>:

> We are effectively upstream for sofia at this point, there are a number of
> fixes in our tree that are not in their abandoned tree..
>
>

Yep, I know, but AFAIK there's no repo for Sofia SIP alone, one would have
to grab the whole Freeswitch repo even to just have access to the updated
library, which means I can't just take that and work on it. Same if I
wanted to suggest people to use yours rather than what repos provide (e.g.,
my Fedora 25). Or am I mistaken and there is indeed a way to do that?

L.



> On Jun 21, 2017, at 2:40 PM, Lorenzo Miniero <lminiero at gmail.com> wrote:
>
> 2017-06-21 19:39 GMT+02:00 Michael Jerris <mike at jerris.com>:
>
>> If you can put a patch together I’m happy to review it…. would simplify
>> our code a bit to use that.
>>
>>
> Sure, I'll try to work on one in the next few days. It would be on the
> plain Sofia SIP source code I have available, though, so I hope that's
> ok... shouldn't be too hard to adapt to your fork in case it works fine, as
> I don't expect it to touch much.
>
> L.
>
>
>> On Jun 21, 2017, at 1:20 PM, Lorenzo Miniero <lminiero at gmail.com> wrote:
>>
>> 2017-06-21 18:22 GMT+02:00 Michael Jerris <mike at jerris.com>:
>>
>>> The function in play here is: auc_credentials… note the TODO at the top
>>> of that function…   A new tag that allows for passing those as a structure
>>> is probably needed to do this cleaner without issues.
>>>
>>>
>>
>> Hi Michael,
>>
>> yes, that's the function I had identified as well, when debugging. I
>> agree a new tag (or new tags, as I believe multiple ones would be relayed
>> as well, due to how Sofia SIP works internally) would indeed fix the
>> ambiguity here.
>>
>> Before receiving your answer I also opened an issue on Jira on this:
>> https://freeswitch.org/jira/browse/FS-10415
>>
>> Apologies for the double post, but I wasn't sure my message here had gone
>> through (it had been in a moderated state for a while).
>>
>> Lorenzo
>>
>>
>>
>>>
>>> > On Jun 20, 2017, at 6:24 AM, Lorenzo Miniero <lminiero at gmail.com>
>>> wrote:
>>> >
>>> > Hi,
>>> >
>>> > I'm not sure this is the right place to discuss a potential issue
>>> related to Sofia SIP, especially considering I'm going to describe
>>> something that happens in another software, but I thought that, considering
>>> that Freeswitch uses Sofia SIP as well and has kept it alive so far, it
>>> would be of interest to you guys as well, as you may be affected too.
>>> >
>>> > To give you some context, I'm using Sofia SIP in one of the plugins of
>>> my WebRTC server, Janus. Specifically, this plugin acts as a SIP client on
>>> behalf of WebRTC users, meaning I create NUA instances for them, doing
>>> registers, invites and stuff like that from the server side and exposing a
>>> simpler API and events (not SIP) to users.
>>> >
>>> > This usually works fine, but I recently encountered a weird problem
>>> that can occur when users try to REGISTER and provide a username with a
>>> colon in it. This fails, and apparently the cause is in how the NUTAG_AUTH
>>> works. As you probably know, NUTAG_AUTH is the tag nua_authenticate
>>> requires when answering a REGISTER challenge, and it needs a string that is
>>> basically a colon-separated concatenation of digest/realm/user/pass, e.g.:
>>> >
>>> >     Digest:"nokia proxy":xyz:secret
>>> >
>>> > This breaks when the username contains a colon, as the method that
>>> parses this concatenated string (auc_credentials() in auth_client.c) seems
>>> to do a "brutal" split on the colon character. I tried wrapping the
>>> username in quotes, but that didn't work, which seems to confirm what the
>>> code suggests. Apparently the only way to get Sofia SIP to digest the
>>> username with the colon in it, is escaping the colon (%3A) in there, but
>>> then this obviously results in a broken authentication when it gets to the
>>> registrar, as the usernames differ (ciccio:123 != ciccio%3A123). Some may
>>> argue that it should be the registrar's responsibility to unescape the
>>> username part, but this is a quoted string in the authorization challenge
>>> and not the username part of a URI, so I don't think they're required to do
>>> that.
>>> >
>>> > Is this something you encountered as well? Being more of a SIP server,
>>> I guess this may be seen as less of an issue in Freeswitch, but it might
>>> still occur if/when you're doing active REGISTERs yourself. If it's a known
>>> problem, do you happen to know of any workaround that wouldn't require
>>> patching auc_credentials to do the right thing? (which might be either
>>> changing the delimiter in NUTAG_AUTH to a much less used character, or
>>> automatically unescaping %3A internally when formatting the username).
>>> >
>>> > Thanks in advance for any feedback you may have for me!
>>> > Lorenzo
>>>
>>
>
> _________________________________________________________________________
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> http://www.freeswitchsolutions.com
>
> Official FreeSWITCH Sites
> http://www.freeswitch.org
> http://wiki.freeswitch.org
> http://www.cluecon.com
>
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev
> http://www.freeswitch.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freeswitch.org/pipermail/freeswitch-dev/attachments/20170622/8d9c2da0/attachment.html>