As you may have known SSL died in 2015, largely due to the “Poodle” vulnerability, long live its successor TLS! What you may not know is a new version of TLS, version 1.3, has been approved and is going to force you to change a number of your network security practices. Most information out in the wild about TLS v1.3 has been focused on improvements in speed, deprecation of older features, and new ciphers / algorithms. But there is one new feature in particular that network & server administrators should be in a hurry to get in front of, as it’s the one big “Gotcha” of the new standard:
TLS v1.3 mandates perfect forward secrecy (PFS).
What is Perfect Forward Secrecy?
In short, perfect forward secrecy (PFS) secures each individual session in a way that makes decrypting past conversations difficult and limited. Without PFS all you need is the private key and passphrase (if one was set), and you can decrypt recorded conversations. When PFS is used, a unique session key is generated for each individual session, which means even if you had the private key and the individual session key you could only decrypt that particular conversation.
Why Should We Care?
While some ciphers in TLS 1.2 support perfect forward secrecy, use of them was not mandated. Since TLS 1.3 mandate’s the use of PFS, it makes passive monitoring of encrypted traffic virtually impossible overnight. What is meant by passive monitoring, you ask? If you captured network traffic a week ago and wanted to analyze it at your convenience because you have the private key to decrypt it, you will not be able to unless you had the unique session key generated for that individual session. This doesn’t just apply to humans performing packet captures a.k.a. “sniffing” traffic – if you have network security appliances that are not directly participating in the encrypt / decrypt path (i.e. terminating the TLS connections) they will no longer be able to decrypt, inspect, and process the unencrypted traffic – again, each session has its own secret key in addition to the traditional key that works with the certificate.
Is TLS v1.3 Faster than the older version of TLS?
You’ll find lots of information discussing the improved speed of the TLS 1.3 handshake – TLS 1.2 takes two round-trips from each host to complete the handshake – in TLS 1.3 it only takes one round-trip. However, what few are talking about is the increased overhead on the servers and network / security devices that need to decrypt and re-encrypt the stronger more complex cipher suite. At scale this may outweigh the benefits of the improved TLS 1.3 handshake efficiency, but there is only one way to tell, test it! We’re working on some real world tests and will post results as soon as the lab work is complete!
How to Support TLS V1.3 Successfully in an Enterprise Environment for Incoming Traffic
How should local administrators and all the folks that will be affected by TLS v1.3 start preparing for TLS v1.3? It’s not always realistic to make an investment vendor-wide across servers and network / security devices, however, an alternative to facilitating a larger TLS v1.3 support model is to use a full proxy device in the traffic path that is very efficient at decrypting and encrypting TLS v1.3 (a.k.a. an “SSL / TLS Terminating device”). You can then terminate the TLS 1.3 sessions at the network’s edge on the client-side of the Full Proxy and then downgrade to non-PFS ciphers on the server-side inside your network, or even completely offload the SSL. Doing that will allow you to satisfy the new mandate externally from the untrusted Internet, and your internal devices can work as they do today without making any SSL / TLS changes on them.
The F5® BIG-IP® is a true Full Proxy and is the leader in SSL/TLS encryption & decryption. F5’s purpose-built hardware and software is able to terminate TLS 1.3 using perfect forward secrecy and then forward traffic to your backend servers using non-PFS cipher suites or offloading SSL all together.
SSL Orchestrator® – Decrypting SSL / TLS in Bulk
That is what F5 has been known for, full proxy flexibility – augmenting client-side and server-side connections like a traffic ninja. What’s even more exciting is F5’s new SSL Orchestrator (SSLO). SSLO is a new BIG-IP module that gives you the ability to terminate TLS v1.3 in “bulk”. SSLO gives you the ability to create a hardened secure inspection zone for safe unencrypted inspection & the ability to easily add or remove security devices to the inspection zone – F5 calls this “Dynamic Service Chaining”. The “add & remove” capability is super powerful and will future-proof your environment. Think of the headache you would have if you buy a new security solution that needed to be inline with your main websites network path… Implementing it would be super intrusive and require some complicated coordination – but not if you have the SSLO! If you’re using SSLO you can just drop it in the dynamic service chain, and easily direct your admins through it for testing – once it is proven out you could easily add it to the full chain.
How to Support TLS V1.3 Successfully in an Enterprise Environment for Outgoing Traffic
While thinking about how to inspect these inbound traffic use cases, it is important that we are also thinking about outbound inspection needs. If you are not decrypting outbound traffic, you are already failing to inspect large amounts of malicious behavior, data leakage, etc. Organizations that have begun decrypting outgoing internet-bound SSL/TLS traffic are realizing the limitations of their inspection devices. Some devices cannot decrypt, some cannot decrypt at scale, some cannot decrypt cost-effectively, and it’s only going to get worse with TLS 1.3. Additionally, daisy-chaining multiple appliances creates numerous points of failure, increased latency, and more complexity to manage SSL certificates in multiple locations.
What to do? Again the F5 BIG-IP with SSLO in the path is a perfect solution for a high performance, cost-effective, and scalable solution pattern that can decrypt your outbound users’ traffic, forward to your inspection devices, and then re-encrypt out to the internet. It supports transparent & explicit proxy, inline layer 2 / layer 3, ICAP, receive only modes, and provides granular bypass control that allows you to conditionally forward to these devices based on a number of different criteria.
All that is awesome, but arguably the biggest benefit of using SSLO is the cost savings on the expensive security hardware / software – how so, you ask? Terminating SSL/TLS is resource intensive, and subsequently you’ll need to buy bigger devices or licenses when purchasing your fancy security solutions – but since SSLO is doing all the heavy lifting, you can save money on the security solutions you purchase as they’ll only ever see the unencrypted traffic safely in the decrypted SSL / TLS zone. Otherwise, you’ll need to overspend on each security platform to handle the SSL/TLS decryption, and manage those keys on every device.
I hope this gave you some high level insight into TLS V1.3 and how you can start preparing for it with F5’s SSLO module. Note – limited support for TLS v1.3 started in BIG-IP v14.0.0, with production level support introduced in v14.1.0.1… v15.0.0 and later extends TLS v1.3 support and includes SSLO support for inbound traffic. Get the skinny on F5’s support for TLS v1.3 here: https://support.f5.com/csp/article/K10251520
Questions? Comments? Post them below and we’ll get right back to you!
Very interested to see the impact of PFS in the wild, we’ll see how much TLS 1.3 gets adopted. Only time will tell. Great article, ty – we’re interested in discussing SSLO, will reach out.