cwernstedt Posted May 26, 2023 Report Share Posted May 26, 2023 Hi, I have a requirement such that no calls can take place unless all involved protocols and traffic are encrypted using up-to-date protocols (e.g., TLS 1.2) Old devices/endpoints with configs that don't adhere should stop working. What would be appropriate settings to make sure that this is the case? (In 2023 it is no longer acceptable to have no guarantees on the PBX with regard to secured links, just like most web pages now prevent the use of non TLS requests.) Best, Christian Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 26, 2023 Report Share Posted May 26, 2023 There are a few things you can do here. First of all, you should set the minimum TLS version to 1.2. This is actually required by most browsers today. The next thing you can do is to clear the ports for SIP/TCP and SIP/UDP. Then there will be no SIP without TLS. You might also clear the HTTP port and leave only the HTTPS port open. Same for LDAP and LDAPS. If you don't have the HTTP port available, you must use your own certificate (Lets Encrypt needs port 80 to be open). Alternatively you can leave HTTP port 80 open and set up the firewall to accept traffic only from the Lets Encrypt servers—though it remains a question what IP addresses it is coming from. As for SRTP, there are various settings for the devices that you use to enforce SRTP. E.g. you can use the snom General parameter to enforce SRTP. The apps all use SRTP and TLS anyway, there is not even an option to do it insecure. It will need some tinkering to make sure that everything really works, but at least you can rule out unencrypted traffic is on the server. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted May 27, 2023 Author Report Share Posted May 27, 2023 Thank you for these suggestions. "As for SRTP, there are various settings for the devices that you use to enforce SRTP. E.g. you can use the snom General parameter to enforce SRTP. The apps all use SRTP and TLS anyway, there is not even an option to do it insecure." It seems SRTP is the biggest "hole" right now with regard to enforcement of encryption at the server. (A user knowing their SIP credentials could connect a misconfigured or malfunctioning device and use unencrypted RTP = nightmare in a corporate IT security context). It would be an essential security feature if the server could detect such connections and not accept them. Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 28, 2023 Report Share Posted May 28, 2023 On 5/27/2023 at 4:22 AM, cwernstedt said: It would be an essential security feature if the server could detect such connections and not accept them. We made that a priority ten years ago, e.g. added a feature so that secure calls can also be terminated over a seemingly insecure SIP trunk. For example when a PSTN gateway is connected through its own Ethernet cable to the PBX, this could be deemed secure. But the feedback was a little disappointment, in a nutshell nobody cared. The solution to disable all non-secure ports and force the phones to use SRTP through a general parameter seems like a workable solution for now. We don't have to change anything in the PBX, and this is an easy parameter setup that should address your requirements. Quote Link to comment Share on other sites More sharing options...
cwernstedt Posted May 30, 2023 Author Report Share Posted May 30, 2023 On 5/28/2023 at 6:14 PM, Vodia PBX said: We made that a priority ten years ago, e.g. added a feature so that secure calls can also be terminated over a seemingly insecure SIP trunk. For example when a PSTN gateway is connected through its own Ethernet cable to the PBX, this could be deemed secure. But the feedback was a little disappointment, in a nutshell nobody cared. It is arguably a different world today when few have local PSTN gateways and most traffic happening over the Internet. Eavesdropping on the Internet or public WiFi (if using soft phone) is a much bigger threat than local packet sniffing. So today, if admins don't think they need the servers' assistance with ensuring encrypted links at all times, they are insane. There's an interesting discussion here about detection of encrypted vs non encrypted RTP: https://www.twilio.com/blog/srtp-deep-dive Twilio for their SIP trunks has an option to enforce SRTP and TLS for SIP, so since we use them for trunks at least we are covered in that regard. On 5/28/2023 at 6:14 PM, Vodia PBX said: The solution to disable all non-secure ports and force the phones to use SRTP through a general parameter seems like a workable solution for now. We don't have to change anything in the PBX, and this is an easy parameter setup that should address your requirements. You mean a general parameter on the phones, such as setting "RTP Encryption" to ON on a snom phone? Is there a way to check that phone settings are working correctly, except by sniffing packets and looking for, for example, "digital silence" as described in the link above? Quote Link to comment Share on other sites More sharing options...
Vodia PBX Posted May 30, 2023 Report Share Posted May 30, 2023 28 minutes ago, cwernstedt said: You mean a general parameter on the phones, such as setting "RTP Encryption" to ON on a snom phone? Is there a way to check that phone settings are working correctly, except by sniffing packets and looking for, for example, "digital silence" as described in the link above? The good news is that the phones have that setting that really enforces SRTP. You can essentially rely the setting. Plus if your SIP trunk provider enforces it as well, you should really be good. There are many ways that trust can be broken. For example, if Twilio accepts SRTP and terminates the traffic to a route that just records anything and sells it to the highest bidder, you would not even know about it. There's nothing you can do about it, realistically. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.