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|
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 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.|
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.
System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
|.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|
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|
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.|