Transport Layer Security: What Stakeholders Need to Know about Communication Security

29 Nov 2022

Transport Layer Securities are designed to provide security at the transport layer to prevent third parties from eavesdropping or tampering with messages

The main purpose of penetration testing is to discover weaknesses within our systems and applications. Armed with the knowledge of where those weaknesses lie, organisations can then proceed to fix those issues. As most vulnerabilities tend to be well-documented, the remediation process is usually clear – yet nevertheless many organisations find it extremely difficult to implement the necessary fixes for various reasons. This article will explore a simple scenario drawn from our own experience with pen testing and will hopefully help us to view such situations in a more sympathetic light.

What is TLS and How Does it Work?

Transport Layer Security (TLS) was created in the 1990s to prevent third-party eavesdropping and tampering over the internet – known in technical terms as the Man-in-the-Middle attack (MITM). In the fast-changing digital era, seven versions of SSL (1.0, 2.0 & 3.0) and TLS (1.0, 1.1, .1.2 & 1.3) in total have been released and only the current latest versions TLS 1.3, and TLS 1.2 are still supported. TLS 1.3 has improved significantly in terms of performance and efficiency compared to its predecessor as it takes only one round trip from both sides to complete the TLS handshake. Most importantly, TLS 1.3 has more robust security because the encryption keys change for every new session and support only cipher suites that have no known vulnerabilities. Older versions of TLS (1.1 and older) are officially deprecated, and no longer supported – this is because armed with the proper tools, a threat actor could leverage the weak cipher suites and key exchange mechanisms to perform downgrade attacks that let them impersonate servers and intercept communications. For example, an attacker could trick the user into running malicious JavaScript. The code will help the attacker to position himself in between the server and user, whereby attacker may send requests to check if the server supports SSL backward compatibility (as older versions of TLS do) and downgrade the connection to use SSL 3.0. The attacker can then exploit known vulnerabilities found in cipher block chaining (CBC) encryption, monitoring server responses and decrypting communications. Attackers can now impersonate users and sensitive data such as passwords, session cookies, personal data, credit card details, and health records may be exposed. Consequently, pen testers will recommend that organisations stop supporting TLS versions older than 1.2 and the risk level would be serious enough to fail an organisation's PCI scan.

Supply Chain and Business Complexities Sometimes Make a Remediation Plan Difficult

Despite this, many organisations nevertheless continue to leave the issue unfixed – not because of technical difficulty, nor cost, but purely for business reasons. Most of these are large organisations with updated systems, but who nevertheless need to communicate with clients, vendors, and business partners regularly, many of whom are SMEs who simply cannot afford to fix the issues on their side. If their vendor's systems are too outdated to support TLS 1.2, then organisations would need to support older versions of TLS to facilitate communications. An organisation would need to be running Windows 10 or Server 2019 to be able to support TLS 1.3, or Windows 7 (and even then, it's not enabled by default) / Server 2008 for TLS 1.2. Surprising as it may sound to some of us, there are many older SMEs out there who do not meet these requirements.

This reminds us that security cannot be implemented in isolation, especially when it comes to supply-chain issues like these – all stakeholders need to work together, and nobody should be left behind. We need to provide support to SMEs, some of whom are still running Windows XP, and educate them on the importance of upgrading their systems. Perhaps some form of standard systems requirement template (updated whenever necessary, of course) enforced by large organisations on their SME partners, or maybe even the option to rent such infrastructure as part of a business partner package. Or perhaps some brave entrepreneurs will see a market for such services and provide them on a third-party commercial basis. Right now, thought, SMEs are struggling to keep up with security requirements, and as a result, organisations are obliged to compromise their security positions to facilitate the working relationship. This is a ticking time-bomb, and hopefully everyone can work towards a solution sooner rather than later.