Udostępnij za pośrednictwem

Enabling TLS 1.1 and 1.2 in Outlook on Windows 7

  • Artykuł

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
  4. EDIT: Thanks to Ivan's comment below, I'm adding this step.  Per the TLS-SSL Settings TechNet article, be sure to create the DisabledByDefault DWORD value and set it to 0 in the following locations:
    1. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
    2. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client

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

Comments

  • Anonymous
    July 08, 2016
    The comment has been removed
  • Anonymous
    September 23, 2016
    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.
    • Anonymous
      September 23, 2016
      I'm glad this helped!
  • Anonymous
    October 14, 2016
    Hello,Is this solution used to connect to other mail servers such as Postfix?Thanks!
    • Anonymous
      November 29, 2017
      Pablo,Yes, the Schannel guidance applies to POP/IMAP/SMTP connections, while the WinHTTP keys build on Schannel to apply to HTTPS connections (such as Exchange RPC over HTTP, MAPI over HTTP, EWS, OAB, etc.).
    • Anonymous
      December 13, 2017
      If you enable the following option: For TLS 1.0, 1.1, and 1.2, the value will be 0xA80 than you will automatically allow applications to use those protocols, so yes Outlook 2007 and others will support TLS 1.1 and 1.2. I applied this changes in order to allow Outlook 2007 in Windows 7 to operate using either TLS 1.1 or TLS 1.2 as my server no longer accepts TLS 1 for smtp. So It will work.
  • Anonymous
    October 27, 2016
    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.
    • Anonymous
      October 27, 2016
      Thanks Brandon! I've corrected the post.
  • Anonymous
    April 26, 2017
    Fantastic! Very helpful! Work like a charm! Big Thank You!
  • Anonymous
    November 29, 2017
    This did not work for me until I also added the following keys and DWORD's to the registry:[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client]"DisabledByDefault"=dword:00000000[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client]"DisabledByDefault"=dword:00000000
    • Anonymous
      November 29, 2017
      Thanks Ivan! You are correct, in the customer environment I discovered this in, we had already deployed the Schannel registry keys and I neglected to include those details here. Great catch!
  • Anonymous
    December 13, 2017
    Chris, thanks for the information, but a real problem for businesses trying to maintain security policies. Microsoft should have already provided users with an option to make these changes and permit them the use of TLS 1.1 and 1.2, instead of having to resort to manually changing and applying patches here and there.
  • Anonymous
    February 22, 2018
    Very good solution but there is a much easier way!1.Download IISCrypto from https://www.nartac.com/Products/IISCrypto2. Run the program.3. Click the "Best Practices" button the the lower right hand corner.4. Optionally disable TLS 1.0 for PCI compliance.5. Click the "Apply" button the the lower right.Done!!!It says to reboot, which is fine, but it works without reboot in my experience.To verify send a message and check the mail log or paste full header of recipient's email into https://testconnectivity.microsoft.com/ Message Header Analyzer tab. You should now see TLS 1.2!!!
    • Anonymous
      February 22, 2018
      Thanks for the comment! I love IISCrypto -- I even had a chance to work with their development team a few years back. However, IISCrypto only works with the Schannel registry keys. These are enough to get Outlook talking TLS 1.2 via TLS for SMTP, but the WinHTTP hotfix and DefaultSecureProtocol keys are also needed to allow Outlook to send a TLS 1.2 Client Hello when connecting to Exchange and other services via HTTPS.Also, keep a watch on the Exchange Team Blog (blogs.technet.microsoft.com/b/exchange) over the next few weeks, there will be more exhaustive guidance on enabling TLS 1.2 across the board coming soon.