10 Jun
2013
10 Jun
'13
10:32 a.m.
Hello,
On 6/7/13 11:33 AM, Daniel Pocock wrote:
Great - Google searches for "Asterisk Kamailio" or even "Asterisk
11
Kamailio 4" still return the old page, so maybe it is still useful to
link the pages
I will add that next time I get a chance.
As you can imagine, I've played with a few variations of this against repro
I've noticed that it isn't so straightforward, here are some issues
(Asterisk faults, not proxy issues):
- Asterisk doesn't automatically use it's bind IP:port for outgoing
connections to the proxy - so proxy ACLs are tricky to set up if the
Asterisk host has multiple IPs
- 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.
Cheers,
Daniel
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
Kamailio Advanced Training, San Francisco, USA - June 24-27, 2013
* http://asipto.com/u/katu *
On 06/06/13 16:35, Daniel-Constantin Mierla wrote:
Yes, same realm along same username and password results in same hash.
Hello,
On 6/6/13 11:05 AM, Daniel Pocock wrote:
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? 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. 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.
- Is it all considered valid for Kamailio 4 and
Asterisk 11? (maybe a
disclaimer could be added at the top)
There is another one for K4.0 and A11:
-
http://kb.asipto.com/asterisk:realtime:kamailio-4.0.x-asterisk-11.3.0-astdb
Not many changes and apparently there are newer updates in asterisk
database structure on latest RC of 11.3.x.
- The Asterisk columns `md5secret' and
`secret' are left empty so that
Asterisk won't challenge. I believe there are other ways of doing this:
for example, telling Kamailio to be the registrar and forcing Asterisk
to use outbound proxy mode. I managed to make this work against repro -
Asterisk no longer receives any REGISTER messages, but all INVITEs go
through Asterisk, so the double-challenge problem only arises for
INVITEs. Maybe Asterisk can be told that Kamailio's source IP:port is
`trusted' and doesn't need to be challenged - is anybody aware of such
an option in Asterisk?
There are various ways of doing it, this particular one
tried to be at
least intrusive as possible in asterisk, not to require changing a
deployed asterisk configuration.
For a new deployment, other approach is more recommended, using
kamailio as outbound proxy.