Robert S. Mueller III, former US FBI Director, once said “There are only two types of companies: Those that have been hacked and those that will be”.
A recent article published by Cyber Crime Magazine predicts that Cybercrime would cost the global economy $6 trillion in 2021 and is expected to grow at 15% year on year and with this rate it will touch $10.5 trillion by 2025.
Cybercrime can happen to any business and its effects can be devastating. Businesses across the industries need a comprehensive and ever evolving security solution to protect from cyber-attacks. TLS (Transport Layer Security) is a vital component of this larger comprehensive security solution.
What is TLS
Transport Layer Security (TLS) is a cryptographic protocol that encrypts data sent over the Internet. For instance, web browsing uses HTTPS (Hyper Text Transfer Protocol Secure - it is HTTP over TLS). First, a secure and a trusted HTTPS session establishes between the browser and the web server using TLS handshake. Second, all data including passwords, sensitive, personal, and general information encrypts at the client side and decrypts at the server side and vice versa. Without TLS, data transmits in plain text and is vulnerable to all kinds of harmful activities.
Other applications such as e-mail, file transfers, video/audio conferencing, instant messaging, voice-over-IP and Internet services such as DNS and NTP use TLS.
Origin of TLS
TLS has come long way. It all started with SSL (Secure Socket Layer) protocol released in 1994 by Netscape for providing secure communications between the client and the server on the web. Later, IETF (Internet Engineering Task Force) developed similar protocol based on SSL 3.0 and released TLS 1.0 in 1999, followed by TLS 1.1 in 2006, TLS 1.2 in 2008 and TLS 1.3 in Aug 2018 (RFC - 8446).
How TLS works
To know TLS better, let us understand step by step process of what happens when a user types a website - URL (eg:- https://www.google.com) in a web browser and clicks enter.
- DNS Lookup – The browser sends the URL (www.google.com) to DNS server which does a lookup of the URL and returns IP address to the browser
- TCP Handshake – the browser sends a request to the IP address, trying to establish a connection with the web server
- TLS Handshake – having made a connection, the browser and web server decide encryption protocol, cipher suites and parameters, authenticate one or both parties, create and exchange symmetric master secret key. The browser and the web server will use this master secret key to encrypt and decrypt the data
- Page Fetch – The browser requests the content of the website and the server responds back with the content. The data exchanged between the browser and the webserver is encrypted
Benefits of TLS 1.3
TLS protocol evolved significantly over the last 2 decades. TLS 1.0 (RFC 2246) - The first version from IETF focused on standardization. TLS 1.1 (RFC 4346) – It added protection against CBC (Cipher Block Chaining) attacks. TLS 1.2. (RFC 5246) – It added support for advanced cipher suites that support elliptical curve cryptography and support for secure hash algorithms such as SHA-256
TLS 1.3 (RFC 8446) offers great improvements over TLS 1.2. Vulnerable optional parts of the TLS 1.2 protocol removed. TLS 1.3 supports only stronger ciphers and the TLS handshake process significantly shortened for better performance. Let us get into details
1) Support for vulnerable ciphers removed
Support of vulnerable, attack-prone ciphers removed. TLS 1.3 supports only below 5 ciphers that support PFS (Perfect Forward Secrecy – which we will learn in detail shortly) and have no known vulnerabilities as of today
a. TLS_AES_128_GCM_SHA256
b. TLS_AES_256_GCM_SHA384
c. TLS_CHACHA20_POLY1305_SHA256
d. TLS_AES_128_CCM_SHA256
e. TLS_AES_128_CCM_8_SHA256
2) Security enhanced for symmetric key exchange
Though TLS is in use by several applications such as e-mail, file transfers, video/audio conferencing, instant messaging, voice-over-IP, for ease of explanation, we will use web browser and web server talking to each other using HTTPS protocol.
For the web browser (client) to encrypt the data and the web server (destination) to decrypt the data and vice versa, both the web browser and web server need a symmetric key (master secret key). The symmetric key exchange happens during TLS handshake
Please note symmetric key (Symmetric Encryption) is one where a same key is used to encrypt and decrypt the data
Alternatively, there exists another type of encryption called Asymmetric Encryption. Asymmetric Encryption encrypts and decrypts the data using two separate yet mathematically connected cryptographic keys. These keys are known as a ‘Public Key’ and a ‘Private Key” and together they are called a ‘Public and Private Key Pair’
RSA (Rivest, Shamir, and Adelman) and Diffie-Hellman Ephemeral (Ephemeral dictionary meaning is lasting or used for only a short period of time) are the two popular asymmetric encryption mechanisms used for exchanging the symmetric key used during the HTTPS connection.
In TLS 1.3, RSA key exchange support deprecated in favor of Diffie-Hellman Ephemeral (DHE) which supports Perfect Forward Secrecy (PFS).
RSA lacks support for PFS. In RSA, the Public and Private key pair is fixed per server. If the private key of the server compromised and attacker gets hold of any previously recorded HTTPS session then he/she can use the private key to get the symmetric key used in this recorded HTTPS session first and he/she then can use this symmetric key to decrypt all the messages in this recorded HTTPS session. This flaw can be avoided with Perfect Forward Secrecy (PFS).
However, unlike RSA where public and private key pair is fixed per server, with Diffie-Hellman Ephemeral (DHE), the public and private key pair is generated per HTTPS session which then generate the symmetric key. The symmetric key is then used to encrypt the messages in HTTPS session. Since public and private key pair is generated per HTTPS session, it is highly impossible for an attacker to decrypt a previously recorded HTTPS session.
3) TLS 1.3 is faster
The TLS handshake process has been optimized in TLS 1.3 to make the TLS connection faster
a. New connections, these are the sites that you are visiting for the first time - with TLS 1.2 and lower, TLS handshake takes 2 round trips to complete, while with TLS 1.3, TLS handshake takes 1 round trip to complete
b. Resumed connections, these are the sites that you have previously visited - with TLS 1.2 and lower, TLS handshake takes 1 round trip to complete, while with TLS 1.3 (0-RTT - Zero Round Trip Time Resumption feature) a TLS handshake is removed. i.e. you can send data on the first message to the server
A shorter TLS handshake means connections are setup faster with low latency. The performance gain may be in milliseconds for a single connection but at scale there will be noticeable difference.
TLS 1.3 adoption
TLS 1.3 is available for little over two years. When it comes to TLS adoption, TLS 1.2 is in use worldwide. TLS 1.0 and TLS 1.1 still in use but not recommended as they are no longer secure. As per IETF report published here https://www.ietf.org/blog/tls13-adoption/ in Dec 2019, one-third traffic from Chrome, Firefox, and Safari web browsers use TLS 1.3. This percentage would have gone up by now.
You can use https://www.cdn77.com/tls-test to verify whether a particular website supports TLS 1.3. Example – As of Nov 2021, Facebook.com and google.com supports TLS 1.3 while Amazon.com does not support TLS 1.3.
When it comes to web browsers, all the latest versions of Google Chrome, Apple Safari, Mozilla Firefox and Microsoft Edge support TLS 1.3.
TLS 1.3 adoption concerns
Organizations keep a constant check on data entering and leaving their network to spot malicious traffic and defend against attacks hidden in that encrypted traffic. For this, they have built security and network monitoring systems that use static RSA private key to decrypt the encrypted network packets to inspect for malware, data breaches, performance issues on the network.
In TLS 1.3, with Diffie-Hellman Ephemeral (DHE) perfect forward secrecy key exchange mechanism, these security and network monitoring systems need access to the ephemeral key for each HTTPS session to monitor the traffic which has become a biggest challenge. This puts organizations to lose this critical security and network monitoring function when they upgrade their systems to TLS 1.3, however, there exists third party security solutions that organizations can use to monitor the incoming data traffic. F5 SSL Orchestrator is one such security solution.
Conclusion
Until few years back we would have found HTTP websites all over and our browsers would start labelling these sites as "non secure". Today, we do not see any popular websites in banking, commerce, education, and any other domains using HTTP, all these moved to HTTPS. This transition from HTTP to HTTPS shows enterprises of all sizes have become security conscious and are using one or other version of TLS.
While designing business applications, there exists a tradeoff between security and performance. In other words, enhanced security would degrade performance, and this has been the case until TLS 1.2. With TLS 1.3 this would change. In the coming years we will see businesses embracing TLS 1.3 because of greater privacy, enhanced end-to-end data security and improved performance.
Let us join hands to build a secure digital world which is safer for everyone
