Updated 12/21/2018 – Added information about removal of 3DES cipher coming on February 29, 2019.
Updated 1/22/2018 – Added information about forced usage of TLS 1.2 coming in CY 2018.
Updated 3/21/2016 – Added information for SNI support
Updated 6/1/2016 – Added KB article for SNI support
Updated 8/17/2016 – Added information for PCI-DSS 3.1
For a long time in the Lync Server world, Lync Phone Edition phones were the most optimal solution for environments that still required physical handsets on desks or within conference rooms (IMHO). The devices are very simplistic and user friendly, but the down-side is they offer less-than-ideal flexibility and administrative control when compared to Audiocodes or Polycom 3PIP phones. Despite the limitations, many customers accepted the LPE devices as-is and continued deploying the phones if they were required. Microsoft has publicly stated that there is a limited support lifecycle still left on those phones (along with the fact that no new development is being geared towards them) so over time it has made the 3PIP phones much more attractive. As with many things in IT, you discover new information as a result of “breaking something”, and we can officially add one more significant limitation to the Lync Phone Edition list: TLS support.
TLS Background
Almost everything we do is secured using TLS – banking, e-mail, Facebook, Instagram…you get the picture. TLS is the successor to SSL and has gone through several iterations to date:
Most modern browsers and Operating Systems support at least TLS 1.0, which has largely become the baseline standard for encrypting communications on the public Internet today. The newer TLS 1.1 and 1.2 standards include enhancements to include features like Elliptic Curve Cryptography and Perfect Forward Secrecy to make TLS communications significantly stronger, due to the hashes, ciphers, and cipher suites that are utilized. For many companies out there (and indeed the industry as a whole), advancing security is part of business and operational excellence – PCI and FIPS 140-2 are evidence of this ongoing approach to security. Many companies have a strong desire to enhance security and as a result begin to make changes to infrastructure to change TLS configurations to make communications “more secure”. Enter Lync Phone Edition…
Lync Phone Edition TLS Support
Lync Phone Edition is a customized Windows application running on a Windows Embedded CE 6.0 operating system. The Windows CE 6.0 OS was originally released back in November of 2006 – I emphasize that date because much has changed in 10 years since that release. The most important thing to remember though is that any application running on Windows CE 6 is subject to the limitations of the OS platform when it comes to SChannel support…which means that the newer versions of TLS are not available to those devices. What Windows CE 6.0 does support is:
- SSL 2.0
- SSL 3.0
- SSL 3.1 (TLS 1.0)
The other significant limitation to consider are the different cipher suites that are supported within those specific SSL/TLS versions. As of the December 2015 Cumulative Update, Lync Phone Edition offers these ciphers when trying to negotiate secured communication paths with external entities such as Exchange, Lync/Skype, or ADFS:
- TLS_RSA_WITH_RC4_128_MD5
- TLS_RSA_WITH_RC4_128_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
- TLS_RSA_WITH_DES_CBC_SHA
- TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
- TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
- TLS_RSA_EXPORT_WITH_RC4_40_MD5
- TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
Note: There are quite a few very insecure ciphers that are offered in that list – just goes to show how much has changed since November of 2006!
Heightened Security Ramifications
SChannel Cipher Support
Lync Phone Edition doesn’t support anything higher than TLS 1.0. When companies begin a process to harden their infrastructure and remove TLS 1.0 to bolster security (or maybe in preparation for PCI DSS 3.1), you effectively remove the ability of the LPE devices to connect to..well…anything. Consider the following potential scenarios:
- If you alter SChannel on Lync/Skype4B Front Ends to not allow TLS 1.0, LPE devices can’t register.
- If you alter SChannel on Exchange Servers to not allow TLS 1.0, LPE devices can’t access Exchange Web Services.
- If you alter SChannel on Active Directory Federation Services to not allow TLS 1.0, LPE devices can’t authenticate to ADFS to allow access to Office365 services, such as Exchange Online or Skype4B Online.
- If you alter SChannel on Reverse Proxies to not allow TLS 1.0, LPE devices cannot access pool web services externally.
- If you alter SChannel on HTTP proxies to not allow TLS 1.0, LPE devices can’t negotiate a compatible TLS version to allow access to Office365 services, such as Exchange Online or Skype4B Online.
Due to the overwhelming outages that can result from removing TLS 1.0, you are far better off not removing TLS 1.0 support! That is, while you still have the option not to.
SChannel Cipher Suite Support
Another potential path of bolstering security is changing the cipher suites that are utilized within TLS communications.
Using Windows OSs? Nartac software has a great utility called IISCrypto that automatically sets the SChannel registry keys according to PCI and FIPS 140-2 compliance requirements.
Using non-Windows OSs? The weakdh.org website has a great write up that gives you instructions on how to set ciphers and cipher suites according to best practice.
PCI Compliance (PCI DSS 3.0)
If you choose the legacy PCI compliance template within IISCrypto, out of the total cipher suites available, only 2 are supported by Lync Phone Edition (Windows CE 6.0):
- TLS_RSA_WITH_RC4_128_SHA
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
PCI Compliance (PCI DSS 3.1)
If you choose the new 3.1 PCI compliance template within IISCrypto, you effectively remove all capabilities of Lync Phone Edition to connect with your systems. PCI DSS 3.1 requires ‘early TLS’ to be disabled (‘early TLS’ = TLS 1.0). Lync Phone Edition does not support TLS versions higher than 1.0, so this is truly game over regarding the PCI DSS 3.1 standard.
Short Aside:
Many could argue that PCI DSS 3.1 on Lync/Skype systems is a bit over-reaching, and I would definitely agree. Per the PCI Compliance Website, there are four specific areas that the new PCI DSS aims to deprecate TLS 1.0 from being used:
- 2.3 – Encryption for VPNs, NetBIOS, file sharing, Telnet, FTP and similar services that are considered insecure;
- 3 – Encryption for web-based management and other remote (non-console) administrative access;
- 1 – Encryption of cardholder data during transmission over open, public networks; and
- 1.1 – Encryption for wireless networks that transmit cardholder data or connect to the cardholder data environment (CDE)
In most environments, cardholder data isn’t being handled by Skype for Business or Lync Server. That being said, file sharing and transmission of cardholder data could occur in a Skype for Business Server (or Lync Server) implementation so it is still a potentially valid restraint. Most Windows based clients (Vista+) will be capable of negotiating TLS 1.1+, but even though Lync Phone Edition can’t support file sharing or IM transmissions, removing TLS 1.0 support on the server will remove the capability of LPE to connect at all. At that point, your Polycom CX600 is nothing more than a large paperweight.
FIPS 140-2 Compliance
If you choose FIPS 140-2 compliance within IISCrypto, out of the total cipher suites available, only 1 is supported by Lync Phone Edition (Windows CE 6.0):
- TLS_RSA_WITH_3DES_EDE_CBC_SHA
Note: The big difference between FIPS and PCI is the differences in hash support and cipher suite order that is configured within the registry for SChannel.
Server Name Indication Support
Simply put, Lync Phone Edition does not support Server Name Indication because the Windows CE OS doesn’t support it:
You can't sign in to Skype for Business or Lync clients on devices that don’t support Server Name Indication (SNI) https://support.microsoft.com/en-us/kb/2973873
SNI is really tied to extensions within TLS 1.1 so the enhanced feature won’t be available for legacy clients that don’t support TLS 1.1 or higher. As a result of this limitation, be careful when you configure the Web Application Proxy role for ADFS 3.0 due to its use of SNI and the default non-fallback setting. It can be made to operate in a method that will support non-SNI clients, but be careful when making this change if your WAP is handling traffic for non-ADFS entities!
Office365 TLS Support
With much of the computing landscape shifting to the cloud, you must also look at Office365 to determine which TLS services are supported. For Microsoft, they must offer FIPS 140-2 support for their services within Office365 so you can look at SSLLabs to determine which versions and cipher suites are supported:
https://www.ssllabs.com/ssltest/analyze.html?d=sipdir.online.lync.com&s=134.170.54.26
For Lync Phone Edition devices, the only available cipher suite is TLS_RSA_WITH_3DES_EDE_CBC_SHA. This largely matches up what what would be available with on-premises SChannel configurations when deploying FIPS 140-2 security requirements.
Microsoft’s TLS Stance for Office365 – Updated
In December 2017, Microsoft made official announcements that TLS 1.2 will now be a unsupported for connections to Office365 as of October 31, 2018. They have not gone so far as to block TLS 1.0/1.1 but when they do, given that LPE simply doesn’t support TLS 1.2, any LPE device attempting to connect to Office365 will not succeed due to a lack of common protocol. As a result, those devices would be useless as you will be unable to sign in to Skype4B Online, or connect to EWS Online, or integrate with federated partners that use Office365. Your only recourse in that instance is to look at third-party phones, such as the Polycom VVX series, to work around this limitation. Or migrate to the desktop client.
Microsoft’s TLS Stance for Office365 – Updated Again
In December 2018, Microsoft made official announcements that the 3DES cipher suite will be removed from Office365 as of February 29, 2019. Given that LPE uses 3DES as the only common denominator of support between itself and Office365, this means Phone Edition devices will not be able to establish a connection due to the lack of common cipher suite. As a result, those devices would be useless as you will be unable to sign in to Skype4B Online, or connect to EWS Online, or integrate with federated partners that use Office365. This is the death knell foretold of these devices so your only recourse is to look at third-party phones, such as the Polycom VVX series, to work around this limitation. Or migrate to the desktop client.
PCI Compliance (PCI DSS 3.1) – Updated
Microsoft Azure must support PCI DSS standards and does so through PCS DSS 3.1 support. Office365, on the other hand, isn’t explicitly outlined as meeting PCI DSS 3.1 requirements yet it does seem to pass PCI DSS 3.0 requirements (at least from a cursory glance).
The Warning
Bottom line: be very, VERY careful with how you harden your infrastructure when it comes to TLS versions and cipher support. If you go too far, you’ll shoot yourself in the foot and prevent things from working. Additionally make sure you examine ALL potential integration points that the LPE devices will contact, especially ADFS and HTTP Proxy scenarios when integrating with Office365!
Note: TLS 1.1 is available within Windows CE 7, but there has been no public information from Microsoft about updating Lync Phone Edition phones to CE 7. At the current time, the only recourse is to begin migrating from the LPE devices to 3PIP phones, such as a Polycom VVX to get the improved TLS versions, OR begin migrating to the UC client on desktops.