The new protocol version TLS 1.3 allows for safer network communication, while creating new security challenges and concerns. We recommend that you review the security features of your environment before TLS 1.3 becomes widely used.
The TLS protocol allows for network traffic encryption, which in turn allows for secure data exchange across private and public networks, such as the Internet. Usage of this protocol allows regular users to use secure communication during operations, such as online shopping, accessing online banks, and exchanging personal data. Behind the scenes, the protocol allows for secure email transport, secure voice and video transmission, etc.
The TLS protocol is derived from the Secure Sockets Layer (SSL) protocol, originally developed by Netscape in 1994. Usage of the SSL and early TLS versions is currently prohibited, due to insufficient security and a large number of known vulnerabilities. The current TLS versions are TLS 1.1 and TLS 1.2, as well as the upcoming TLS 1.3.
There are no significant changes in client-server communication when comparing various versions of SSL or TLS 1.1 or 1.2 protocols. This allows for a similar implementation by devices using these protocols to handle traffic as well as by devices performing traffic decryption and analysis. With TLS 1.3, however, there are significant changes.
Changes in the TLS 1.3 protocol
The main changes present in TLS 1.3 are:
- Removal of multiple obsolete algorithms, such as RC4, DES, 3DES, AES-CBC, MD5, and SHA-1. The current protocol version only uses AEAD-compliant algorithms;
- The protocol is no longer vulnerable to a plethora of attacks against TLS versions 1.2 and older, such as Lucky13, POODLE, SLOTH, CRIME, DROWN, etc.;
- The handshake procedure required to establish a secure connection between the client and the server has been significantly shortened. This results in decreased latency and increased speed of secure connection establishment, especially on mobile devices;
- With PFS enabled by default, an attacker cannot decrypt all the previously intercepted traffic by successfully decrypting a single encryption key;
- Web proxies, next generation firewalls and similar devices, currently used to intercept and decode encrypted traffic, cannot perform this task without the static RSA key exchange, which was removed from the current protocol version.
Especially the later presents the main concern when considering the decryption and inspection of TLS 1.3 traffic in modern IT environments. Two organizations, namely Enterprise Data Center Operators (EDCO) and BITS, the technology policy division of Financial Services Roundtable (FSR), expressed concern regarding the legitimate traffic decryption that is used by organizations to enforce data loss prevention, network troubleshooting, malware detection and compliance with regulations, such as PCI-DSS and HIPAA. The two organizations issued recommended addendums to the proposed TLS 1.3 standard:
- Usage of static Diffie-Hellman private keys
- Access to encrypted session’s plaintext, based on an opt-in mechanism.
Neither of these proposals were accepted for the final TLS 1.3 protocol draft. While the final TLS 1.3 protocol draft satisfies the relevant PCI-DSS and HIPAA requirements regarding securing and encrypting sensitive data, concerns regarding legitimate access to unencrypted traffic contents by solutions such as enterprise proxies and next-generation firewalls remain.
Regardless of the issues discussed herein, usage of TLS 1.3 by new versions of web browsers and web servers in enterprise environments remains an inevitability, which must be taken into consideration when revising security policies and performing cyber risk assessments.
How to mitigate the risks presented by the new TLS 1.3 encryption protocol?
How can you as IT managers retain a satisfactory level of IT environment and network security while allowing your users to communicate using the new security protocols? Multi-level approach works best:
- Securing the endpoints by preventing suspicious file storage and execution on devices, such as servers, laptops, and mobile devices. You can use solutions such as Cisco AMP and PaloAlto Traps
- Preventing unauthorized resource access by monitoring and filtering DNS requests using tools such as Cisco Umbrella
- Performing encrypted traffic analysis using tools such as Cisco ETA, which can use advanced machine learning and network analytics to detect threats in encrypted traffic without performing deep packet inspection and traffic decryption.
Unfortunately, there is no such thing as a perfect security solution, and caveats to using the above-mentioned security solutions still exist:
- Using SNI to control access to web resources can be bypassed after the encrypted session has already been established
- Securing the endpoints is only possible on managed endpoints. This is especially an issue within IoT environments, where we cannot alter the behavior of connected devices
- Limiting malicious resource access using DNS filtering is possible as long as enterprises do not implement DNS query encryption using tools such as DPRIVE.
IT managers and security engineers are encouraged to use the belt-and-suspenders principle when implementing security in a multi-level approach, as this is the only way to achieve true environment security.