[Freeswitch-dev] Issue with Sofia SIP: username and colons
mike at jerris.com
Wed Jun 21 16:22:14 UTC 2017
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.
> On Jun 20, 2017, at 6:24 AM, Lorenzo Miniero <lminiero at gmail.com> wrote:
> 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!
> Professional FreeSWITCH Consulting Services:
> consulting at freeswitch.org
> Official FreeSWITCH Sites
> FreeSWITCH-dev mailing list
> FreeSWITCH-dev at lists.freeswitch.org
More information about the FreeSWITCH-dev