We’ve had quite a few questions this past week because Microsoft/Metaswitch announced that EAS V9.7 will only support TLS v1.2 and above – which effectively prevents the use of a variety of older SIP phone models.
If you’re not sure what this all means, you’ve come to the right place – because we don’t either! Just kidding. You’ve come to the right place, because this article will hopefully explain everything you need to know.
What’s TLS?
Historically, encrypted communications over the internet was performed using Secure Sockets Layer, or SSL. So when you used HTTPS in your web browser, the HTTP protocol was encrypted using SSL (based on an SSL certificate from a Certifying Authority) to encrypt the webpage.
TLS (or Transport Layer Security) performs exactly the same function as SSL, it’s just a more modern (better) protocol – and in fact usually when we talk about SSL these days, we really mean TLS.
The first version of TLS was named TLS version 1.0 (surprise!), but these days there are significant known security holes in TLS v1.0 and TLS v1.1 – so the major browsers will only connect to websites that support at least TLS v1.2.
I’ve been talking about websites, but the same underlying technology can be used for a variety of other uses. You can use TLS to encrypt SIP signaling traffic (sometimes referred to as SIPS), or to encrypt VoIP media traffic (SRTP – Secure Realtime Transport Protocol).
What’s the problem?
In your Metaswitch VoIP network, there are two common places where TLS is used in communications between phones and your core network.
- The HTTPS request sent from the phone to the SIP Provisioning Server, which the phone uses to pull its configuration file. The configuration file includes all the settings available on the phone, including the SIP username and password for registration and the configuration of the various buttons. This config file is pulled when the phone is first deployed and on an ongoing basis (typically every night, or when the phone is rebooted). This is the scenario that is impacted by the recent announcement.
- If you configure the Perimeta SBC to support TLS on an interface (which is less common), then you can configure your phones to use TLS to encrypt both the SIP signaling and the media between the phone and the SBC.
Since TLS v1.1 and earlier is known to have security holes, Microsoft will no longer support TLS v1.0 or v1.1 for the SIP provisioning server after you upgrade to EAS V9.7 (which has a planned release date of May 2024).
Side note: We haven’t seen any announcements about TLS support on the Perimeta, and at the time of writing, the most recent version (V5.3) can be configured to support any of TLS v1.0, v1.1 or v1.2 (although by default it is configured to require TLS v1.2). So the current announcement is NOT about TLS for SIP signaling and media – it’s all about the configuration files that the SIP phones pull from the SIP Provisioning Server.
Therefore, if you use phones that don’t support TLS v1.2 (for the HTTPS request to the provisioning server), these phones will not be able to receive any updates to the phone configuration after the EAS is upgraded to V9.7.
Say that again? What impact will I see if I upgrade the EAS to V9.7?
If you upgrade the EAS to V9.7 and you have deployed various old SIP phones (see below) to your subscribers, then those phones will no longer be able to update their configurations from the central SIP provisioning server. They will continue to make and receive calls without a hitch, but if a user tries to update a button on their phone through CommPortal, or if you try to push a new firmware update to that phone, it will not work.
Which phones are affected?
Rather than duplicate Microsoft’s work, I will simply provide a link to the Metaswitch Communities article (this requires a user account) that provides three lists of phones:
- Phones that do not support TLS v1.2 at all
- Phones that can support TLS v1.2 if you’re running the latest firmware (but older firmware does not)
- Phones that fully support TLS v1.2 on all firmware levels.
What should I do about all this?
In the words of The Hitchhiker’s Guide to the Galaxy… don’t panic. We recommend the following action plan:
- Look at the phones deployed in your network, and compare them to the list of phones that have the problem. Maybe you don’t have an issue at all. You can figure out which phones are in use in your network in a couple of ways – by looking at the Endpoint Packs you’ve installed on your system (through the EAS craft menus) or by running a query on the Shadow Config Database (see appendix below).
- If you have phones in the first group (no TLS v1.2 support), then you should really look at replacing these – they’re all really old, no longer supported by the vendor, and have security holes. I know this could be painful, but that’s really the best solution. Your other option is simply not to upgrade to EAS V9.7 or above. (In theory, you could also stop using HTTPS and switch to HTTP but that’s obviously an awful idea from a security point of view…)
- If you have phones in the second group – where the latest firmware supports TLS v1.2 but older firmware does not – then make sure you upgrade the firmware before you upgrade to EAS V9.7. After you upgrade to V9.7 you will no longer be able to use SIP PS to push out a firmware upgrade. [Note that Metaswitch plans to provide some tools prior to V9.7 that will help you figure out the firmware levels deployed on the affected phones – to help understand the scope of issues in this category.]
I hope this has helped clarify the situation – but if I’ve just made things worse feel free to reply with more questions and I’ll either reply individually or send another email update to everyone!
If you’re an existing client and could use some help digging into this, feel free to reach out to your primary technical contact at Award Consulting and we’ll be happy to help.
Appendix: Shadow Configuration Database query
If you’re familiar with the Shadow Config Database (see here for more info), it’s possible to run a query in there to identify which phone models are in use for different lines on your switch.
SELECT baseinformation_devicemodel, BaseInformation_formattedmacaddress, baseinformation_userdirectorynumber, businessgroupname FROM Meta_ManagedDeviceWe haven’t experimented with this much (yet), but if you’re inclined to dig around in your system the above query would be a good starting point.
