| | Categories: Blog, News

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.

 

| | Categories: Blog, News

Twinfield case study – Liberty Leasing

Alan Cooper, finance director at Liberty Leasing, recently took time out of his busy schedule to talk to us about his experience of selecting, implementing and using Twinfield Online Accounting software.

Liberty Leasing Ltd is an FCA-regulated asset finance company which provides asset finance to a selection of small and medium sized companies across the UK. The company’s compound annual growth rate of about 20% over the last five years took their loan book value to over £100 million in March 2017. As Alan says: “Twinfield has helped us in our growth… and it’s become clear that it’s going to be able to help us to grow much further into the future.” We’ll certainly do all we can to help Alan and Liberty Leasing!

Click here to find out how Twinfield could help your growing business  

If you’re an existing Twinfield user with a story to tell, we’d love to hear from you – call us or discuss with your account manager. 

 

| | Categories: Blog, News

International financial reporting and analysis made easy with Twinfield

Twinfield Case Study money image

There are an estimated two billion people in the world who have a job but no bank account. In a country like Egypt, for example, only 3% of adults get their salary paid into a bank. That’s where dopay helps.

They provide a cloud-based payroll service that allows employers to calculate salaries and pay employees electronically. Unbanked employees receive their salary in a dopay account, which comes with a debit card.

The Challenge

Based in the financial heart of London, dopay has grown rapidly and now has operations in the Netherlands, Ghana and Egypt. Like any fast-moving, entrepreneurial organisation, dopay needs to be able to take decisions based on up-to-date financial information. It needs financial information presented in a consolidated form to show the group accounts as if it were a single entity. Financial information from each subsidiary must therefore be converted into a single reporting currency but each subsidiary has its own local accounting methods and checks so updates and corrections can be time consuming, especially across multiple time zones.

The Solution

Goodman Jones is a London-based accountancy practice with extensive experience of working with international groups, large owner-managed businesses and small, growing organisations. Applying their deep knowledge and experience of the Twinfield Online Accounting system, Goodman Jones were able to help dopay prepare monthly group financial information efficiently, easily and cost effectively.

Khaled Abou-Zied, Group Finance Director of dopay says “The results are excellent. We finally have a much better understanding of our business. We can analyse our figures and can quickly identify the areas of growth. We can look at group accounts but also have the ability to immediately drill down to a specific invoice in Ghana if we need to.”

You can watch our video case study here.