Web Service Problems and TLS 1.0

Introduction

By the end of June 2018, many secure sites will have changed the way in which they allow their users to establish and use a connection to themselves.

We have noticed that a number of web services have recently implemented the same security changes, and we’ve had problems connecting to a couple.

Here’s the background, and how we ensured that we are still able to communicate with those web services.

Payment Card Industry (PCI)


The industry body which regulates the payment card industry has stipulated that sites taking credit or debt card payments must remove access via SSL or early TLS by 30th June 2018, to prevent future compromising of card details and personal information, during sessions conducted under these old protocols and now insecure protocols.

In practical terms this means that users of older browsers such as Internet Explorer 6-9, or older versions of Safari, will be unable to connect to any sites that take card payments, or at least the relevant portion of those sites.

Windows Servers and SChannel

We use Windows Web Servers.

A feature of Windows (including Windows 10 etc) is that all secure communications is handled via a component known as SChannel. In order to, for example, prevent a web server from accepting TLS 1.0 connections, SChannel must be re-configured; this is done via Windows Registry settings (but see below).

A factor to consider is that any change to SChannel affects incoming and outgoing traffic that use it.

 

Use IISCrypto to Change SChannel

We recommend the use of the free IISCrypto tool, as a simple means to configure SChannel on your web servers.

The image below shows that TLS 1.0 has been disabled in the protocol section.

Problem 1 – Web Service Accepts Only TLS 1.1 or 1.2

Several web services that we use from Windows 2008 R2 servers upgraded their security to remove not only SSL 3 (which was done some time ago) but also TLS 1.0

Using .Net 4.5,it is necessary to make a minor change to a SOAP service or an invocation of the .Net class HttpWebRequest.

The C# snippet below illustrates the necessary configuration to System.Net.ServicePointManager:-

 //send using TLS 1.2
 System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
 
 //invoke the soap service
 ExtSoap.ExtSoap_Int.ResponseType1 response = client.Invoke(request);

Problem 2 – Our Server Cannot Communicate with a TLS 1.0

This is an unlikely scenario, but we did encounter it briefly early in 2018.

We made a change to SChannel, preventing incoming connections using TLS 1.0 on a web server. That same web server then attempted to communicate with an external web service that did not, at that time, allow a secure connection over any protocol above TLS 1.0. Since the SChannel’s TLS 1.0 capability had been disabled, this also prevents outgoing communications over TLS 1.0.

Our solution in the above instance was to move the invocation onto another server that did not have TLS 1.0 disabled, whilst the external web service was upgraded.

Problem 3 – Cannot Connect to External Web Service

We were using HttpWebRequest to connect to an external web service over TLS 1.2. A web browser (Chrome or Firefox), running on a Windows Server was able to connect to the external web service, but any attempt to do so using the above class instance, failed, with an unhelpful “connection closed” error.

Further investigation showed that the external web service had replaced their server certificate with an Elliptic Curve certificate.

Because .Net uses SChannel to achieve a secure connection (unlike the web browsers listed above) it was necessary to explictly enabable those ciphers in SChannel using IISCrypto.

The shot below shows IISCrypto runnig on the affected server, whch is now able to communicate with the offending web service securely.

Note the Cipher suites that have ECDHE, now enabled and prioritised.

Setting Cipher Suites in SChannel