Topics In Demand
Notification
New

No notification found.

Embrace Security with TLS 1.3
Embrace Security with TLS 1.3

November 29, 2021

326

0

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.

  1.   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
  2. TCP Handshake the browser sends a request to the IP address, trying to establish a connection with the web server
  3. 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
  4. 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

DW

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


That the contents of third-party articles/blogs published here on the website, and the interpretation of all information in the article/blogs such as data, maps, numbers, opinions etc. displayed in the article/blogs and views or the opinions expressed within the content are solely of the author's; and do not reflect the opinions and beliefs of NASSCOM or its affiliates in any manner. NASSCOM does not take any liability w.r.t. content in any manner and will not be liable in any manner whatsoever for any kind of liability arising out of any act, error or omission. The contents of third-party article/blogs published, are provided solely as convenience; and the presence of these articles/blogs should not, under any circumstances, be considered as an endorsement of the contents by NASSCOM in any manner; and if you chose to access these articles/blogs , you do so at your own risk.


images
Venkat Kandhari
Industry Principal

Mr. Venkat is an Industry Principal working with Infosys Limited. A thought leader in Unified Communications field with 24 years of industry experience in Unified Communications Research and Product Development and a proven track record in building technology teams who partner with business leaders in meeting strategic goals. Venkat’s professional expertise includes UC Linux platform and UC product security. He holds Master of Computer Application (MCA) from Osmania University Hyderabad, India

© Copyright nasscom. All Rights Reserved.