Replacing TLS1.0/1.1 with TLS 1.2 for Office 365

As you may have heard through the grape vine, TLS 1.0/1.1 will be deprecated for Office 365 customers starting October 31st, 2018.

So, what does that mean and why should you care? In this article, we’ll discuss what this means for users of Lync/Skype for Business on-premises and Skype for Business Online and why TLS 1.2 will be mandatory going forward in Office 365. In addition, we’ll look at the first steps you’ll need to take on your AudioCodes SBC to ensure it is ready to support TLS 1.2. So, with all that said, let’s dive right in!

Background

So, what is TLS? To put it simply (or at least try to), TLS is used to secure a device’s SIP signaling connections, whether it be via SIPS (SIP over TLS), Web (HTTPS), Telnet or SSH sessions. This protocol is the successor to SSL and provides confidentiality, integrity and authenticity between two communicating applications over TCP/IP. Microsoft has been toying with us in terms of their TLS 1.0/1.1 deprecation date. Initially Microsoft had said they’d no longer be supporting TLS1.0/1.1 as of March 2018. However, due to continuous backlash from the Microsoft community regarding the very aggressive timeline, Microsoft has agreed to extend support for TLS 1.0/1.1 until October 31, 2018. So why are Microsoft pushing this so aggressively? Well, as of right now, there are no known TLS 1.0 security vulnerabilities within Microsoft’s TLS 1.0 implementation. However, Microsoft has stated that, due to the potential for future protocol downgrade attacks and other TLS vulnerabilities, they have made the executive decision to discontinue the support of TLS 1.0/1.1 in the Office 365 environment. These vulnerabilities can include (but are not limited to) Beast, POODLE, Crime and Heartbleed. This applies to both client-server and browser-server combinations.

Note: Using TLS 1.2 with Office 365 does not mean you must have TLS 1.0/1.1 disabled in your environments by October 31, 2018. If parts of your environment require the use of TLS 1.0 and 1.1 on or after October 31, 2018, you can leave the older protocol versions enabled. However, TLS 1.2 will have to be enabled and used for communication with Office 365 to avoid any interruption in service.

Preparation

In order to best prepare for this upcoming TLS 1.2 change to your Office 365 environment, there are 3 scenarios that you should review and adequately plan and prepare for.
 

1. Lync/Skype client connectivity to Office 365
2. On-premises server integration w/Office 365
3. 3rd party integration with Skype for Business Online

Now let’s discuss what each of these scenarios in a little more detail.

Lync/Skype client connectivity to Office 365

Lync and Skype for Business clients may connect to Skype for Business Online, Exchange Online or both depending on where the accounts for these services are homed (online or on-premises). With that said, you should refer to the table below regarding the three different connectivity scenarios to determine if preparation will be required.

*Although you are not required to prepare for client connectivity scenarios, you still may be required to remediate your on-premises infrastructure if you federate with any customers that reside in Skype for Business Online. This scenario will be covered further in the next section.

You must also ensure that you have the following minimum client versions:

• Lync 2013 (Skype for Business) Desktop Client, MSI and C2R, including Basic 0.5023.1000 and higher
• Skype for Business 2016 Desktop Client, MSI 0.4678.1000 and higher, including Basic
• Skype for Business 2016 Click to Run Require the April 2018 Updates:
  • Monthly and Semi-Annual Targeted – 16.0.9126.2152 and higher
  • Semi-Annual and Deferred Channel – 16.0.8431.2242 and higher
• Skype for Business on Mac 16.15 and higher
• Skype for Business for iOS and Android 6.19 and higher
• Skype Web App 2015 CU6 HF2 and higher (ships with Server)

Lastly, as mentioned with the preceding client remediation, you must ensure that the underlying Operating System (OS) and default browser support TLS 1.2. You can consult Microsoft’s whitepaper here.

Note: Windows 7 does not have TLS 1.2 enabled by default. This means that you will need to enable this for all Windows 7 users if not done already (guidance on this is included in the whitepaper above). Also, the following link will provide you with guidance on TLS 1.2 capability for browsers. https://en.wikipedia.org/wiki/Transport_Layer_Security#Web_browsers

On-premises server integration with Office 365

There are several supported hybrid topologies that are covered with this scenario. This would include integration or Hybrid with: Skype for Business Online or Exchange Online. For a list of all supported on-premises Skype for Business to Exchange integration scenarios, please refer to the link here. Please note, Lync 2010 hybrid scenarios have not and have never been in scope for TLS 1.2 support. Thus, you must plan accordingly to get to a supported hybrid topology (i.e. Lync 2013 hybrid, Skype for Business 2015 hybrid). The table below provides an overview of scenarios where preparation is required as well as where to find additional guidance on said deployment and integrations types.

