API support for TLS versions 1.0 and 1.1

Action Required for Web service / API Integrations

We’ll be retiring support for TLS versions 1.0 and 1.1 on all Twinfield sites, including Twinfield’s API. This change improves the security of the data sent between you and Twinfield, whether you’re accessing Twinfield through a browser or communicating directly with our API.

We strongly encourage any developers who are using the Twinfield API to ensure that their software supports negotiating TLS 1.2 connections, and to coordinate with their system administrators to update software to take advantage of newer TLS versions. In addition, we recommend proactively switching over to TLS 1.2 when communicating with Twinfield’s API by modifying your API client software to enforce TLS 1.2 negotiation.

Please refer to the compatibility guidelines below:

Platform or Library Compatibility Notes
Java (Oracle)

Compatible with the most recent version, regardless of operating system

Java 8 (1.8) and higher Compatible with TLS 1.2 by default.
Java 7 (1.7) Enable TLS 1.2 using the https.protocols Java system property for HttpsURLConnection. To enable TLS 1.2 on non-HttpsURLConnection connections, set the enabled protocols on the created SSLSocket and SSLEngine instances within the application source code. Switching to IBM Java may be an effective workaround if upgrading to a newer Oracle Java version isn’t feasible.
 
Java (IBM)
Java 8 Compatible with TLS 1.2 or higher by default. You may need to set com.ibm.jsse2.overrideDefaultTLS=true if your application or a library called it by it uses SSLContext.getinstance(“TLS”).
Java 7 and higher, Java 6.0.1 service refresh 1 (J9 VM2.6) and higher, Java 6 service refresh 10 and higher Enable TLS 1.2 using the https.protocols Java system property for HttpsURLConnection and the com.ibm.jsse2.overrideDefaultProtocol Java system property for SSLSocket and SSLEngine connections, as recommended by IBM’s documentation. You may also need to set com.ibm.jsse2.overrideDefaultTLS=true.
.NET

Compatible with the most recent version when running in an operating system that supports TLS 1.2.

.NET 4.6 and higher Compatible with TLS 1.2 or higher by default.
.NET 4.5 to 4.5.2 .NET 4.5, 4.5.1, and 4.5.2 do not enable TLS 1.2 by default. Two options exist to enable these, as described below.

Option 1:
.NET applications may directly enable TLS 1.2 in their software code by setting System.Net.ServicePointManager.SecurityProtocol to enable SecurityProtocolType.Tls12. The following C# code is an example:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Option 2:
It may be possible to enable TLS 1.2 by default without modifying the source code by setting the SchUseStrongCrypto DWORD value in the following two registry keys to 1, creating them if they don’t exist: “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319” and “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319”. Although the version number in those registry keys is 4.0.30319, the .NET 4.5, 4.5.1, and 4.5.2 frameworks also use these values. Those registry keys, however, will enable TLS 1.2 by default in all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on that system. It is thus advisable to test this change before deploying it to your production servers. This is also available as a registry import file. These registry values, however, will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value.

.NET 4.0 .NET 4.0 does not enable TLS 1.2 by default. To enable TLS 1.2 by default, it is possible to install .NET Framework 4.5, or a newer version, and set the SchUseStrongCrypto DWORD value in the following two registry keys to 1, creating them if they don’t exist: “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319” and “HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319”. Those registry keys, however, may enable TLS 1.2 by default in all installed .NET 4.0, 4.5, 4.5.1, and 4.5.2 applications on that system. We recommend testing this change before deploying it to your production servers.

These registry values, however, will not affect .NET applications that set the System.Net.ServicePointManager.SecurityProtocol value.

.NET 3.5 and below Not compatible with TLS 1.2 or higher encryption
 
Python

Compatible with the most recent version when running on an operating system that supports TLS 1.2.

Python 2.7.9 and higher Compatible with TLS 1.2 by default.
Python 2.7.8 and below Not compatible with TLS 1.2 or higher encryption
 
Ruby

Compatible with the most recent version when linked to OpenSSL 1.0.1 or higher.

Ruby 2.0.0 TLS 1.2 is enabled by default when used with OpenSSL 1.0.1 or higher. Using the :TLSv1_2  symbol with an SSLContext’s ssl_version helps ensure that TLS 1.1 or earlier is disabled.
Ruby 1.9.3 and below The :TLSv1_2 symbol does not exist in 1.9.3 and below, but it is possible to patch Ruby to add that symbol and compile Ruby with OpenSSL 1.0.1 or higher.
How to test?

Download and install Fiddler (free of charge): https://www.telerik.com/download/fiddler

Start Fiddler. Go to the menu “Rules” and remove the check from “Hide CONNECTs”.
Send a request to the Twinfield web services and capture the connect creation. Examine the first packet from the client, including the TLS version requested by the client. See also underneath screen shot. Make sure you see TLS/1.2 in the “TextView” tab.