On February 28th, 2018 Authorize.NET discontinued support for all TLS 1.0 and 1.1 access to their APIs and only supports TLS 1.2. Not surprisingly the last few days my phone (Skype actually) has been ringing off the hook with customers frantically looking to fix a variety of TLS 1.2 issues.
TLS is the successor to the SSL protocol. TLS 1.0 and 1.1 both had theoretically possible (but very computing intensive) breaches associated with them and so they are considered compromised, and most industry groups that rely on secure standards (like Credit Card Processors obviously) now require TLS 1.2. This requirement has been long announced by many companies - years ago, but the cut off dates are now reaching maturity and Authorize.NET was just one of them that many of the customers I work were directly affected by.
Protocol Support in Windows and what it means
Before we look at what supports which version etc. it's important to understand what 'TLS Support' means in this context. The context here really is Windows Support meaning that Window's internal libraries and SDKs that use the underlying Windows Security Protocol infrastucture.
This affects most Microsoft Products that run on Windows, as well as the Windows Client stack including WinInet and WinHttp which incidentally is also used by the desktop .NET framework as well as Web Connection and West Wind Client Tools use for the its HTTP support.
Non-Microsoft Browsers bypass Windows Security Protocol Libraries
Although TLS 1.2 may not be supported by some older versions of Windows and APIs, you can still use a number of applications that have their own TLS implementations. Specifically any non-Microsoft Web Browsers like Chrome and FireFox do not use the Windows infrastructure so even on old versions of Windows you can get TLS 1.2 support using custom browsers. This works for browsers, but many other applications that run on old Windows versions do rely on the Windows infrastructure and those may stop working if they require TLS 1.2.
Windows and TLS 1.2
TLS 1.2 is relatively new and old versions of Windows didn't have native support for TLS 1.2. The first versions of Windows that natively support TLS 1.2 are:
- Windows 8.1 or later
- Windows Server 2012 R2 or later
Windows Versions that can work with TLS 1.2 with some tweaks and patches:
- Windows 8
- Windows 7
- Windows Server 2012, 2008 R2
These versions can support TLS 1.2 via registry settings (for machine wide settings) or Internet Explorer Configuration of Protocols for IE and WinHttp/WinInet functionality.
Older versions of Windows don't have support TLS 1.2 at all and don't have any way to make it work outside of using applications that don't use the Windows Protocols Stack:
- Windows Vista
- Windows Xp
- Windows Server 2003
- Windows Server 2008
These versions all don't support TLS 1.2. This also affects the wwHttp class which runs through WinInet in Web Connection or the Client Tools.
Checking TLS 1.2 support
If you're running a version that either supports or can be upgraded to support TLS 1.2, you should be able to check TLS 1.2 in Windows with Internet Explorer. If you know of a site that requires TLS 1.2 to access, you can visit that site and if TLS 1.2 support is not working you will not be able to access the site/page with anything that uses WinHttp/WinInet which includes the West Wind FoxPro HTTP tools.
In essence you can use IE as you canary in a coal mine to see if you'll have problems and need to fix TLS 1.2 settings.
One such TLS 1.2 test link is:
https://tls1test.salesforce.com/s/
The page returns a Green page with a success message.
You can also hit this page with an HTTP client. Using wwHttp in Web Connection or the Client Tools you can do:
DO wwHttp
o = CREATEOBJECT("wwHttp")
? o.HttpGet("https://tls1test.salesforce.com/s/")
? o.cErrorMsg && Connection could not be established if TLS 1.2 is not availableYou can check the HTML output in the page for TLS 1.0 Deactivation Test Passed in the output to confirm that the page worked.
If the test fails you have some work to do.
Making TLS 1.2 work in older Windows Machines
There are two places where TLS 1.2 settings can be made:
- Internet Explorer Settings (affects IE and WinInet/WinHttp)
- Registry Protocols Section
Internet Explorer Settings
The first and easiest way to fix settings for client libraries that are using an HTTP client using WinInet or WinHttp like wwHttp is by setting the Internet Explorer Protocols selection in the IE options.
In IE open Internet Settings -> Advanced -> Security and scroll to the bottom of the list. There you can find the protocol support you want to allow.
This enables only TLS 1.2 support and disables all the other protocols which is the recommended approach. However, be careful with this - you may run into problems with older Web Sites that may not yet have updated to TLS 1.2 certificates. These days all new certificates issued are TLS 1.2 but some sites may still have older or client signed certificates that are not and that can break things.
Note: PCI compliance requires that TLS 1.1 and 1.0 are to be turned off!
Protocol Registry Settings
There are also a set of Registry Settings that let you enable and disable the various protcols for client and server explicitly.
You can find these in:
HKLM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\ProtocolsThere sub-keys for each protocol and subkeys for Client and Server. Client affects client libraries like Internet Explorer and WinInet, WinHTTP and by extension .NET and Web Connection. Server affects incoming Server connections so it affects server software like SQL Server, Exchange, IIS etc.
The values are:
DisabledByDefault: 0 or 1
Enabled: 0 or ffffffff
and you can apply them on any of the Client and Server protocol keys.
Be Careful Removing Protocol Support
Removing older protocols may seem secure, but it may bite you in unexpected ways. One customer I worked with removed all non-TLS 1.2 protocols and was then unable to connect to SQL server until a post SP patch was installed because SQL Servers client connectivity wasn't able to connect via TLS 1.2. Get it working first, then dial back and test! Going all TLS 1.2 may require updating many old components to latest version to ensure connectivity still works.
Keep Things Up To Date
I've been harping on keeping software up to date recently and this is yet another reason why it's important to not neglect upgrades and keep on running with ancient versions of OS's. This goes for Operating Systems as well as critical server and client software. Keeping patched is extremely important and staying somewhat current with OS versions (no more than 2 OS releases behind is my rule) is critical to not be caught by surprise by something critical simply not being available.
The same is true for server software - like Web Connection. We have a lot of customers that never went past version 4 which is now nearly 20 years old. That's a long time to be running an application and not be broken.
This TLS 1.2 issue may be one of those things as really old OSs don't have an easy work around.
Be diligent with your applications. This doesn't mean being on the upgrade treadmill constantly but have a lifetime management for your server hardware and software and stick to it when time is up. I see 4-5 years as the sweet spot for upgrading OS versions.
These days this is even easier with cloud based VM and service solutions that are much quicker to deploy and restore to.
Summary
There you have it - I thought I'd write down these notes since this issue has been a recurring theme that's affecting quite a few customers. Hopefully you find something useful here to help you make sure your applications are TLS 1.2 capable.
Resources
this post created and published with Markdown Monster