PSA: Ticking TLS (1.2) Time Bomb for Office 365

Office 365, Skype for Business

Introduction

I thought I would write a post to remind people that Microsoft will be switching off TLS 1.0 and 1.1 for their Office 365 services. It was originally meant happen in March 2018, then October 2018, but has now been pushed back to a later date.

If you don’t have Office 365 services you won’t be affected by this, but I would still advise migrating away from the older specifications of TLS where possible. If you do have Office 365, prepare for the change so the nightmares don’t become real on Halloween!

Let’s go over:

  • What is TLS?
  • What version we should be using (and how its determined)?
  • Are you ready for the change?
  • Is it wise to disable TLS 1.0 and 1.1?

What is TLS?

Let’s start from the beginning. Before there was TLS, there was SSL (Secure Socket Layer) and before that there was no real encryption standard used en-mass. SSL became part of a wider ranging protocol known as TLS (Transport Layer Security). TLS is effectively a layer of security that sits on top an existing transport protocol - for example HTTP. Adding TLS to HTTP, it becomes HTTPS - but the HTTP protocol remains the same. By adding TLS to a transport protocol, if a third party intercepts the data, they can see the source and destination IP addresses (and ports), but crucially not the data/payload itself e.g. HTTP traffic.

One (specification) to rule them all

Currently there are three complete specifications (versions) of TLS - 1.0, 1.1 and 1.2 (1.3 is still draft and incomplete). TLS 1.0 and 1.1 (along with SSL) are now known to have critical vulnerabilities in them that could allow a third party to intercept encrypted data. This poses a security risk. As the current specification TLS 1.2 is less compromised, it is the preferred specification to use. Because of this, Microsoft is keen to stop using TLS 1.0 and 1.1 in Office 365.

What’s the problem?

Well let’s all just use TLS 1.2, what’s the big deal!? Hold your horses. Microsoft has put together a handly article detailing what clients/software might be impacted when it only uses TLS 1.2 in Office 365. Let’s break their list down:

  • Android 4.3 and earlier versions - Android 4.3 came out in 2013. Most companies I’ve worked at look to replace their mobile devices every couple of years, so I don’t see this being a massive issue for most. If your users are using Android 4.3 or earlier, now may be a great time to force a device refresh.

  • Firefox version 5.0 and earlier versions - Firefox 5.0 was released in 2011, so I don’t expect many users to still be using such an old browser. If your users are, it might be time to push out a newer version. For what it’s worth, I believe version 27.0 was the first to have TLS 1.2 support, not 5.0.

  • Internet Explorer 8-10 on Windows 7 and earlier versions:

    • IE8 is unsupported on all platforms.
    • IE9 is unsupported on all platforms.
    • IE10 is not supported on Windows 7 or earlier (supported on Windows 8).
    • What they don’t tell you is, these are the default settings. You can still enable TLS 1.1 and 1.2 on Windows 7 for use in IE 8-10. If you install IE 11 on Windows 7, it even enables TLS 1.1 and 1.2 for you, so not an OS limitation.

  • Internet Explorer 10 on Win Phone 8.0 - It looks like you would need to upgrade your phone to Windows Phone 8.1 to be supported. Much like the version of Android mentioned, its quite a few years old at this stage, I can’t see many users having a mobile device this old.

  • Safari 6.0.4/OS X10.8.4 and earlier versions - Safari 6.0.4 and OS X 10.8.4 released in 2013, so again, I suspect there is minimal impact here, but worth mentioning - time to upgrade!

Also mentioned in the article is some builds of Windows 7 using WinHTTP. If an application or service relies on WinHTTP to function (e.g. Outlook), you may need to update your preferences to make TLS 1.2 the default protocol for WinHTTP. Details on how to patch it are here. (You either need to apply a registry key or run install a Windows Update).

What’s not mentioned?

Other Browsers and OS combinations

Microsoft has listed some affected browsers but it misses the most used browser in the world - Google Chrome! Using the massive table on SSL/TLS support in browsers from Wikipedia and other information, I’ve put a little table together outlining the minimum versions needed for TLS 1.2.

Note: I have not tested all the following combinations, so I would use this as a reference rather than relying on this information.

**Chrome** **Android Browser** **Firefox** **IE 8** **IE 9** **IE 10** **IE 11** **Edge** **Safari**
_Windows 7_ From v29 N/A From v27 Disabled* Disabled* Disabled* Yes N/A N/A
_Windows 8_ From v29 N/A From v27 N/A N/A Disabled* N/A N/A N/A
_Windows 8.1_ From v30 N/A From v27 N/A N/A N/A Yes N/A N/A
_Windows 10_ From v29 N/A From v27 N/A N/A N/A Yes Yes N/A
_OS X_ From v29 N/A From v27 N/A N/A N/A N/A N/A From OS X 10.9
_iOS_ From v29 N/A From v27 N/A N/A N/A N/A N/A From iOS 6
_Android_ From v29 From v5 From v27 N/A N/A N/A N/A N/A N/A
_* Although disabled, TLS 1.2 support can be enabled under settings._

Whilst not mentioned above, the general rule of thumb for the server versions are:

  • Windows Server 2008 and 2008 R2 = Windows 7
  • Windows Server 2012 = Windows 8
  • Windows Server 2012 R2 = Windows 8.1
  • Windows Server 2016 = Windows 10
Lync Phone Edition

Lync Phone Edition does not support TLS 1.2. Microsoft have officially announced that Lync Phone Edition will no longer be supported. Time to upgrade if you have any!

