Update: With the Office 365 deadline to have TLS 1.2 enabled being moved from March 2018 to October 2018 we have changed the timing of subsequent post releases; please see below!
Contents
Overview
As the realm of security in technology continues to evolve over time, every so often we say hello to newer and more competent versions of technologies while saying goodbye to their older siblings. By the time you are reading this article you may have learned Office 365 intends to stop accepting inbound network connections if they are using TLS protocol versions prior to TLS 1.2, and started to wonder how this may affect your on-premises deployments of Exchange Server. For clarity, this does not mean your on-premises deployments must disable TLS 1.0/1.1 by the time Office 365’s change takes place. It only means TLS 1.2 must be enabled and used when communicating with Office 365. Today, in part 1 of this series we will provide you with the information required to prepare your environments for using TLS 1.2, as well as, what our plans are during the next few weeks. Part 1: This blog. What you need to be ready for TLS 1.2 being enabled.
ETA: The present, which is now the past
Part 2: Enabling and confirming TLS 1.2 is operational in supported Exchange Server deployments.
Part 3: Disabling TLS 1.0 and TLS 1.1 as well as how to run a TLS 1.2-only Exchange Server deployment aligned with Office 365’s configuration.
In addition to the Office 365 announcement, we know there are customers interested in this topic due to the PCI DSS 3.1 that currently has an effective date of June 30th, 2018. We are seeing an uptick in requests for guidance related to this date and want to assure you we have the guidance underway.
Protocols and Components
TLS versus SSL
Before going further, let us take a moment to clarify TLS and SSL in case they are unfamiliar terms. In the world of Exchange Servers, it isn’t uncommon to think of the TLS protocol (Transport Layer Security) as being involved only in mail delivery processes (“Transport” kind of indicates that). For the SSL protocol (Secure Socket Layer), we most often speak to it when planning for client namespaces and ensuring we’re able to use HTTPS for a secure HTTP session. For example, during the deployment of a new Exchange organization you may hear, “Did you already get the SSL certificate for the new Exchange namespace?” The S in HTTPS does not stand for SSL, it stands for Secure. What really should be asked in the SSL example above is “Did you already get the certificate to enable HTTPS for the new Exchange namespace?” as HTTPS can (and should) be using a TLS based protocol these days rather than an older SSL protocol. TLS can be thought of as the successor to SSL and can be used anywhere two systems must exchange information over an encrypted network session. The Windows Dev Center does a nice job of summarizing this for us here and here.
Additional Components
In addition to the TLS and SSL protocols, there are many other terms that may be useful to cover, which will become more important in later segments of this blog series.
Schannel
Microsoft Exchange Server relies on the Secure Channel (Schannel) security support provider, which is a Windows component used to provide identity repudiation and in some instances authentication to enable secure, private communications through encryption. One of the roles of Schannel is to implement versions of SSL/TLS protocols to be used during client/server information exchanges. Schannel also plays a part in determining what cipher suite to be used.
Cipher Suites
Cipher Suite selection, in addition to the encryption protocol (TLS/SSL) used to carry out information exchanges, is another significant piece of the overall puzzle. Cipher suites are a collection of algorithms used to determine how information exchanged between two systems will be encrypted for key exchange, bulk encryption, and message authentication. As one may expect, different versions of Windows have supported an ever-evolving list of cipher suites made up of different strengths throughout the course of release. If you are a customer accustomed to configuring applications to only use Federal Information Processing Standards (FIPS) compliant algorithms, then cipher suites are nothing new to you.
WinHTTP
Some components of Microsoft Exchange Server rely on Microsoft Windows HTTP Services (WinHTTP). WinHTTP provides a server-supported, high-level interface to the HTTP/1.1 Internet Protocol. WinHTTP enables Exchange to retrieve enabled encryption levels, specify the security protocol, and interact with server and client certificates when establishing an HTTPS connection.
.NET
Last, but certainly not least, is the Microsoft .NET Framework. .NET is a managed execution environment that includes a common language runtime (CLR) that is used as an execution engine and class library which provides reusable code; a vast majority of the code that makes up Exchange Server is written for the .NET Framework. With the release of Exchange Server 2013, our references to the Information Store now being “managed code” or “managed store” were due to its complete rewrite using .NET Framework. Settings for .NET itself can have an impact on how different protocols are used when applications exchange information with other systems. There are many components Exchange Server depends on to properly implement all its encryption capabilities. Understanding what those components are, and how every component should align when adjusting cryptography settings will help you better understand the impact to Exchange Server when those changes are carried out. With those clarifications out of the way let us keep moving on.
How to Prepare
If you would like to prepare your Exchange environments for the upcoming TLS 1.2 configuration guidance, please align yourself by auditing your current deployment against the below set of requirements. No guidance will be provided for versions of Exchange or Windows earlier than what is listed below. By ensuring you are ready for the TLS 1.2 configuration guidance you will minimize the amount of work to enable TLS 1.2 in your environment. Any update called out as ‘current’ is as of the publishing of this article and may not remain true in the future.
Exchange Server versions
Exchange Server 2016
- Install Cumulative Update (CU) 8 in production for TLS 1.2 support and be ready to upgrade to CU9 after its release if you need to disable TLS 1.0 and TLS 1.1.
- Install the newest version of .NET and associated patches supported by your CU (currently 4.7.1).
Exchange Server 2013
- Install CU19 in production for TLS 1.2 support and be ready to upgrade to CU20 after its release if you need to disable TLS 1.0 and TLS 1.1.
- Install the newest version of .NET and associated patches supported by your CU (currently 4.7.1).
Exchange Server 2010
- Install SP3 RU19 in production today for TLS 1.2 support and be ready to upgrade to SP3 RU20 in production after its release if you need to disable TLS 1.0 and TLS 1.1.
- Install the latest version of .NET 3.5.1 and patches.
Exchange Server versions older than 2010
- Out of support. There is no path forward and you should be planning a migration to Exchange Online or a modern version of Exchange Server on-premises.
As always you may refer to the Exchange Supportability Matrix if you need information related to what combinations of Exchange, Windows, and .NET Framework are supported operating together.
Windows Server versions
You cannot have an Exchange server without Windows Server, so don’t forget to make sure you’re in a good place at the operating system level to support using TLS 1.2. Many of the Schannel, WinHTTP, and. NET Framework updates require registry changes to become effective. After confirming the updates below are installed, please do not make any registry changes unless you already have custom settings you must use. We will cover registry changes for these updates in the next part of this series.
Windows Server 2016
- TLS 1.2 is the default security protocol for Schannel and consumable by WinHTTP.
- Ensure you have installed the most recent Monthly Quality Update along with any other offered Windows updates.
Windows Server 2012 R2
- TLS 1.2 is the default security protocol for Schannel and consumable by WinHTTP
- Ensure your server is current on Windows Updates.
- This should include security update KB3161949 for the current version of WinHTTP.
- If you rely on SHA512 certificates; please see KB2973337.
Windows Server 2012
- TLS 1.2 is the default security protocol for Schannel.
- Ensure your server is current on Windows Updates.
- This should include security update KB3161949 for the current version of WinHTTP.
- If you rely on SHA512 certificates; please see KB2973337.
- Exchange 2010 Installs Only: Install 3154519 for .NET Framework 3.5.1.
Windows Server 2008 R2 SP1
- TLS 1.2 is supported by the OS but is disabled by default.
- Ensure your server is current on Windows updates.
- This should include security update KB3161949 for the current version of WinHTTP.
- This should include optional recommended update KB3080079 which adds TLS 1.2 capability to Remote Desktop Services if you intend to connect to 2008 R2 SP1 based Exchange Servers via Remote Desktop. Also install this update on any Windows 7 machines you intend to connect from.
- If you rely on SHA512 certificates; please see KB2973337.
- Exchange 2010 Installs Only: Install 3154518 for .NET Framework 3.5.1.
Windows Server 2008 SP2
- TLS 1.2 is not supported by default.
- Ensure your server is current on Windows updates.
- If you rely on SHA512 certificates; please see KB2973337.
- Exchange 2010 Installs Only: Install 3154517 for .NET Framework 3.5.1.
Why is having current updates helpful?
It may normally go without saying, but by being on a current update you will minimize the risk of encountering any issues while applying a new update as these update paths are tested and well-known prior to the release of the new update. We would like to help you avoid any delay in deploying TLS configuration changes which could arise from battling upgrades from very old Exchange or Windows updates. In addition, with our December 2017 releases for Exchange Server, we’ve already been making underlying changes to prepare for this eventual moment in TLS’ history. Starting with those releases, Exchange setup no longer overwrites the current cryptography settings of the server you’re upgrading. If you have previously configured certain cryptography ciphers and their order of presentation, we will no longer reset them to our desired default configuration. For any new server installations (not an upgrade of an existing server to a new update), Exchange setup will still configure the recommended configuration as of the time the update was originally published. This will also happen if setup is run with /M:RecoverServer as we assume this is the first time Exchange is being installed on the server. If customers prefer a configuration other than our recommended out-of-the-box configuration, then you will still have to apply those updates after installing Exchange Server for the first time on a server. However, once Exchange is installed your custom cryptography config should remain in place after any future Exchange Server update. The Exchange team will continue to publish guidance on which cryptography settings we believe customers should use to optimally configure an Exchange server.
What else have we been up to?
Historically there were many areas within the Exchange codebase where specific cryptography protocols were hard-coded. Over the last few years we have been systematically updating all these areas and slowly converting components over to use protocols and ciphers as dictated by the underlying operating system and .NET. Progress in making these changes was intentionally done in a slow controlled manner over time to ensure stability of the product was not affected. We believe these changes should make administrators’ lives easier by reducing where and how you need to configure cryptography settings for an Exchange Server.
Am I a Server or a Client?
Believe it or not even with Exchange 2016 the acceptance of inbound connections to the Mailbox Server role and the Edge Transport role are not the only purposes a server can have. Exchange Server is often playing the role of a client. Any time Exchange is initiating contact to another system it is effectively a client. Sending mail to another Exchange Server in your org? Client. Contacting O365 for a cross-premises F/B request? Client. Sending mail to a partner organization? Client. Doing a CRL lookup against a CDP so it can show S/MIME certificate status in OWA? Client. Proxying a client request from one Exchange Server to another? Client. Exchange obviously can also play the role of a server, as defined as the party answering a request from another system. Examples include receiving client connections, receiving inbound e-mail via SMTP, or accepting cross-forest requests from another Exchange org. Why does this matter? As you move forward with your configuration changes you must take caution to not move too quickly. Stop and take stock of not only what talks to Exchange, but what Exchange talks to as well. This may mean you have to coordinate changes across multiple environments to ensure you do not suffer any impact to service availability. In the next part of the series you will see configuration changes that refer to both Client and Server aspects of the machine. If you miss one setting you may find yourself with a system making outbound connections on older TLS protocols even though it allows incoming connections to only use TLS 1.2. In part 2 of this series we will discuss how to introduce TLS 1.2 into your environment safely while other servers may still be using TLS 1.0 or 1.1.
Call to Action and Review
Should you be preparing to act?
Yes, we recommend all Exchange Server on-premises customers begin the transition towards using TLS 1.2.
Action Items
If you have not already, then please audit your systems for any updates we’ve outlined above as necessary and begin deploying them to prepare yourself for configuring TLS 1.2.
Review
Keep watching this space for additional information on configuring TLS 1.2, and then additional future guidance on deprecating TLS 1.0 and 1.1 from Exchange Servers. We’re continuing to work with our partner teams across Microsoft to provide you with the best set of guidance and you’ll continue to hear more from us to help guide you through this transition. We hope this first post is helpful in your planning and look forward to releasing the other upcoming parts! A huge debt of gratitude goes to Scott Landry, Brent Alinger, Chris Schrimsher and others for combining numerous efforts of work into this series of postings. Brian Day Senior Program Manager Office 365 Customer Experience.