On 29 Oct 2013, at 20:58, Charles Chance <[email protected]> wrote:
> On 29 Oct 2013 17:52, "Olle E. Johansson" <[email protected]> wrote: > > ... > Anyway, this discussion is now outside of the DMQ module and should propably > continue in a general dev meeting. > > > Yes, perhaps slightly out of the original scope now, but very interesting > discussion nonetheless :) > Back to DMQ though, enabling TLS support would be straightforward enough with > a small change to the code. Then in config the user will just have to specify > "sips:..." as the server address instead of "sip:...". > > NO! Don't mix SIPS: into the mix. In the rest of Kamailio we use ";transport=tls" SIPS: is a long a complicated bad story... ;-) > However, it still doesn't provide a way to verify that a received DMQ message > has come from another DMQ instance, and not some other source. > > S/MIME would handle that... ;-) Maybe we need something more simple. TLS will provide client certs which can contain metadata. > To explain a little how the module works - it does not require the user to > provide a static list of nodes at startup. Instead, it need only know about > one other node, from which it can retrieve a full list of other nodes. The > list is then maintained dynamically between nodes, making it possible to spin > up new instances without restarting all the existing ones or having to issue > some kind of reload command on each. > > So back to TLS, unless sessions are restricted to other servers in the > cluster only, any client who is able to establish a connection with Kamailio > is able to forge a DMQ message and currently, it will be processed blindly by > the module. > > Ok, that's no good at all. > Therefore, there still needs to be something within the module itself, a > pre-shared key/secret for example, which enables the node to decide whether > to act on the message or reject it. Once a node is in the shared list, it's > not a problem, but during startup the other nodes will not know about it, so > there needs to be some form of authentication, independent of the transport > layer, I feel. > > A shared private CA signing certs could be one solution. Anyone with a certificate signed by the cluster CA can join. SIP Identity could be used if you don't want TLS. > Am I the one who is overcomplicating things now? > No. I need to take a new look at DMQ. /O > Regards, > > Charles > > > > > www.sipcentric.com > > Follow us on twitter @sipcentric > > Sipcentric Ltd. Company registered in England & Wales no. 7365592. Registered > office: Unit 10 iBIC, Birmingham Science Park, Holt Court South, Birmingham > B7 4EJ._______________________________________________ > sr-dev mailing list > [email protected] > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
