Starting October 31st 2018 Office 365 will only allow TLS 1.2

Gold Bar in vault, Museu do Dinheiro in Lisbon. Representing TLS.

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.

Important change

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).

HTTPS

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.

POP/IMAP

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.

SMTP

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.
Mail relaying

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.

Partner connections

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.

14 comments

  • SMTP is still in scope I believe?

    Reply
  • Mark Brashear

    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.

    Reply
    • Yes, SMTP connections are also impacted by this change.

      Reply
    • Tammy

      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?

      Reply
      • 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.

        Reply
  • Paul Marsh

    Are ADFS Proxy and ADFS connections impacted by this change?

    Reply
    • 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.

      Reply
  • Josh

    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.

    Thanks

    Reply
    • 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.

      Reply
      • Josh

        Dave…

        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?

        Regards,

        Josh

        Reply
        • Hi Josh,

          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.

          Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.