Plan of action

Ensure TLS 1.2 is negotiated in the browser

Checking TLS 1.2 is used in browsers is pretty straightforward.

Navigate to the Office 365 Portal (https://portal.office.com) and then check the certificate. How you do this differs from browser to browser:

IE - Right click on the page and select Properties. It should be listed under Connection:

(It’s IE11 in this case, so TLS 1.2 is used)

Firefox - Right click on page and select View Page Info. Click Security and it should be listed under Technical Details:

(This version of Firefox is up-to-date, so TLS 1.2 is used).

Chrome - Right click on page and select Inspect. On the console, navigate to the Security section. It should be listed under Secure connection.

(This version of Chrome is up-to-date, so using TLS 1.2).

As you can see, all my browsers are up-to-date, so no real concern with the older versions of TLS being disabled in Office 365.

Just to demonstrate, I’ve fired up a brand new vanilla Windows 7 installation with no updates or service packs applied. Opening the same page in IE 8 yields this:

In this example I would be affected and would either need to upgrade to IE11 or enable TLS 1.2 in the IE settings.

Checking TLS 1.2 is negotiated in other applications

We’ve checked the browsers, but what about other applications e.g. Outlook?

This is where the trusty Network Monitor 3.4 comes in. One benefit of this over Wireshark is the ability to look at traffic per process (application) which is very useful in this scenario.

Let’s break down how you can see what version of TLS is being used. As part of the TLS handshake process there is a “Client Hello” sent from the client e.g. Outlook to the server e.g. Exchange. The “Client Hello” details among others things what version of TLS it would prefer to use and what cipher suites it has available (in preferred order). The server then replies with a “Server Hello” where it details what version of TLS and cipher suite it has chosen to use. The server can choose to use TLS 1.0, 1.1 or 1.2. As long as the client supports the version offered, the handshake will continue. It is similar to SDP negotiation in SIP, both clients will list their preferred options in the SDP and as long as there is something in common, it will proceed. If you want to get in to the details of TLS, the RFC5246 is worth a read.

Let’s now look at a “Server Hello” from Exchange Online for Outlook 2016:

We can see here that the handshake is indeed using TLS 1.2 as expected.

Now lets look at one on using the same Exchange account on a vanilla Windows 7 installation with Outlook 2010 SP2. I suspect not many users connect to Exchange Online using Outlook 2010, but I like to test some edge cases:

The client chose to use TLS 1.0, the server (Exchange Online) accepted it and we are using TLS 1.0. Uh-oh! Once TLS 1.2 is enforced, this connection would fail.

Let’s try again with Windows 7 SP1 and all updates installed (including KB314025 patch to WinHTTP), again using Outlook 2010 SP2:

Hmmm, still the same. I checked the registry the values haven’t been created as per the hotfix. Let me apply the “Easy Fix” instead, this time they are in the registry. Let’s try again:

Bingo! This time the request is using TLS 1.2. If you are going to use Windows 7, double check that WinHTTP is patched correctly!

Disabling TLS 1.0 and 1.1

With Microsoft choosing to only TLS 1.2 on Office 365 does not mean you also need to disable TLS 1.0 and 1.1 on your clients. Whilst this something to aim for (maybe you have to become PCI DSS compliant), other services or applications might rely on them still. Before you rush to disable these, you need to be certain that nothing else communicates with use TLS 1.0 or 1.1. Maybe there is an old CRM server still used by handful of users that you forgot about? Maybe there is an admin page for a firewall or router that doesn’t support TLS 1.2? Whilst you can re-enable TLS 1.0 and 1.1, you ideally want to know when you do disable them you are not going to impact users.

Luckily using Network Monitor again, we can try and find some culprits still using TLS 1.0 or 1.1. If you start a trace and apply the following filters, you can see if any traffic is found. We are looking for “Server Hello” replies with TLS 1.0 or TLS 1.1 as the chosen version:

Filter TLS 1.0 traffic:

TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ServerHello.Version.Major == 0x3 AND TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ServerHello.Version.Minor == 0x1

Filter TLS 1.1 traffic:

TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ServerHello.Version.Major == 0x3 AND TLS.TlsRecLayer.TlsRecordLayer.SSLHandshake.HandShake.ServerHello.Version.Minor == 0x2

I’ve applied the first filter against “All Traffic” and purposely browsed to Office 365, other websites and an old Exchange 2010 server I know still uses TLS 1.0 only.

The only result is the old Exchange 2010 server. Note: The “Client Hello” sent out a TLS 1.2 request, but as the server only supports TLS 1.0, that was used instead.

Using these filters applied to a users machine going about their day-to-day work could be useful. It could possibly highlight some applications or services on the client that you didn’t realise were still using TLS 1.0 or 1.1.

Recap

So to recap:

  • If you are using Office 365, ensure all your clients, browsers, phones etc. are updated to support TLS 1.2 before Microsoft only support TLS 1.2.
  • Lync Phone Edition will no longer work.
  • If using Windows 7 you can still use TLS 1.2, but you need to make sure it has KB3140245 applied to allow WinHTTP to use TLS 1.2 (in my case I had to apply the “Easy Fix”). If using IE 8-10, you also need to enable TLS 1.2 in the settings. Ideally you should be looking to migrate to Windows 10 though!
  • If you want to disable TLS 1.0 or 1.1, using Network Monitor we can check applications or services aren’t using them before we disable them.

Hope this helps someone. If I’ve missed anything or made an error, please let me know.