Secure SIP? TLS? SRTP? Who needs it anyway?

[PBXMePlz]

Anyone have like a general walk through on setting up TLS and ensuring proper configuration of endpoints?
Part of me feels like I have it figured out, but it would be nice to confirm traffic encryption (I guess I could run a sniffer).

Then there's the fact that some endpoints (see Zoiper), seem to struggle with working at all. FusionPBX has a walk through on how to enable it on the internal side, but I'm kind of hoping for a general top to bottom walk through on securing traffic; if there is such a thing. Or even handy articles pointing me to good reading.

While we're at it, the thought comes to mind, am I working harder than necessary here. Yes I want to be ahead of the curve, and secure, but who's really doing this and why?
Hopefully this sparks some good conversation.

Thanks!

 

[ricktendo]

Go to Status -> Registrations, it will tell you here if the extension is registered with TLS

 

[hfoster]

The supplied scripts that come with the installer should shed a little light.

>Yes I want to be ahead of the curve, and secure, but who's really doing this and why?

Sometimes, when the customer mandates it. We do have to reiterate that only the Handset<->PBX connection can be secured. The PSTN and beyond is definitely not.

 

[PBXMePlz]

The supplied scripts that come with the installer should shed a little light.



Sometimes, when the customer mandates it. We do have to reiterate that only the Handset<->PBX connection can be secured. The PSTN and beyond is definitely not.

My plan was to start providing security by default, and unsecure as the exception. Because why not?

Also and unrelated, but more for context here, turns out the Zoiper thing needed its CID re-entered under the extension for some reason, and then outbound calls started working on that extension. Internal calls are now having weird issues though. See here for reference.

 

[hfoster]

Oh yeh, certainly. The main issue is handsets. If you are going secure by default, be strict on the models and don't let any go out of support/end-of-life.

Otherwise you'll end up tugging your hair out over such useful logs as:

<131>Jul 26 16:09:06 sua [996]: NET <3+error > [255] SSL ERROR
<131>Jul 26 16:09:06 sua [996]: NET <3+error > [255] (null) in (null) (null)

If it weren't for the handsets, it would be fine. As it stands, it's such a minimal security gain compared to doing something more sensible like SSL VPNs, we don't really bother.

 

[PBXMePlz]

Oh yeh, certainly. The main issue is handsets. If you are going secure by default, be strict on the models and don't let any go out of support/end-of-life.

Otherwise you'll end up tugging your hair out over such useful logs as:

<131>Jul 26 16:09:06 sua [996]: NET <3+error > [255] SSL ERROR
<131>Jul 26 16:09:06 sua [996]: NET <3+error > [255] (null) in (null) (null)

If it weren't for the handsets, it would be fine. As it stands, it's such a minimal security gain compared to doing something more sensible like SSL VPNs, we don't really bother.

ok fair point. OpenVPN is pretty easy too all things considered.
And that's exactly the issue I suppose I'm having right now. Softphone to handset, or softphone to different softphone. Would definitely explain this issue.