In contemporary IP network connected devices, encryption is a requirement. Not just on inbound connections for administration, but outbound integrations as well.
Those updates obviously includes adding new protocols when they are new, as well as removing older protocols when they are dangerous to keep using (though there is some wiggle room there if users insist on using insecure crypto if they have dependencies they cannot update). An example of this is adding in TLS 1.3 support (released 2018, some 8 years ago), and removing TLS 1.0 (deprecated by IEFT in 2021). That wiggle room is demonstrated by Microsoft only retiring TLS 1.0 much later (see this).
And while protocols are one thing, we have two other areas:
- Encryption Ciphers
- TLS Certificate Trust Store
The Trust Store is the set of pre-defined TLS Certificate Authorities Root Certificates that your device will trust by default. Depending on the fatures of your device, you may be able to extend this with additional Customer trusted certificate authorities, and potentially disable some of the default trusted CAs.
The Certificate Authority (CA) Root Trust store is often included in the base firmware or software of your computer or device, issued by the manufacturer. They get to chose what Certificate Authorities they will put in here. This gets added into the firmware you download (or is pre-installed).
The challenge here is, like with all TLS Certificates, they have an expiry date, and new ones are being added.
My recent experience with this was a Yealink VOIP/DECT phone system trying to make an outbound HTTPS connection to fetch a centralised address book (“Phone Book”). Yealink defines an XML format that can be placed (or generated) on a webserver, and then fetched by the base station periodically.
However, even with the latest firmware 146.87.0.30 (as at this date), it doesn’t support the ISRG Root X3 certificate, as used by Let’s Encrypt, with a NotBefore date of 2020. and expiring in 2040. Luckily, Yealink supports users adding additional Custom CA certificates to the local trust store. That’s a good work around, but really the internal trust store from the manufacturer should include the current and upcoming CA Root Certificates for all the major worldwide public CAs of strong reputation (those that confirm to the Baseline Requirements of the Browser/CA Forum).
At the same time, its also good to remove the expired Root certificates as a janitorial service. If an older CA is compromised, and local time is badly skewed, then this could prevent an compromise vector.
Vendors should monitor global CAs and watch for their new Root certificates being generated, and add them early to avoid connectivity issued. In “this case with the YeaLink W70B, the only error message was “Connect Error”.
Dear Yealink, see ticket: ID 519067.