Office 365 will allow TLS 1.2 only starting October 31st 2018
Update 10 February 2018*
So, Microsoft announced a new date for this change and updated their support article regarding TLS support. It’s now October 31st 2018, instead of March 1st 2018. This gives organizations a lot more time to prepare for this change. IMHO the previous date was maybe a little too ambitious. It seems that Microsoft got enough feedback to push back the date.
Even earlier the Exchange Product Team posted an article in a series of three, detailing how to prepare your environment. The first part can be found here: Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2
Unfortunately, I don’t have anything to share yet regarding SMTP. But we’ve got a few more months. I still suggest you go ahead and check your environment whether the relevant parts have the capability to use TLS1.2.
Microsoft announced an upcoming change for secure connections in a support article last updated 19th December 2017. Office 365 will only initiate and accept connections secured by TLS 1.2 (Transport Layer Security) only as of March 1st 2018. There will be no support for older TLS versions 1.0 and 1.1. This is a pro-active measure before any possible downgrade attacks that might will pop-up in the future.
Microsoft warns that client-server and browser server combinations must use at least TLS1.2. Most connections to Office 365 already use TLS1.2 according to Microsoft. The change also impacts any on-premises architecture such as Active Directory Federation Services (ADFS) and Exchange Hybrid. These would require inbound and outbound TLS1.2 connections. You do not have to disable TLS1.0/1.1 on your on-premises environment. When you disable TLS 1.0 or 1.1 you might result into issues. Being up-to-date with software that is still in support is important. Check whether TLS1.2 is enabled after updates.
In another article Microsoft explains a little bit what the impact might be regarding different Windows OSes. The article does not explicitly mention non-Microsoft solutions that connect with Office 365. I fear some of those solution will not be checked. The longer I thought about those scenarios, I got a little bit worried that some organizations might run into issues when this change comes into effect. The support article does not specify any particular protocol. Therefore I assume that every protocol is affected. I can think of HTTPS, POP/IMAP and SMTP when regarding Exchange Online. I will only focus on these protocols. That doesn’t mean other protocols or services might have some impact specifically for that service (Skype for Business Online for instance).
Most solutions (like applications, devices, SaaS) use the HTTPS protocol to connect with Office 365, such as Exchange Web Services (EWS) or Microsoft Graph. I know of some Java or other platform based applications. It is feasible that they run on older versions that do not support TLS1.2 or need to actively enable it. Check every of those applications whether are already compliant. You might have to update the platform first, which could in turn break stuff and require some updates. I suggest you check your business critical applications as soon as possible. Doing so might give you enough time to prepare and hopefully prevent downtime. Also check any application or appliance that connects to Office 365, things like a room manager display for instance (my employer uses them for every bookable room). You might have to update the firmware.
If you are stuck with solutions that will not support the new security requirements you will have to consider workarounds. This could be something like a caching proxy that is able to create HTTPS TLS1.2 connections for the internal solutions that can’t. This is something that probably require some configuration and testing in your environment.
I know there are applications or appliances that still use this in order to extract data from mailboxes. As these are old protocols, some applications might not even support any form of secure POP/IMAP, let alone TLS1.2. Check those applications and check whether they (after updating) perhaps support more modern solutions based on HTTPS like EWS. A more modern protocol might also mean a more modern approach towards encryption such as supporting TLS1.2.
I found SMTP especially an interesting protocol within the security change context. You have to check several uses:
- Applications/appliances that send mail directly via Office 365 to users or other organizations: Mail relaying.
- Incoming and outgoing mail from partners that require secure transport: Partner connections (Mandatory SMTP, Mutual TLS).
- Incoming and outgoing mail from and to unknown organizations: Opportunistic TLS SMTP.
Check your applications/appliances that use SMTP to connect to Office 365, because they might require firmware or software updates to support TLS1.2. If the supplier has failed to support it at this time, you might have to contact them. You can use an relaying SMTP that does the direct connection to Office 365. You might have to plan, design and implement some necessary infrastructural changes that also might add costs.
If you have connections set up with partner organizations to ensure that SMTP transport is encrypted, your mail flow to that partner might fail. You have to contact your partner organization and warn them of the impending change so they can check and prepare. They might have to consider alternatives that do work within the new security reality.
Are they using Office 365 or even just Exchange Online Protection (EOP) the change obviously won’t be a problem. But if your partner organization uses another cloud solutions for the SMTP partner connection, let them check whether they support TLS1.2. If not, they have to contact their provider in time or switch.
To be clear, we are talking about the first connection point from your Office 365 environment to their organization. This is sometimes different from their MX configuration.
Opportunistic TLS SMTP
The change could impact all incoming or outgoing mail. Opportunistic TLS is the principle that for the incoming or outgoing SMTP connection is attempted first with an encrypted connection. Mail servers use non encrypted connections when no encryption is possible.
The need to fallback to older or no layer security is quite common with SMTP connections. Due to lazy admins, misconfigurations, “it’s always done this way and we rather have mail at all than have it transported securely”. Preferably every SMTP connection uses some form of encryption, but this is just the way it is and we have to accept it.
Create a partner connection if you really require a guaranteed secure mail flow with some of your partners. But remember the caveats from the previous paragraph.
I have asked Microsoft some clarification regarding SMTP. There are very valid reasons to still allow TLS1.0/1.1 for SMTP connections. When I get a reaction I will update this post. It is technically possible that SMTP is the exception to this new support statement. But I will not assume this.
How to check?
How do you if there are any issues? It highly depends on your infrastructure. You need access to OSI model Layer 7 in order to inspect the TLS version. Check connection logging available. Use OpenSSL tools to check whether TLS1.2 is available. Use Fiddler to monitor whether TLS1.2 connections are actually used. I’ve written a blog post two years ago on how to check your connections.
When you know which connections still aren’t able to leverage TLS1.2, you have some work to do.