TLS 1.3 has been approved by the Internet Engineering Task Force (IETF). It contains “major improvements in the areas of security, performance, and privacy”, and unlike TLS 1.2, there appears to be built-in motivation to upgrade. The performance boost TLS 1.3 offers will on its own perk up the ears of more than just security folks.
The benefits TLS 1.3 offers are substantial; but more comprehensive encryption also makes it tougher to spot malicious traffic and defend against attacks hidden in that encrypted traffic. This is a real threat: recent F5 Labs research found that 68% of malware hides within encryption. You may need to take a new approach to get the visibility you need while preserving the performance gain you realize with the updated protocol.
The benefits of TLS 1.3 are substantial; but more comprehensive encryption also makes it tougher to spot malicious traffic.
TLS 1.3 offers some great improvements over TLS 1.2. Vulnerable optional parts of the protocol have been removed, there’s support for stronger ciphers that are required to implement perfect forward secrecy (PFS), and the handshake process has been significantly shortened.
In addition, implementing TLS 1.3 should be relatively simple. You can use the same keys you used for TLS 1.2. Clients and servers will automatically negotiate a TLS 1.3 handshake when they both support it, and most mainstream browsers do by default on the latest versions.
Although TLS 1.2 can still be deployed securely, several high-profile vulnerabilities have exploited optional parts of the protocol and outdated ciphers. TLS 1.3 removes many of these problematic options and only includes support for algorithms that currently have no known vulnerabilities.
The IETF chose to remove all ciphers that do not support PFS from TLS connections, including DES, AES- CBC, RC4, and other ciphers less commonly used. They also removed the ability to perform what’s known as “renegotiation,” which allows a client and server that already have a TLS connection to negotiate new parameters, generate new keys, and so on. Eliminating renegotiation closes a window of opportunity for an attack.
TLS 1.3 also enables PFS by default. This cryptographic technique adds another layer of confidentiality to an encrypted session, ensuring that only the two endpoints can decrypt the traffic. With PFS, even if a third party were to record an encrypted session, and later gain access to the server private key, they could not use that key to decrypt the session.
In terms of performance, TLS 1.3 shaves an entire round trip from the connection establishment handshake, which cuts the encryption latency in half. Another advantage is that when you access a site you’ve previously visited, you can now send data on the first message to the server. This is called a "zero round trip time" (0-RTT). These enhancements—coupled with efficient modern cryptographic algorithms—can make TLS 1.3 faster than TLS 1.2.
With all these benefits, what could possibly be a problem? So glad you asked! With PFS, only the endpoints (the web user and the application server), can decrypt the traffic. However, it’s likely that you have one or more solutions—such as a next-generation firewall, an intrusion detection system (IDS), or a malware sandbox—designed to spot malicious traffic egressing your network. Alternatively, you might have a web application firewall, IDS, or an analytics solution in front of an application that you host. All these solutions sit between a user and the application or website they are connected to, so they are typically blind to the encrypted traffic.
Some security inspection tools do have the ability to decrypt; however, this often comes with performance hits to the tools and adds complexity to your network architecture. Also, blindly decrypting everything may introduce privacy regulation violations.
It's worth mentioning is that some security experts are up in arms over the 0-RTT feature, because of the potential for replay attacks. And without 0-RTT enabled within the TLS configuration, you may lose most of the performance boost that motivated you to implement in the first place.
The decision to implement TLS 1.3 at this point will depend on your requirements and motivations. There are some browsers that do not support 1.3, which could result in a bad user experience. Additionally, if you take out potentially vulnerable features like renegotiation and use PFS for your applications’ TLS 1.2 configuration, you get all the same security and privacy benefits as TLS 1.3. As far as a potential performance boost, you should perform thorough testing to see if this is true for your application as it may not be worth the effort with 0-RTT disabled.
Whatever your decision, it doesn’t mean that previous versions of TLS are going away any time soon. Google has announced that they will deprecate TLS 1.0 and 1.1 by 2020, so TLS 1.2 will continue to be around for quite a while. And, with the exception of some point-to-point API connections, you will need to continue support for TLS 1.2 (and possibly 1.1) for some time to ensure you do not break users’ connections to your applications.
Regardless of your TLS version, you need to have visibility into encrypted threats to protect your business. SSL/TLS based-decryption devices that allow for packet inspection can intercept encrypted traffic, decrypt, inspect, and re-encrypt untrusted TLS traffic entering or leaving the network—but that’s still not enough.
SSL/TLS based-decryption devices that allow for packet inspection can intercept encrypted traffic, decrypt, inspect, and re-encrypt untrusted TLS traffic entering or leaving the network—but that’s still not enough.
Security teams and network operations have found that setting up decryption zones isn’t easy. They often have to resort to manual daisy-chaining or tedious configuration to manage decryption/encryption across the entire security stack. And then they find that exceptions abound.
F5 SSL Orchestrator delivers visibility, but differentiates itself from the pack with orchestration that provides policy-based traffic steering to a service chain based on risk and dynamic network conditions. Because it functions as a full proxy for both SSL/TLS and HTTP, SSL Orchestrator can make intelligent decisions to steer inbound and outbound traffic to any combination of inspection tools within the security stack.
No matter how complicated your inbound and outbound encryption requirements are, SSL Orchestrator can bring visibility back to your inspection solutions, which helps keep your network—and your apps— more secure.
You can’t secure what you can’t see—understand how attackers use encryption to mask malware and data exfiltration and what you can do to block it.
Get insights into how and when your enterprise peers are adopting the new TLS 1.3 protocol version, and how you might be affected by a lack of visibility into encrypted traffic.
Discover how to quickly identify hidden threats and prevent attacks with full visibility into, and orchestration of, your encrypted traffic.
Ready to understand how to identify hidden threats and prevent attacks with SSL Orchestrator?
Contact F5 today.
