Enabling TLS 1.1 and 1.2 in Outlook on Windows 7

Happy Friday everyone!

I was recently on site with a customer in the financial services industry, and as any of you familiar with PCI DSS probably already know, there has been talk of disabling TLS 1.0 for quite some time.  The original deadline was June 30, 2016, but this has been extended until June 30, 2018.  For those of you not involved in PCI, there is still the BEAST attack against TLS 1.0.  🙂

Working with this customer in support of a hardware load balancer deployment, their Outlook clients (OL2013 on Windows 7) could not connect to Exchange (EX2013 on Windows 2012 R2) through the load balancer (F5 LTM).  Autodiscover and Outlook Anywhere were both broken.  However, accessing the Exchange load balancer URLs (/owa and /autodiscover/autodiscover.xml) via Internet Explorer on the same Windows 7 clients worked fine, and Outlook on a test Windows 10 VM also worked just fine.

We fired up Fiddler on the Win7 client and noticed that the Outlook connection was attempting to use TLS 1.0 (which was odd, since Windows 7 supports TLS 1.1 and 1.2), and that Schannel was returning error 0x80090326 (SEC_E_ILLEGAL_MESSAGE).  This Schannel error maps to several TLS protocol alerts, so we fired up Wireshark and noticed TLS alert 0x40, which is SSL3_ALERT_HANDSHAKE_FAILURE (don’t be alarmed, the “SSL3” reference here is just a red herring).  Which means the “server” (the F5 in this case) couldn’t accept some combination of options the client was proposing — TLS protocol version, cipher suites, etc.

Looking at the Internet Explorer traffic (which worked), we noticed that it was offering TLS 1.2.  The Outlook traffic on the Win10 PC (which worked) was also offering TLS 1.2 (remember, Outlook on Win7 was only offering TLS 1.0).  Now we were getting somewhere…  We checked with the load balancer administrators and they confirmed that they had proactively disabled TLS 1.0 to be “ahead of the curve” with regard to PCI DSS requirements.  This was harmless since, in their minds, “All of our client OSes support TLS 1.1 and TLS 1.2.”  And well, they weren’t wrong.  🙂

So what gives?  Well, I’ll spare you the anguish that ensued (including setting Schannel registry keys like DisabledByDefault to 0 and Enabled to 1 for TLS 1.1 and 1.2 Client keys), but I ultimately found the referenced articles at the end of this post.  In summary, Office applications, including Outlook, use something called WinHTTP (“Windows HTTP Services”).  Although Windows 7 (via Schannel) supports TLS 1.1 and 1.2, WinHTTP (and therefore applications built on WinHTTP) only support TLS 1.0.  The fix for this resides in KB3140245, released in March 2016.  Quoting the KB,

“This update adds support for DefaultSecureProtocols registry entry that allows the system administrator to specify which SSL protocols should be used when the WINHTTP_OPTION_SECURE_PROTOCOLS flag is used.

“This can allow certain applications that were built to use the WinHTTP default flag to be able to leverage the newer TLS 1.2 or TLS 1.1 protocols natively without any need for updates to the application.”

So, in summary, here are the steps to enable Outlook on Windows 7 and Windows 8.0 to use TLS 1.1 and 1.2 to communicate with Exchange (the same goes for other apps, i.e. Word, and other servers, i.e. SharePoint):

  1. Determine which TLS versions you want to enable, and determine the corresponding value for DefaultSecureProtocols (which we will add shortly):
    1. For only TLS 1.1 and 1.2, the value will be 0xA00
    2. For TLS 1.0, 1.1, and 1.2, the value will be 0xA80
  2. Install the KB3140245 update, either via Windows Update — it’s available as an Optional Update, or obtain via the Microsoft Update Catalog and deploy as you would any other updates (SCCM, etc.).
  3. Create a DWORD value called DefaultSecureProtocols in both of the following locations and set its value to the value determined in Step 1:
    1. HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp
    2. HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\Internet Settings\WinHttp

Reboot and you’re good to go!  Here are some articles for reference:

And some random notes:

  • This behavior only affects Windows 7 and Windows 8.0:
    • Windows Vista didn’t include support for TLS 1.1 and 1.2 at all.
    • Windows 8.1 and Windows 10 enable TLS 1.1 and 1.2 for WinHTTP-based applications by default.
    • Windows 7 and Windows 8.0 support TLS 1.1 and 1.2 via Schannel (hence why IE is able to use TLS 1.1 and 1.2) but do not enable TLS 1.1 and 1.2 for WinHTTP-based applications without the aforementioned update and registry values.  Simple, right?  😉

One last note.  Although this update makes it possible for Outlook clients to use higher versions of TLS, at this time Microsoft does NOT recommend attempting to disable TLS 1.0 on Exchange servers themselves.  Please see this article for more details.

More tk…

Comments (5)

  1. Joe Gorski says:

    Wow. I appreciate this article very much. We just failed a DR exercise due to a misconfiguration in our co-lo of one of our VIPs requiring TLS 1.2. The error was a non specific certificate error on W7 clients and certain Android devices when connecting to Exchange 2013. The problem described and remedy explained here were the exact problem/solution we experienced.

  2. Brandon Barrick says:

    In Step 2 the KB article is not correct. The KB article up higher is written as KB3140245, but in step 2 it is KB314025. Hopefully that saves someone some time who was looking only at Step 2 and not the previous reference earlier in the article.

    1. Thanks Brandon! I’ve corrected the post.

Skip to main content