TLS 1.3: What do I need to know?
Much is getting written about the new TLS 1.3 and its impact on network operations. This is absolutely an issue that needs to be considered and addressed. In fact, there are actually 2 issues that need to be addressed.
The first is the move to TLS 1.3 will create significant problems as it can blind network based detection/analytic tools because those tools can’t see the data packets to do their job. The addition of PFS (Perfect Forward Secrecy) adds a level of complexity that means simply upgrading from TLS 1.2 to 1.3 won’t work.
The second is the need to consider impacts to the actual networking gear in your remote offices & data centers. Are you leveraging remote connectivity to get access to the hardware? Whether you are updating OS versions or pulling SNMP information, using networks to access your equipment could become compromised. Many older equipment probably still use TLS 1.0 or 1.1 and we know this equipment is prone to security vulnerabilities. Make sure you do a systematic check to validate all equipment has been upgraded to support, at minimum, TLS 1.2 or your ability to remotely access your equipment might disappear.
What is TLS? TLS stands for Transport Layer Security and is the successor to Secure Sockets Layer (SSL). Many IP-based protocols such as HTTPS, SMTP, POP3 and FTP support TLS to encrypt data. There are a few different versions of TLS that are being used by websites today with a range including 1.0, 1.1, 1.2 and the most recently released version 1.3.
The problem with 1.0 and 1.1 is that they have been in use for years and have endured many patches and revisions. Concerns over the level of security and vulnerabilities have led to the development of 1.3 on a clean slate. Google, Apple, Microsoft and Mozilla are all eliminating support for 1.0 and 1.1, leaving 1.2 as the default version. The migration of these browser software releases has started and will continue through 2020.
OK, Let’s get back to the first issue which is the implementation of TLS 1.3. The primary benefits of TLS 1.3 are faster speeds and better security. The problem with TLS 1.3 is that it breaks out-of-band monitoring for Data Loss Protection (DLP), Intrusion Detection Systems and Intrusion Prevention Systems (IDS/IPS), malware detection, PCAP, DDoS mitigation and other “middle-box” monitoring and security devices.
Notes about Encryption Why is this important? TLS supports the encryption of data. Middle boxes need visibility to encrypted data in order to carry out performance and security monitoring. Here are a few bullets about data encryption: • 70% of Web traffic is encrypted and growing • The range of encrypted traffic in the Data Center is about 25-50% • 50% of malware downloads are encrypted • 60% of visibility is lost when implementing Perfect Forward Security (PFS) 1.2 from RSA 1.2
Middle-Box Solutions Monitoring and security tools connect to links for visibility necessary to monitor, report and protect network information. Independent TAPs and Packet Brokers connect these tools to network links, make a mirror copy of the traffic for tools while sending live traffic on through the network. This is the case with encrypted TLS 1.0 and 1.1 and 1.2 traffic. The TAP and Packet Broker typically do not open the packets or inspect payload so encryption is not a big issue. Traffic is passed to the tools and on to the network in its original form. One of the key benefits of using TAPs and Packet Brokers, is that they provide visibility to the network tools without impacting live traffic or adding latency to the network. Packet inspection, reporting and blocking when necessary, is the job of the network tools. When TLS 1.3 becomes widely used, there will be issues with these middle-box tools decrypting packets using the new format.
Work-arounds are being developed and tested that will maintain visibility to encrypted packets for monitoring and security tools. Some Packet Broker vendors are trying to integrate the decryption and encryption. This functional integration idea will inject additional delay in the network as the visibility devices decrypt, open, inspect and encrypt packets. While this may work in smaller implementations, it will fail in bigger deployments especially in scenarios where hundreds & thousands of encryption keys are in play and need to be managed. Companies are working on software solutions and other integration points in the network architecture. There will soon be a variety of TLS 1.3 compliant options introduced to mitigate the visibility issue while taking advantage of the security advances. Our position is that TAPs and Packet Brokers should continue to provide their full packet delivery functions without adding network delay.
TAPs and Packet Brokers Updated On the second issue, my key point is that as TLS 1.2 and 1.3 become more prevalent, many legacy networking equipment may need to be upgraded or changed out. This includes TAPs and Packet Brokers. We have updated SW releases for all of our current portfolio that support TLS 1.2, so at a minimum, contact us to ensure you are running the latest firmware release. However, if you are upgrading your middle boxes, then you should consider refreshing older TAPs and Packet Brokers to updated models with more modern technology & features.
Got Questions? Our theory is that if you are a security software engineer you already understand the issue. The solution is unfortunately much more opaque. Some of you probably also have strong opinions around how & where to solve the issues. For the rest of you who are in the “collecting information” stage, feel free to give us a call to discuss in more detail.