SSL Encryption – Cipher Suites

Securing access to your environment and web sites by encrypting the traffic and data is becoming more important these days as we move an increasing amount of data into Cloud environments.  Encrypting the data - while it is in transit between clients requesting the information from the servers hosting it - is enabled by the use of SSL certificates, SSL Cipher Suites and the TLS Protocol.  In this blog, I will be focusing (at a high level) on the SSL Cipher Suites, which make up part of the secure connection. What are Ciphers and Cipher Suites?

A cipher is an algorithm which outlines the steps to follow to complete a cryptographic function, such as encrypting or decrypting data.  With SSL encryption, such as when your Web browser connects with a web site, SSL keys carry out the encryption or decryption of data. However, the SSL Ciphers provide the rules of the cryptosystem and the order in which the keys must perform the cryptographic functions.

When connecting to a secure website (HTTPS) a number of these ciphers work in tandem, known as a Cipher Suite. This Cipher Suite is a collection of ciphers which perform several cryptographic functions such as key generation and authentication and also provide the order in which this should occur. Connecting to the server hosting the secure website they negotiate which cipher suite to use to establish a secure connection during a process known as the SSL handshake.

CIPHER SUITES AND THE SSL HANDSHAKE

When connecting to secure websites, the SSL handshake process is very complicated. However, it eventually results in the creation of a session key, which encrypts the connection between the server and the client. Here is a simplified process focusing on the Cipher Suite when a Web Browser connects to a secure Website:

  • When a client connects to a secure website, they exchange details about which cipher suites to use for the SSL Handshake
  • The client sends the server hosting the website a list of its support cipher suites
  • The server selects the standard cipher suite from the list available which it decides is the most secure

The client is informed of the decision, and the SSL Handshake begins

WHAT MAKES UP A CIPHER SUITE?

The contents of a Cipher Suite is dependent on the Transport Layer Security (TLS) protocols available on the client and server - TLS underpins how SSL Certificates function to secure the connection. There are also different versions of TLS available with the latest being v1.3.

The previous version, v1.2, is still widely used and is a very secure protocol; however, v1.3 incorporates some improvements and is less at risk to specific vulnerabilities.

Older TLS versions (v1.0 and v1.1) are not recommended for securing connections due to being less secure, suffering vulnerabilities which are actively exploited and will eventually be phased out entirely. A notable difference between TLS v1.3 and v1.2 is the number of Cipher Suites they support - 1.3 supports five, 1.2 supports 37 with some 1.2 Cipher Suites being less secure than others.  The number of ciphers in a Cipher Suite is also different between the versions; in 1.3 it has two ciphers in a Cipher Suite, in 1.2 it has four. As 1.3 contains a smaller number of ciphers in a Cipher Suite, this reduces the time taken to complete the SSL Handshake and simplifies the key exchange, while also providing a more secure connection.

Here is a quick example of TLS 1.3 and 1.2 Cipher Suites:

  • TLS 1.3: TLS_AES_128_GCM_SHA256
  • TLS 1.2: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

You can see TLS 1.2 is a lot longer than TLS 1.3, which has a bearing on the time taken to complete the SSL Handshake and begin the transfer of encrypted data from the server. The following network traces quickly highlight the time taken for a client connecting to a web site configured with only TLS 1.3.  With only TLS 1.2 as a comparison of the time required for the client to complete the SSL Handshake and begin receiving encrypted data from the server (your mileage will vary as the traces below were taken in a lab environment):

TLS 1.3:

Handshake initiation:

The first encrypted data packet from the Web server:

Time taken for the client to begin receiving encrypted data: 0.007412 seconds.

TLS 1.2:

SSL Handshake initiation:

The first encrypted data packet from the Web server:

Time taken for the client to begin receiving encrypted data: 0.018417 seconds.

So, using TLS 1.3 provides a much faster method of completing the SSL Handshake and getting data over to the client. While TLS 1.3 is the latest version of the TLS protocol, 1.2 is still widely used across the Internet and should be enabled on Web servers as clients running older browser versions may not be able to connect to the site.

To test your webserver to validate which SSL/TLS protocols and cypher suites are in use, head on over to www.ssllabs.com and click “Test your server”. You can also review their SSL and TLS Deployment Best Practices here: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deployment-Best-Practices

Join the Insentra Community with the Insentragram Newsletter

Hungry for more?

[Secure Workplace]

Microsoft Defender for Endpoint 101

By [Rahul Singh]

So, finally I have decided to come out of retirement from writing blogs to help save humanity from the chaos around endpoint protection.

[Secure Workplace]

The Secure Workplace Story Part 2: Why and How Do You Implement a SWP?

By [Lee Foster]

The secure workplace has evolved rapidly over the past 24 months with more and more integration and continuous development to stay ahead of the bad guys.

[Secure Workplace]

Azure Information Protection - Deployment - Part 4

By [Hugh Roberts]

In part 4 of the series we take our implemented environment and ensure it is expanded, governed and monitored correctly.