[Freeswitch-dev] Issue with Sofia SIP: username and colons
lminiero at gmail.com
Wed Jun 21 18:40:40 UTC 2017
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.
> 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
> Before receiving your answer I also opened an issue on Jira on this:
> 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).
>> > On Jun 20, 2017, at 6:24 AM, Lorenzo Miniero <lminiero at gmail.com>
>> > 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
>> > 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
> Official FreeSWITCH Sites
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the FreeSWITCH-dev