If you fall under one of the first four scenarios outlined above, you are required to update your on-premises server environment to one of the following versions:

• Skype for Business Server 2015 CU6 HF2 6.0.9319.516 (March 2018 update) and higher on Windows Server 2012 (with KB 3140245 or superseding update), 2012 R2 or 2016
• In-place Upgraded Skype for Business Server 2015, with CU6 HF2 and higher on Windows Server 2008 R2, 2012 (with KB 3140245 or superseding update), or 2012 R2
• Lync Server 2013 CU10 or higher. https://support.microsoft.com/en-us/help/2809243/updates-for-lync-server-2013. Any supported OS for Lync Server 2013 – 2008 R2 – 2012 R2; https://technet.microsoft.com/en-us/library/gg398588(v=ocs.15).aspx

As mentioned earlier, Lync 2010 was never part of Microsoft’s scope to support TLS 1.2. Thus, if you have a Lync 2010 environment it is recommended you upgrade to Skype for Business Server 2015 HF2 6.0.9319.516 or higher. Hybrid or integration scenarios with Office Communications Server 2007 R2 or earlier are not supported. 

• For post CU6 HF2 steps required for SFB Server 2015 – please refer to https://blogs.technet.microsoft.com/nexthop/2018/04/18/disabling-tls-1-01-1-in-skype-for-business-se…
  Post CU10 steps required for Lync Server 2013 are exactly the same as SFB Server 2015.

To talk to one of our experts about Replacing TLS1.0/1.1 with TLS 1.2 for Office 365, 
click the button.

AudioCodes Session Border Controller (SBC) TLS Configuration

Finally, the part that you’ve all been waiting for (seeing as this is an AudioCodes blog)! Let’s say you have an AudioCodes SBC in your environment that you’d like to ensure is ready to support TLS 1.2. Easy enough - let’s go through the initial steps to configure, limit, or change the current configuration on the SBC to cater to those needs. AudioCodes uses TLS Context Tables which are applicable to their gateways and SBC calls. Each of the TLS Context Tables can be configured with the following:

• TLS version (SSL 3.0, TLS 1.0, TLS 1.1, and TLS 1.2)
• Encryption ciphers for server and client – DES, RC4 compatible, Advanced Encryption Standard (AES)
• TLS certificate expiry check, whereby the device periodically checks the validation date of the installed TLS server certificates and sends an SNMP trap event if a certificate is nearing expiry. To configure TLS certificate expiry check, see ''Configuring TLS Server Certificate Expiry Check'' on page 125.
• Online Certificate Status Protocol (OCSP). Some Public-Key Infrastructures (PKI) can revoke a certificate after it has been issued. You can configure the device to check whether a peer's certificate has been revoked, using the OCSP. When OCSP is enabled, the device queries the OCSP server for revocation information whenever a peer certificate is received (TLS client mode, or TLS server mode with mutual authentication).
• Private key - externally created and then uploaded to device.
• Different levels of security strength (key size) per TLS certificate.
• 509 certificates - self-signed certificates or signed as a result of a certificate signing request (CSR).
• Trusted root certificate authority (CA) store (for validating certificates).

Note: The device is shipped with a default TLS Context (ID 0 and string name "default"), which includes a self-generated random private key and a self-signed server certificate. The subject name for the default certificate is "ACL_nnnnnnn", where nnnnnnn denotes the serial number of the device. The default TLS Context can be used for SIP over TLS (SIPS) or any other supported application such as Web (HTTPS), Telnet, and SSH. However, if you create a new TLS Context, you can use it only for SIPS. The default TLS Context cannot be deleted.

Now that we know what settings can be configured within each TLS context table, let’s take a look at how to implement a TLS context table in your environment.

1

2

Click New to add a new TLS Context or Edit to modify the default TLS Context at Index 0; the following dialog box appears (for adding a TLS Context)

TLS Dialog Box

3

Configure the TLS Context according to the parameters described in the table below.

Note: Notice that in the TLS Version parameter you are able to specify which type of TLS you want to advertise.

In the next blog article, we’ll continue our discussion on TLS by explaining how to:

• Assign a CSR-based certificate to a TLS Context
• View Certificate Information
• Assign an externally created private key to a TLS Context
• Generate a private key for a TLS Context
• Create a self-signed certificate for a TLS Context
• Import certificates into a Trusted Certificate Store