Understanding And Testing The TLS1.3 Encryption Standard

People often state that change is good. This statement is obviously relative. Change can be either good or bad. A key to success is knowing what you are getting into before you embark on a new journey. Data encryption/decryption is one such example. The Internet Engineering Task Force (IETF) released a new version of their encryption protocol RFC 8446 during the last half of 2018. So, is this new standard something you should adopt immediately? A whitepaper, The Security Engineer’s Guidebook to TLS 1.3, answers this and other questions.

Interestingly enough, a study by Enterprise Management Associates (EMA) indicates that 73% of their respondents already plan to begin the conversion to TLS 1.3 before mid-year 2019. At the same time, for many enterprises (especially in the financial industry) this will result in a fundamental change to their security architectures. Any organization that is currently using secure socket layer (SSL) or Transport Layer Security (TLS) for passive SSL decryption will need to change their architecture or lose the ability to conduct deep packet inspection (DPI), threat hunting, data loss prevention (DLP), and the use of intrusion detection systems (IDS).

The real question is, how many enterprise personnel understand the full ramifications of how TLS 1.3 data decryption will affect them? Once the change are understood, the next question is how do you implement the new changes with the least impact (cost) to your network? A third question is how will you validate that your new changes are actually working? These questions and their answers should be fully understood before an enterprise undertakes the TLS 1.3 conversion process.

For instance, the EMA survey showed that currently over one quarter of enterprise IT solutions decrypt data for out-of-band monitoring, i.e. they are currently using passive decryption. Since this is no longer allowed with TLS 1.3, security and operations personnel will need to change this process.

The obvious process change is to support inline data monitoring and decryption. This allows you to perform the man-in-the-middle decryption. However, if you are not one of the few enterprises currently conducting inline decryption activities, you must change your monitoring and decryption architecture to support the capability. The probably means new additional cost for inline security tools, a network packet broker (NPB) to perform decryption/re-encryption functions along with data distribution to those inline tools, and an external bypass switch to decrease the risk involved with inline security solutions.

This configuration is shown in the following illustration using the Ixia Vision ONE product for the NPB:

Network diagram showing SSL Decryption

In addition, this new inline monitoring scheme will increase monitoring complexity, programming costs, and possibly reduce the speed of access to monitoring data. It will all depend upon the solution you implement and how you implement it.

As you move forward to deploy TLS 1.3 across your network, you need to validate your TLS upgrade implementation. Is the decryption accurate? Is it 100% effective or did encrypted packets slip by unnoticed? This type of TLS testing covers firewalls, IDS, IPS, SSL offload, web servers, and other SSL points within a large data center architecture.

One critical concern is that decryption has the potential to change the underlying performance of the devices — throughput and session increases/decreases. The impact is sometimes substantial. ZK Research performed a survey and estimates that 45% of respondents admitted to turning off security features in devices to improve performance. SSL decryption was the central culprit of the problem.

To investigate the impact of decryption across various function points in your network, you will need a specific test tool, like the Ixia BreakingPoint product. This type of test system is a combined traffic and malware generator. It creates simulated traffic to mimic the type and amount of load on your network, as well as the creation of encrypted malware. You can retest these points prior to the TLS 1.3 upgrade (as a baseline) and then after.

Here are four TLS/SSL tests you should consider performing:

  1. Application throughput with encryption
  2. Performance variance with different ciphers
  3. Efficacy of detecting encrypted malware
  4. Strength of decryption capabilities

For more information on all of the TLS 1.3 impacts and how to mitigate them, read this whitepaper, The Security Engineer’s Guidebook to TLS 1.3.

limit
3