Keith Bromley
Sr. Manager, Product Marketing at Ixia
Blog

How The New TLS1.3 Standard Will Affect Your Encryption Tactics

June 11, 2019 by Keith Bromley

The IETF released a new version of their encryption standard called RFC 8446 (Transport Layer Security (TLS) Protocol Version 1.3) in the latter half of 2018. This is a newer version of the original IETF Secure Socket Layer (SSL) protocol first issued in 1995. While the name was changed a few years, the goal is still the same—encrypt IP traffic. In fact, if you are curious, here is a list of several versions of the standard.

TLS Versions

So, what does the new TLS 1.3 standard mean for you though? Enterprise Management Associates (EMA) performed a survey late last year to investigate this very topic. The results are summarized here.

According to the survey, most people expect to see improved privacy, security and user experience. Here is the exact breakdown of those results:

  • Expect to see improved data security = 73%
  • Expected to see improved privacy = 67%
  • Expected improved user experience = 55%

While there are many expectations, here is a chart summarizing the results of the new protocol:

TLS Changes

One of the key components driving the expectations is that ephemeral keys are now mandatory. This means that a “man in the middle” approach is now mandatory. The resulting outcome is that passive monitoring is eliminated you must use active monitoring.

This one change will affect many IT engineers because another data point from the 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. Since out-of-band decryption is no longer supported, the following will be your new monitoring/decryption architecture.

Network diagram

An easy way to enable active decryption and inline monitoring is to use a network packet broker (NPB). Once an NPB is deployed, an SSL decryption appliance can be connected to it to handle high volume data decryption. Decrypted data is then relayed back to the NPB which will forward the data to the correct security appliance for analysis. If an integrated decryption approach is used (where the decryption is performed by the NPB), the NPB will forward the data straight to special purpose tools. The NPB will have no impact on application performance. Data that passes analysis is re-encrypted and sent on into the network core.

Another fundamental change from the TLS 1.3 standard is in regard to the allowed cipher suites. TLS 1.3 only allows five ciphers now. This is a far cry from TLS1.2 that allowed 37 ciphers or the 319 ciphers in previous versions. If you are using any of the older ciphers then, then you will need to reconfigure your web servers for the proper ciphers.

  • ECDHE-ECDSA-CHACHA20-POLY1305-SHA256
  • ECDHE-ECDSA-CHACHA20-POLY1305
  • ECDHE-ECDSA-AES256-SHA384
  • ECDHE-ECDSA-AES128-SHA256
  • ECDHE-RSA-CHACHA20-POLY1305

Of course, until everyone adopts TLS 1.3 you may find that the actual keys your web servers will need to use are still part of TLS 1.2.