Office 365 to enforce TLS 1.2 per October 15, 2020
Update 21 July 2020
Microsoft has set a new date for the deprecation of TLS1.0 and 1.1, after a previous postponement due to the pandemic. You can find it in the Microsoft 365 Message Center message MC218794, which also references this Docs article.
From October 15, 2020 onward, Microsoft will gradually enforce TLS1.2 on Office 365 services. Note that this enforcement change will take to roll-out to every tenant etc., so you might not see it immediately.
I hope everybody has been working towards this important change since the initial announcement at the end of 2017 and this post from early 2018 (!). I've changed the title of this post to reflect this change, but the URL should stay the same.
Update 5 September 2018
I got confirmation that SMTP also requires TLS1.2, see also this support article. Be sure to check all of you incoming/outgoing SMTP connections. That might be a good time to review those SMTP connections with this and this Microsoft article.
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.
Note: I expect that Office 365 will support TLS1.3 that is still in development, Cloudfare has an interesting blog post about this.
SMTP is still in scope I believe?
Yes, correct. I recently got explicit confirmation for this that SMTP connections are also impacted with this change.
Thanks Dave for the reply. I can see this catching out a lot of orgs.
Exchange Online requirements really need to be added to the list in this kb
Can you comment further on the SMTP connections? We have a complicated O365 environment with over 400 domains in the tenant. Our company is very large and we have hundreds of our businesses in our tenant and close to 100 SMTP connectors. We use SMTP connectors to accept mail from printers/scanners, ERP systems, etc. Looking at the Connector Report in the tenant, we have a significant amount of mail flowing from our connectors that is not using TLS 1.2. Will we need to identify each device sending to our environment via the SMTP connector, and try to force it to use TLS 1.2? This impact of this will be significant as we have a lot of older systems and devices.
Yes, SMTP connections are also impacted by this change.
I have these questions as well: Will we need to identify each device sending to our environment via the SMTP connector, and try to force it to use TLS 1.2?
Yes, as I understand it SMTP is also impacted by this change. However, it kind of depends on you kind of submission. If it could be considered as external mail, I would assume that SMTP could fall back to unencrypted connections. But not for Authenticated (direct send) connections.
Are ADFS Proxy and ADFS connections impacted by this change?
Yes, those where explicitly called out in Microsoft publications. But it should be fairly easy to enable TLS1.2 for those and if not it's probably time to upgrade the OS anyway.
Are you aware of whether or not EOP (Exchange Online Protection) connections are affected? We use EOP to scrub mail before coming into our on-prem exchange server. Currently we receive mail from EOP to our exchange on-prem server using TSL 1.0 or 1.1. We don't route mail back out of our on-prem Exchange server via EOP.
As I've come to understand from Microsoft, yes SMTP is impacted as well. But like I mentioned earlier, I assume that external mail (or deliveries from your devices etc. that are considered by EOP as external) might use Opportunistic TLS, meaning that if TLS connections cannot be made it falls back to lower encryption or no encryption. Not for authenticated submissions though, I would assume those would be TLS1.2 only.
If you see TLS1.0/1.1 and no incoming TLS1.2 connections on your on-prem Exchange server, I would seriously investigate whether the OS and Exchange are ready for TLS1.2. SMTP shares the same TLS configuration as IIS.
I just spoke with EOP support and they have said that support for TLS1.0/1.1 will be ended on October 31st but that it will continue to function until August of 2019 – they will not support customers with TLS 1.0/1.1 issues after the 31st. Have you heard any time lines for when it will actually be deprecated, same month as I was just provided?
Yeah, they clarified the language over time that it's not a hard date but more a support end date (as I'm currently traveling for several weeks didn't really have the time/energy to update my post. Sorry).
Unfortunately I can't give any specific dates and it's possible Microsoft can't either. I assume they will gradually convert to TLS1.2 only when they redeploy servers not via a specific configuration change/update (Microsoft doesn't update Exchange servers, they redeploy them with a new build. There are some Ignite sessions on how they run Exchange Online). So, it would depend on the lifetime of the servers your tenant is using and that could change every now and then (mailbox moves, maintenance switchovers etc. etc.).
That's why I considered the October 31 date as a hard deadline, it's the only thing you are sure about. Maybe not realistic considering how long changes in orgs can take, but on the other hand TLS1.2 is not really brand new.
Looks like Microsoft has updated their support document as there's probably been a bit of a rush of questions lately.
"As of October 31, 2018, Office 365 will no longer support TLS 1.0 and 1.1. This means that Microsoft will not fix new issues that are found in clients, devices, or services that connect to Office 365 by using TLS 1.0 and 1.1.
Note This doesn't mean Office 365 will block TLS 1.0 and 1.1 connections. There is no official date for disabling or removing TLS 1.0 and 1.1 in the TLS service for customer connections. The eventual deprecation date will be determined by customer telemetry and is not yet known. After a decision is made, there will be an announcement six months in advance unless we become aware of a known compromise, in which case we may have to act in less than six months to protect customers who use the services."
Taken from: https://support.microsoft.com/en-ca/help/4057306/preparing-for-tls-1-2-in-office-365
Thanks for this page – very helpful!
I'm surprised Microsoft doesn't have better guidance.
Do you know if an e-mail relay would be affected? Isn't e-mail unencrypted by default?
Also, would a p-roxy that uses 1.2 be an effective work-a-round for the legacy apps that do not support 1.2?
A protocol proxy might work (SMTP for sure, but IMAP and POP might be a bit trickier), but I would focus on getting rid of those legacy apps. It's reasonable to consider that if they do not even support TLS1.2, they might harbor a lot of other security issues. TLS1.2 is not that new.
I know an understand that there are real challenges with some applications and their vendors, especially if they are smaller. And I also know that sometimes there is no choice (healthcare apps for handling specialized machinery for instance), but that is one reason I've tried to warn everyone about this change.
In the long run it's also the better strategy as Microsoft will also disable legacy or basic authentication and will require OAuth on most protocols. https://techcommunity.microsoft.com/t5/exchange-team-blog/basic-authentication-and-exchange-online-april-2020-update/ba-p/1275508
Will tls 1.2 be enabled in outlook 2010?
Thought I responded, but must have gone wrong posting…
TLS connections are handled by the OS, so check the OS. But the extended support for Office and thus Outlook 2010 ended yesterday anyway.
Looking for an appliance that can do Opportunistic TLS without spending a lot of money and a lot of time learning it/
What's everyone using out there?
Anything modern that has SMTP and can handle TLS should be able to support it. Most come in the form of malware/spam filtering solution based on things like PostFix, although those with paid support often craft a GUI on it. Barracuda, IronPort, Messagelabs are some appliances I've seen, but not enough experience to give a full review. I prefer cloud based solutions for mail filtering, so I hardly have current experience. Most of them started on-prem and might still offer solutions.
Will this have any effect on messages that do not use TLS at all? We have an older ERP system that does not support TLS and I am waiting for the day way messages are no longer accepted from it.
It depends on whether the connectors configured receiving it require TLS. If yes, then TLS1.2 is required and other TLS connections (TLS1.0 and 1.1, including some older chiphers) won't be accepted. Only anonymous connections (i.e. other sending mailservers) will still connect to Exchange Online Protection (the whole Opportunistic TLS approach).
My strategy would be to place a Mail Transfer Agent/Appliance or use an on-prem Exchange server between the ERP solution and let that rout to Exchange Online via TLS (or the hybrid mailflow).