On 10/06/13 09:32, Daniel-Constantin Mierla wrote:
Hello,
On 6/7/13 11:33 AM, Daniel Pocock wrote:
On 06/06/13 16:35, Daniel-Constantin Mierla wrote:
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
I was just looking over:
http://kb.asipto.com/asterisk:realtime:kamailio-3.3.x-asterisk-10.7.0-astdb
A couple of things I noticed:
- Kamailio is using a column sippasswd which is not hashed. Asterisk
doesn't use that column at all. Is there any reason this can't be done with the H(A1) and H(A1b) columns? The INSERT example shows a non-encrypted password.
you can store hashed value there. In Kamailio is just a matter of config parameter/function parameter to say the loaded value is either plain text or ha1.
Great - are there any interoperability issues with the realm name when using hashes? I presume that as long as the same challenge realm name is configured in Asterisk and Kamailio and when making the hashes it is all OK?
Yes, same realm along same username and password results in same hash.
I also posted a query on the asterisk-users list about support for ha1b
- would you know if that is something that still comes up in practice?
It is in the Kamailio schema, but I have not encountered a device behaving that way in practice.
There are few devices, not remembering any at this moment that use user value in authentication header as being username@domain.
ha1 = MD5(username:realm:password) ha1b = MD5(username@domain:realm:password)
I hope I remembered correctly the order, by you get the idea.
Oddly enough, I almost forgot to mention Lumicall is using the ha1b column.
In Lumicall, it is explicitly configured in the phone settings: authentication username = +41xxxxx@sip5060.net
and it sends that whole value to the SIP proxy in the auth header
To be clear, this was an administrative decision and not a device-specific issue.
- instead of having a ha1b column (which is a hassle for sharing the database with Asterisk or other systems that don't know ha1b), maybe it is also useful to have an auth_user column or to have a flag in the domains table to indicate that the user@domain convention is used for a particular domain?
- in other cases, do people expect this for administrative reasons or solely to support devices that are internally hard-wired to this behavior?
- if Asterisk tries to connect to a TLS proxy, and the proxy has
optional client cert verification enabled, Asterisk tries to send it's cert. There seems to be no way to disable Asterisk sending a cert in this scenario, but the proxy doesn't like the way the client cert is submitted and so it seems impossible to connect to such a proxy.
This was observed with Asterisk 11.4
I haven't played with Asterisk over tls, I used kamailio to bridge tls to udp and then send to asterisk.
I first hit this issue with Asterisk 1.8 I think - ever since then, I've been doing the same workaround with transport=tcp (I found some UDP packets would be too big)