[sr-dev] DMQ security

Jan Janak jan at janakj.org
Tue Oct 29 18:40:25 CET 2013


On Tue, Oct 29, 2013 at 12:03 PM, Olle E. Johansson <oej at edvina.net> wrote:
>
> On 29 Oct 2013, at 16:58, Jan Janak <jan at janakj.org> wrote:
>
>> On Tue, Oct 29, 2013 at 11:29 AM, Olle E. Johansson <oej at edvina.net> wrote:
>>>
>>> On 29 Oct 2013, at 13:38, Charles Chance <charles.chance at sipcentric.com>
>>> wrote:
>>>
>>> I agree with Olle that the common "pass the buck" attitude is wrong,
>>> although in this case I don't believe securing the messages should be
>>> mandatory. Often the communication between servers will be over a
>>> private/secure network and the user should be allowed to disable it if they
>>> deem it an unnecessary overhead.
>>>
>>> Is that another myth - the secure/private/inside network? :-)
>>
>> Have you heard of IPsec?
> It doesn't happen by default... But yes it's an alternative. The people that use
> IPsec is not the ones I'm worrying about.
>
>>
>>> Either way, the ability to use TLS where required is a definite must, so
>>> I'll go away and look into that now.
>>>
>>> At least write the documentation so that most people believe that they have
>>> to have TLS and work hard to disable it :-)
>>
>> I am not convinced this is the right documentation style. I think
>> documentation should be balanced, it's IMHO better to explain what
>> options are available and not force a particular security mechanism
>> down people's throat.
>
> Well, we've been at this for many years and still all of us have a very
> limited number of installations using security mechanisms we have.
>
> Why is that? I don't think that it's because they use IPsec. ;-)

Are you concerned about client-to-server or server-cluster scenarios?

I was mainly pointing out that TLS is not necessarily the first choice
when it comes to securing communication in server clusters, which is
AFAIK where the dmq module is meant to be used. And in this particular
case I'm not sure if making it hard to disable is the right choice.

Client-to-server scenarios are a different story, of course.

-Jan



More information about the sr-dev mailing list