Endpoint Local Proxy for SSL Traffic Inspection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing network information leakage prevention solutions face limitations in forwarding traffic from endpoints to cloud-based security gateways, particularly in outside network environments and with applications like messengers, leading to excessive internet delays and charges, and requiring physical equipment for transparent inline proxy methods.
Innovation Solution
A system and method utilizing a local proxy module within an endpoint to redirect and decode SSL traffic using network-kernel-based or application-socket-connection API hooking methods, allowing for out-of-path forwarding of SSL traffic to a security gateway for inspection, without the need for physical equipment, thereby minimizing network delays and charges.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If general endpoint traffic forwarding method is used to transmit traffic over the Internet through a cloud-based security gateway, then traffic inspection capability is provided, but excessive Internet delay and network charge occur
Solution Approach 1:
The patent segments the traffic forwarding process into two paths: SSL traffic is decoded and forwarded through the security gateway for inspection, while non-SSL traffic continues through the original Internet path without relay. This segmentation allows selective inspection of encrypted traffic without forcing all traffic through the cloud gateway, reducing unnecessary delay and network charges.
Solution Approach 2:
The local proxy module acts as an intermediary between the endpoint and the security gateway. It intercepts SSL traffic, decodes it, and forwards only the decoded traffic to the security gateway for inspection, while allowing non-SSL traffic to pass through unchanged. This intermediary approach enables targeted inspection without the performance penalty of relaying all traffic through the cloud.
2Ease of operation
If explicit proxy method is used with HTTP proxy settings in browsers, then browser traffic can be forwarded to gateway, but traffic of applications such as messenger cannot be forwarded
Solution Approach 1:
The local proxy module provides universal traffic interception capability that works for both browser traffic and application traffic (such as messenger). Instead of relying on browser-specific HTTP proxy settings, the proxy module operates at the network layer to intercept and forward SSL traffic from any application, making the system versatile across different types of traffic sources.
Solution Approach 2:
The patent replaces the mechanical browser configuration method (manual HTTP proxy settings in browsers) with an automated network-level proxy mechanism. The local proxy module uses network-kernel-based or API hooking methods to automatically intercept SSL traffic from applications without requiring user configuration, substituting manual browser settings with programmatic traffic interception.
3Reliability
If snipping method or transparent inline proxy method is used, then traffic monitoring is achieved, but physical equipment or components are necessary in inside network
Solution Approach 1:
The patent uses virtualization to replace physical monitoring equipment with software-based copying mechanisms. Instead of requiring physical SPAN ports or TAP devices in the network infrastructure, the local proxy module creates virtual copies of SSL traffic by intercepting and decoding encrypted connections locally at the endpoint, eliminating the need for physical monitoring hardware.
Solution Approach 2:
The patent substitutes mechanical physical equipment (Switch Port Analyzer, TAP, physical inline proxy) with software-based network-kernel-based or API hooking methods. The local proxy module implements traffic interception and monitoring through software mechanisms running on the endpoint device, replacing the need for dedicated physical monitoring hardware in the network infrastructure.
4Ease of operation
If port redirection method using L4 switch or firewall is used, then traffic redirection is achieved, but traffic of endpoint in outside network environment cannot be forwarded
Solution Approach 1:
The patent implements dynamic traffic redirection through the local proxy module that operates independently of network location. Instead of relying on static port redirection configurations in L4 switches or firewalls that work only in specific network zones, the proxy module dynamically intercepts and forwards SSL traffic from endpoints regardless of whether they are in inside or outside network environments, providing adaptable redirection capability.
Data Source
AI summary
Disclosed is a system for forwarding traffic of an endpoint. The system includes the endpoint configured to transmit traffic generated by an application to a server and a security gateway configured to receive the traffic from the endpoint and analyzes data related to information security of secure sockets layer (SSL) traffic among the traffic. Here, the endpoint includes a local redirection module configured to store redirection information including server connection information for transmitting the traffic to the server and to perform redirection related to transmission of the traffic and a local proxy module configured to decode the data with respect to the SSL traffic among the traffic received from the local redirection module and then to forward the decoded SSL traffic to the security gateway according to the redirection of the local redirection module.