After 4 years and 28 draft versions, TLS 1.3 is here and it will force a change to the way we do forensic investigations in Cyber Security. In order to fully understand the impact of TLS 1.3 on Security Incident Response we should first look at the role that packet capture takes in providing forensic data and how it is has historically been implemented.
How is packet capture implemented?
Packet capture can be thought of as a virtual security camera constantly watching what enters and exits the network. By that defintion it is neccessary to establish a choke point and funnel all of the enterprises’s ingress and egress traffic through such a system. This tends to enforce a network architecture model known as hub and spoke where traffic from remote locations (Spokes) is backhauled to a centralized location (Hub) where the packet capture function is employed.
In these Hub locations packet capture is commonly facilitated by utilzing smart inline taps, commonly refferred to as packet brokers, which send copies of the intercepted traffic to the various monitoring devices that might need to analyze the data. These packet brokers provide several functions like load balancing the traffic across destination monitoring systems, removing VLAN or MPLS headers, and pre-stage filtering to parse out specific protocol traffic to send to a particluar device. The addition of metadata like timestamps and geolocation info to the captured packets are also provided. Most importantly, in the context of this particular blog post, is the ability of the packet broker system to be preloaded with private encryption keys to decrypt SSL encrypted traffic prior to sending the data to monitoring devices. In this model, SSL decryption capability is performed passively, out of band and after the fact, rather than by having the packet broker system act as a man-in-the-middle proxy for the purpose of SSL decryption.
The role of packet capture in incident response
Packet capture provides the Security Incident Response Team the ability to go back in time and look into a potential security incursion that has occurred. This includes examining the behavior of a specific piece of malware such as determining what propagation techniques it uses, what additional files it attempts to download as well as determining the C&C domains and IPs in use that would need to be blocked by inline security controls to prevent additional attempts to download more malware or exfiltrate sensitive data from the impacted Enterprise. All of this data can be used to write detection signatures to prevent future occurences. Another benefit to incident response is the ability to replay the originally captured traffic through those newly written signatures to test proper detection of a specific threat. It is also very valuable in helping to determine the impact of a breach such as what accounts and systems were accessed and what sensitive data was actually exfiltrated.
However, with more and more enterprise traffic destined to the open internet and SaaS applications this backhauling model to do centralized packet capture comes at a cost. There is considerable impact to remote branch office and remote user performance due to the latency incurred in this traffic backhauling to a centralized “Hub” location model. Extending packet capture functionality to remote users that are off the corporate network requires enforcing a full tunnel VPN solution to bring them back onto the network where packet capture can happen at the network ingress/egress boundary. While it can also be debated that packet capture is primarily used forensically in a way that is analogous to solving crimes rather than preventing them, nevertheless it’s been an important tool in the Enterprise Security Incident Response Team’s toolbox for quite some time now.
So what is changing with TLS 1.3?
TLS 1.3 (RFC 8446) brings about some important changes which deliver security improvement and performance enhancements over version 1.2. Some of the more salient changes are:
- Faster session setup times as session completion is done in 1 round-trip versus the 2 round-trips required in TLS 1.2
- Zero Round Trip (0-RTT) which essentially lets you immediately send data to a server that you’ve previously communicated with also increases performance over TLS 1.2
- Removal of previously used insecure protocols, ciphers and algorithms
- Perfect Forward Secrecy (PFS) uses Ephemeral Diffie-Hellman key exchange protocol for generating dynamic one-time per session keys rather than a single static private key for every session
Why is TLS 1.3 going to impact our ability to effectively do packet capture?
This mandate of perfect forward secrecy (PFS) is what is going to force a change to the way we implement packet capture. PFS will prevent us from going back and doing passive after the fact decryption on traffic as there is no longer a single private key that can be used to decrypt prior sessions. Prior to the actual packet capture, TLS 1.3 decryption is going to require the use of an active “man-in-the-middle” (MITM) proxy which terminates each unique SSL (TLS 1.3) session from the client and opens a new TLS 1.3 session onward towards the origin content server that the client seeks to communicate with.
This will have both a resource and financial impact on the enterprise in that it will require either the purchase and deployment of dedicated MITM SSL decryption devices, or enabling MITM SSL decryption on previously in use web proxy appliances. Hopefully these previously purchased proxy appliances can actually support TLS 1.3 interception without requiring a hardware upgrade of the crypto chipset used under the hood. Even if a hardware upgrade/refresh isn’t required to support TLS 1.3, existing proxies will likely struggle to keep up with the performance impact of SSL inspecting all of this traffic and require additional capacity augmentation to be purchased. The net effect here is that continuing to do packet capture with TLS 1.3 in play will require a signifcant re-investment to the current “hub-and-spoke” centralized outbound security gateway stack model.
Of course full proliferation of TLS 1.3 onto both the client and server side is going to take some time. Major browsers like Chrome and Firefox already support it as of October 2018 and on the server side some large providers like Facebook, Google, Twitter, Microsoft and Cloudflare’s CDN have already started to run TLS 1.3 as well. Despite some early adoption, as of August 2018, Sandvine reports that only half a percent of all the encrypted traffic it sees is TLS 1.3.
Since it will take awhile before TLS 1.3 is maintstream, perhaps now is an opportunitistic time to really rethink our overall longer term network and security architecture strategy and consider whether continued re-investment in centralized backhaul and security appliance refresh is the best approach in the era of increasing cloud application usage and end user mobility. With applications and users leaving the traditional enterprise network perimeter does it really make sense to force users back onto the corporate network and continue to spend time and resources on a legacy hardware appliance based approach?
At Zscaler, we certainly believe that there is a better way to deliver a modern network and security architecture with full visibility into all of your enterprise’s encrypted traffic without compromises.
Disclaimer: The views expressed here are my own and do not necessarily reflect the views of my employer Zscaler, Inc.
References:
TLS 1.3 is moving forward: what you need to know today to get ready
TLS 1.3 – Impact on Network Based Security – draft-camwinget-tls-use-cases-00