A Deep Dive into Todyl's Web Proxy v2

At the end of 2021, we released the latest version of the Secure Global Network™ (SGN) Cloud Platform, the backbone of our Secure Access Service Edge (SASE) module. Since this launch, our SGN Engineering team has worked hard on the next version of our web proxy, a critical component of our SASE module. The web proxy handles all web requests, manages content filtering, performs multi-engine malware scanning, integrates and ships logs to Todyl’s SIEM, facilitates SSL inspection, and much more.

To start the project, the SGN Engineering and Product teams worked closely with partners to identify areas of improvement, including ways to:

• Enhance performance
• Reduce SSL conflicts
• Create a foundation for additional security modules and customizations in the future

After a few meetings, the mission was clear. The SGN Engineering team needed to rip out web proxy v1 and rebuild the web proxy module from the ground up.

Today, we're excited to announce that Todyl's Web Proxy v2 is live for every SASE user. In this blog, we dive deep into the new architecture and infrastructure that:

• Powers faster page load times, file downloads, and file scanning
• Results in fewer SSL conflicts
• Provides compatibility with HTTP/2 and TLS 1.3
• Serves as an incredibly strong foundation for exciting updates in the future

Setting the project parameters and goals

The web proxy ensures every TLS & HTTP packet is fast and secure, making it a critical yet sensitive component of SASE. In addition to performance and security, the SGN Engineering team aimed to significantly improve stability and reliability on a global scale.

While web proxy v1 delivered strong security, its structure had limitations, including an inability to account for new web traffic protocols, such as HTTP/2, and used a less efficient SSL inspection architecture. Also, each time we implemented updates, the original web proxy required a restart of all services, which created inefficiencies.

With web proxy v2, we wanted a dynamic system that solved these issues and delivered a better experience for our partners. The new web proxy needed to easily incorporate additional security controls, improve visibility, and increase reliability while ensuring every feature on v1 runs optimally on v2.

Finally, we needed to align the structure of the new web proxy with the experience of our engineering team. We wanted a web proxy that leveraged the team’s skillset without a steep learning curve.

We strive to deliver the best user experience and security. With this commitment to quality in mind, we determined rebuilding our existing web proxy from the ground up with a modern, dynamic infrastructure was the best path forward.

Updating the web proxy’s architecture

Web proxy v1 leveraged a static configuration that was not extendable, requiring our engineers to maintain multiple side applications to ensure every feature communicated and worked as expected.

We started by separating the data and control planes. In the new web proxy, the control plane manages the configurations and communicates with the data plane, which handles the packet processing and inspection. By separating the planes, we can dynamically update the data plane by applying real-time changes via the control plane.

Web proxy v2 also features built-in applications that eliminate external communication for improved reliability and less latency. Our Engineering and Security teams can efficiently push out intelligence updates and dynamically add security controls without a web proxy system reset (see Figure 2). These enhancements translate to more effective security without any impact on the user experience.

Performance and optimization with HTTP/2

With the new architecture implemented and the core functionality tested, the team switched focus to performance. Web proxy v2 leverages HTTP/2 for connection reuse and latency optimization, a significant change from web proxy v1.

Figure 3 details the agent making a request through web proxy v1, which only supported HTTP/1 protocols. With HTTP/1, a user makes a request to the web proxy, and the web proxy completes the TLS inspection process with the user. In this example, the web proxy sends the request to Google and relays the information the user requested. This process creates roundtrip time on both ends, and the web proxy must complete it for every request.

We'll use some round numbers to help exemplify the impact. If the user is 10ms away from the edge and the edge is 10ms away from Google, each initial web transaction would experience 160ms of latency to set up the TLS and HTTP TCP connections (see handshake graph below).

With HTTP/2, the web proxy establishes secure connections and maintains the previously negotiated TLS session so requests can be multiplexed and sent to the web much faster. Using the same example as above, each initial web transaction would likely experience 80ms of latency (120ms for unpopular sites). This 50% reduction results from the web proxy maintaining open HTTP/2 connections to recently visited websites. The real-world page load latency reduction is even higher due to HTTP/2 header compression and multiplexing all requests to the same website on a single TCP connection while improving TCP efficiency.

Since launching our beta testing phase, HTTP/2 traffic makes up 80% of traffic on average (see Figure 4). The upgraded web proxy also enables our engineers to upgrade the web proxy system and account for any new HTTP/3 iterations with a flip of a switch, ensuring we continuously deliver the best browsing experience for our partners and their clients.

One more goal of web proxy v2 was to ensure a seamless experience for partners across every application they use while leveraging SASE. The new web proxy accomplishes this via an enhanced SSL inspection process and by managing non-HTTP traffic, so applications run more smoothly.

There are many additional benefits of the new web proxy v2, but overall the upgraded structure of the web proxy v2 helps us deliver better security and a faster, more reliable experience.