Network traffic encryption and decryption processing method and system
By dynamically constructing decryption and re-encryption paths through the SSLO gateway and utilizing virtual communication ports and independent proxy modules, the rigidity of HTTPS traffic processing paths and tight system coupling in existing technologies are resolved. This enables on-demand processing and efficient resource utilization, thereby improving system flexibility and security.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-19
- Publication Date
- 2026-04-03
AI Technical Summary
In existing technologies, the decryption and re-encryption processing path of HTTPS traffic is rigid, which causes unencrypted traffic to also consume resources. The system is tightly coupled, with poor flexibility and maintainability, and cannot allocate processing resources as needed.
By using an SSLO gateway to unify access and determine traffic types, dynamically construct decryption and re-encryption paths, and utilize virtual communication ports and independent encryption/decryption proxy modules, precise on-demand processing of traffic can be achieved.
It improves system flexibility and resource utilization efficiency, reduces the invalid occupation of unencrypted traffic, enhances throughput and overall system performance in high-concurrency mixed traffic scenarios, and ensures the integrity of secure processing.
Smart Images
Figure CN121792149A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer network and information security technology, and more specifically, to a method for encrypting and decrypting network traffic. Background Technology
[0002] In applications such as network security and content auditing, it is often necessary to decrypt, inspect, or modify encrypted traffic such as HTTPS, and then re-encrypt and forward it to the backend server. A typical implementation is to deploy two reverse proxy servers (such as Nginx) in series: the first proxy is responsible for SSL termination (decryption), and the second proxy is responsible for SSL initiation (re-encryption).
[0003] However, this traditional series mode has inherent drawbacks:
[0004] 1. Rigid Processing Path: All incoming TCP connections, regardless of whether they are HTTPS traffic requiring decryption, must pass through these two proxies. For large volumes of pure TCP traffic or HTTP traffic that does not require decryption, this path causes unnecessary performance overhead and latency.
[0005] 2. Tightly coupled system: The decryption and re-encryption functions are fixed on two specific proxy implementations, forming a tight coupling. Failure, upgrade, or configuration change of either party may affect the entire link, resulting in poor system resilience and maintainability.
[0006] 3. Resources cannot be allocated on demand: Processing resources cannot be allocated differently based on whether traffic requires encryption or decryption. In mixed traffic scenarios, valuable encryption / decryption proxy resources may be occupied by a large amount of unencrypted traffic, leading to processing bottlenecks. Summary of the Invention
[0007] The purpose of this invention is to provide a method for encrypting and decrypting network traffic to solve the problems mentioned in the background section.
[0008] To achieve the above objectives, the present invention aims to provide a network traffic encryption and decryption processing method, comprising: S1: unified access and traffic type determination: the SSLO gateway receives a network connection initiated by the client and performs protocol type analysis on the traffic carried by the connection to determine its traffic type, wherein the traffic type includes encrypted traffic and unencrypted traffic.
[0009] S2: Dynamically construct and execute the decryption processing path: If the judgment result of S1 is encrypted traffic, the SSLO gateway dynamically constructs a decryption processing path, guides the encrypted traffic to the first encryption / decryption proxy module for decryption, and the SSLO gateway receives the plaintext data output after decryption.
[0010] S3: Dynamically construct and execute a re-encryption and forwarding path: The SSLO gateway continues to dynamically construct a re-encryption and forwarding path, guiding the plaintext data to the second encryption / decryption proxy module for re-encryption, and forwarding the re-encrypted data to the target backend server.
[0011] S4: Construct and execute a fast direct connection path: If the judgment result of S1 is unencrypted traffic, then the SSLO gateway constructs a fast direct connection path to bypass the first encryption / decryption proxy module and the second encryption / decryption proxy module and directly forward the unencrypted traffic to the target backend server.
[0012] As a further improvement to this technical solution, the SSLO gateway is used to create and manage a first virtual communication port, a second virtual communication port, a third virtual communication port, and a fourth virtual communication port, wherein the first virtual communication port, the second virtual communication port, the third virtual communication port, and the fourth virtual communication port are virtual network interfaces created at the operating system level.
[0013] As a further improvement to this technical solution, the method for analyzing the protocol type of the traffic carried by the connection to determine its traffic type is as follows: The asynchronous IO interface of the SSLO gateway captures the first packet of the network connection and temporarily stores the packet data in a memory pool. The port characteristics and protocol header characteristics of the first packet are extracted. If the port characteristics and protocol header characteristics do not have a clear indication, the payload characteristics are extracted. The extracted characteristics are matched with a preset rule base. If the port characteristics or protocol header characteristics of the traffic match the preset rule base, the traffic is directly determined to be encrypted traffic. If the port characteristics and protocol header characteristics of the traffic do not have a clear indication, but the payload characteristics contain encryption signatures, the traffic is further determined to be encrypted traffic. If none of the above characteristics match, the traffic is determined to be unencrypted traffic.
[0014] As a further improvement to this technical solution, the dynamic construction and execution of the decryption processing path specifically includes: S2a: dynamically guiding all data of the encrypted connection to the first virtual communication port, wherein the first encryption / decryption proxy module listens on the first virtual communication port and is configured as an SSL terminal, thereby performing SSL decryption processing on the encrypted traffic and outputting plaintext data.
[0015] S2b: The SSLO gateway receives the plaintext data output by the first encryption / decryption proxy module from the second virtual communication port.
[0016] As a further improvement to this technical solution, the dynamic construction and execution of the re-encryption and forwarding path specifically includes: S3a: dynamically guiding the plaintext data to the third virtual communication port, wherein the second encryption / decryption proxy module listens on the third virtual communication port and is configured as an SSL initiator, thereby performing SSL re-encryption processing on the plaintext data.
[0017] S3b: The SSLO gateway receives the re-encrypted data output by the second encryption / decryption proxy module from the fourth virtual communication port and forwards it to the target backend server.
[0018] As a further improvement to this technical solution, the first encryption / decryption proxy module and the second encryption / decryption proxy module are reverse proxy service embodiments that operate independently of each other. The first encryption / decryption proxy module and the second encryption / decryption proxy module communicate with the SSLO gateway by binding to the corresponding virtual network interface.
[0019] A second aspect of the present invention provides a system for network traffic encryption and decryption processing, comprising: an SSLO gateway module for receiving network connections, identifying traffic types, dynamically constructing processing paths, and managing virtual communication ports.
[0020] The first encryption / decryption proxy module is connected to the SSLO gateway and is used to decrypt encrypted traffic.
[0021] The second encryption / decryption proxy module is connected to the SSLO gateway and is used to re-encrypt plaintext traffic.
[0022] As a further improvement to this technical solution, the SSLO gateway includes: a traffic type identification unit, used to analyze the protocol characteristics of network connections and distinguish between encrypted traffic and unencrypted traffic.
[0023] The path building unit is used to dynamically select the following paths based on traffic type:
[0024] (1) Encrypted traffic processing path: The encrypted traffic is guided to the first encryption / decryption proxy module for decryption, and then the decrypted plaintext is guided to the second encryption / decryption proxy module for re-encryption.
[0025] (2) Fast direct connection path: Unencrypted traffic bypasses the first and second encryption / decryption proxy modules and is directly forwarded to the backend server.
[0026] Compared with the prior art, the beneficial effects of the present invention are as follows:
[0027] 1. It achieves precise on-demand invocation of encryption and decryption processing: Only encrypted traffic that is identified as needing decryption will be scheduled to the encryption and decryption proxy resources for processing, avoiding the invalid occupation of the encryption and decryption module by unencrypted traffic, and greatly improving the overall system throughput and resource utilization efficiency in high-concurrency mixed traffic scenarios.
[0028] 2. Dynamic construction and decoupling of processing links are achieved: Through the SSLO gateway and virtual communication port technology, the originally physically or logically fixed "proxy A -> proxy B" serial link is deconstructed into a virtual processing chain that can be dynamically assembled or skipped according to traffic type. The encryption and decryption proxy modules become a "function pool" called by the SSLO gateway, which is independent of each other and can be easily expanded, upgraded or replaced individually.
[0029] 3. Improved system flexibility and maintainability: Changes to encryption / decryption strategies (such as certificates and cipher suites) only require configuration on the corresponding independent proxy module; the SSLO gateway's path control logic remains unchanged. The system can flexibly adapt to future new encryption protocols or processing requirements.
[0030] 4. Ensures the integrity and security of the processing process: For encrypted traffic that needs to be processed, this invention still ensures that it must go through a complete security processing chain of "decryption -> (optional content processing) -> re-encryption", which meets the rigid requirements of business scenarios such as security auditing. Attached Figure Description
[0031] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0032] Figure 1 This is a schematic diagram of the implementation steps of the method of the present invention.
[0033] Figure 2 This is a schematic diagram of the system structure connection of the present invention. Detailed Implementation
[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.
[0035] Example: Please refer to Figure 1As shown, a network traffic encryption and decryption processing method is provided, including: S1: Unified access and traffic type judgment: The SSLO gateway receives the network connection initiated by the client and performs protocol type analysis on the traffic carried by the connection to determine its traffic type, wherein the traffic type includes encrypted traffic and unencrypted traffic.
[0036] In one specific embodiment, the SSLO gateway is used to create and manage a first virtual communication port, a second virtual communication port, a third virtual communication port, and a fourth virtual communication port, wherein the first virtual communication port, the second virtual communication port, the third virtual communication port, and the fourth virtual communication port are virtual network interfaces created at the operating system level.
[0037] In one specific embodiment, the method for analyzing the protocol type of the traffic carried by the connection to determine its traffic type is as follows: The asynchronous IO interface of the SSLO gateway captures the first packet of the network connection and temporarily stores the packet data in a memory pool. The port characteristics and protocol header characteristics of the first packet are extracted. If the port characteristics and protocol header characteristics do not have a clear indication, the payload characteristics are extracted. The extracted characteristics are matched with a preset rule base. If the port characteristics or protocol header characteristics of the traffic match the preset rule base, the traffic is directly determined to be encrypted traffic. If the port characteristics and protocol header characteristics of the traffic do not have a clear indication, but the payload characteristics contain encryption signatures, the traffic is further determined to be encrypted traffic. If none of the above characteristics match, the traffic is determined to be unencrypted traffic.
[0038] The lack of explicit indication of port characteristics and protocol header characteristics refers to situations where the port number (e.g., a non-standard port) and protocol header fields (e.g., no TLS / SSL identifier) extracted by the SSLO gateway cannot directly determine whether the traffic is encrypted or unencrypted based on predefined typical characteristics (e.g., port 443 corresponds to HTTPS, and the protocol header contains a TLS version number). In such cases, further analysis of the packet payload is required to obtain a more accurate basis for judgment.
[0039] In another embodiment, the asynchronous I / O interface is vpp::net::udp_socket or vpp::net::tcp_socket.
[0040] Port characteristics: Destination port / source port for parsing packets (e.g., 443 and 8443 are typical ports for HTTPS encrypted traffic);
[0041] Protocol header characteristics: Parse the transport layer / application layer protocol header. If it contains TLS / SSL handshake packet characteristics (such as ClientHello message, TLS version number field 0x0303 / 0x0304), it is determined to be encrypted traffic; if it is a TCP / UDP bare packet (without TLS / SSL header), it is determined to be unencrypted traffic.
[0042] Payload characteristics: For packets without explicit port / protocol header characteristics, parse the first 16 bytes of payload. If it contains a fixed signature of encrypted traffic (such as the TLS extension field 0x0000), further verify that it is encrypted traffic.
[0043] The pre-defined rule base is based on the induction and abstraction of known network protocol characteristics: by collecting typical communication samples of common encrypted protocols (such as TLS / SSL, SSH) and unencrypted protocols (such as HTTP, FTP), its standard port range, protocol header structure characteristics, and payload key byte patterns are extracted and solidified to form a set of feature rules that can be quickly matched. The rule base can be dynamically updated and optimized in combination with the actual network environment to ensure the ability to identify new or variant protocols.
[0044] S2: Dynamically construct and execute the decryption processing path: If the judgment result of S1 is encrypted traffic, the SSLO gateway dynamically constructs a decryption processing path, guides the encrypted traffic to the first encryption / decryption proxy module for decryption, and the SSLO gateway receives the plaintext data output after decryption.
[0045] In one specific embodiment, the dynamic construction and execution of the decryption processing path specifically includes: S2a: dynamically guiding all data of the encrypted connection to the first virtual communication port, wherein the first encryption / decryption proxy module listens on the first virtual communication port and is configured as an SSL terminal, thereby performing SSL decryption processing on the encrypted traffic and outputting plaintext data.
[0046] S2b: The SSLO gateway receives the plaintext data output by the first encryption / decryption proxy module from the second virtual communication port.
[0047] S3: Dynamically construct and execute a re-encryption and forwarding path: The SSLO gateway continues to dynamically construct a re-encryption and forwarding path, guiding the plaintext data to the second encryption / decryption proxy module for re-encryption, and forwarding the re-encrypted data to the target backend server.
[0048] In one specific embodiment, the dynamic construction and execution of the re-encryption and forwarding path specifically includes: S3a: dynamically guiding the plaintext data to a third virtual communication port, wherein the second encryption / decryption proxy module listens on the third virtual communication port and is configured as an SSL initiator, thereby performing SSL re-encryption processing on the plaintext data.
[0049] S3b: The SSLO gateway receives the re-encrypted data output by the second encryption / decryption proxy module from the fourth virtual communication port and forwards it to the target backend server.
[0050] In one specific embodiment, the first encryption / decryption proxy module and the second encryption / decryption proxy module are reverse proxy service embodiments that operate independently of each other. The first encryption / decryption proxy module and the second encryption / decryption proxy module communicate with the SSLO gateway by binding to the corresponding virtual network interface.
[0051] The first encryption / decryption proxy module and the second encryption / decryption proxy module are HAProxy, Nginx or Traefik, and this invention takes Nginx as an example.
[0052] S4: Construct and execute a fast direct connection path: If the judgment result of S1 is unencrypted traffic, then the SSLO gateway constructs a fast direct connection path to bypass the first encryption / decryption proxy module and the second encryption / decryption proxy module and directly forward the unencrypted traffic to the target backend server.
[0053] Another embodiment of the present invention specifically includes:
[0054] Device and Module Deployment: SSLO Device and Module Deployment. Building an SSLO processing device and integrating it within the device:
[0055] Traffic type determination module (SSLO asynchronous driver);
[0056] SSLO high-concurrency forwarding module;
[0057] Two Nginx proxies (each associated with SSL decryption and SSL re-encryption functions); the two Nginx proxies are deployed in the user space of the SSLO processing device, and Nginx1 is bound to virtual port 1 and virtual port 2, and Nginx2 is bound to virtual port 3 and virtual port 4.
[0058] Layered adaptation module for physical network ports (Eth1~Eth4) and virtual interfaces (virtual port 1~virtual port 4).
[0059] SSLO-driven traffic reception and classification: Client traffic is received through the Eth1 of the SSLO device. The SSLO traffic type judgment module (based on asynchronous IO driver) identifies the traffic type and classifies it into HTTPS traffic and non-HTTPS traffic.
[0060] SSLO-guided HTTPS traffic encryption / decryption link
[0061] For HTTPS traffic: SSLO directs it to virtual port 1, which connects to the Nginx1 entry point. Nginx1 then completes the SSL decryption. After decryption, the traffic is scheduled by SSLO and forwarded to the Eth2_SSL channel via virtual port 2.
[0062] For decrypted HTTPS traffic: it is passed to virtual port 3 via the SSLO high-concurrency forwarding module, accesses the Nginx2 entry point to complete SSL re-encryption, and then forwarded to the Eth4_SSL channel via virtual port 4.
[0063] SSLO high-concurrency forwarding of non-HTTPS traffic: Non-HTTPS traffic is directly guided to the Eth2_Forward channel by the SSLO traffic type determination module, and then passed to the Eth4_Forward channel by the SSLO high-concurrency forwarding module.
[0064] Traffic is uniformly distributed to backend servers via the Eth4 of the SSLO device, which distributes encrypted HTTPS traffic from the Eth4_SSL channel and non-HTTPS traffic from the Eth4_Forward channel to the backend servers.
[0065] The validity of the SSLO link is verified by using the traffic monitoring tools built into SSLO to capture and analyze packets on the SSLO device, Nginx node, and backend server sides to verify whether the processing and forwarding results of various types of traffic meet expectations.
[0066] See Figure 2 As shown, a system providing a network traffic encryption and decryption processing method includes: an SSLO gateway module, used to receive network connections, identify traffic types, dynamically construct processing paths, and manage virtual communication ports.
[0067] The first encryption / decryption proxy module is connected to the SSLO gateway and is used to decrypt encrypted traffic.
[0068] The second encryption / decryption proxy module is connected to the SSLO gateway and is used to re-encrypt plaintext traffic.
[0069] In one specific embodiment, the SSLO gateway includes: a traffic type identification unit, used to analyze the protocol characteristics of the network connection and distinguish between encrypted traffic and unencrypted traffic.
[0070] The path building unit is used to dynamically select the following paths based on traffic type:
[0071] (1) Encrypted traffic processing path: The encrypted traffic is guided to the first encryption / decryption proxy module for decryption, and then the decrypted plaintext is guided to the second encryption / decryption proxy module for re-encryption.
[0072] (2) Fast direct connection path: Unencrypted traffic bypasses the first and second encryption / decryption proxy modules and is directly forwarded to the backend server.
[0073] The foregoing has shown and described the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely preferred examples and are not intended to limit the invention. Various changes and modifications can be made to the invention without departing from its spirit and scope, and all such changes and modifications fall within the scope of the claimed invention.
Claims
1. A method for encrypting and decrypting network traffic, characterized in that, include: S1: Unified Access and Traffic Type Judgment: The SSLO gateway receives network connections initiated by clients and performs protocol type analysis on the traffic carried by the connection to determine its traffic type, which includes encrypted traffic and unencrypted traffic; S2: Dynamically construct and execute the decryption processing path: If the judgment result of S1 is encrypted traffic, the SSLO gateway dynamically constructs a decryption processing path, guides the encrypted traffic to the first encryption / decryption proxy module for decryption, and the SSLO gateway receives the plaintext data output after decryption. S3: Dynamically construct and execute a re-encryption and forwarding path: The SSLO gateway continues to dynamically construct a re-encryption and forwarding path, guiding the plaintext data to the second encryption / decryption proxy module for re-encryption, and forwarding the re-encrypted data to the target backend server; S4: Construct and execute a fast direct connection path: If the judgment result of S1 is unencrypted traffic, then the SSLO gateway constructs a fast direct connection path to bypass the first encryption / decryption proxy module and the second encryption / decryption proxy module and directly forward the unencrypted traffic to the target backend server.
2. The network traffic encryption / decryption method according to claim 1, characterized in that, The SSLO gateway is used to create and manage a first virtual communication port, a second virtual communication port, a third virtual communication port, and a fourth virtual communication port, which are virtual network interfaces created at the operating system level.
3. The network traffic encryption / decryption method according to claim 1, characterized in that, The specific implementation method for analyzing the protocol type of the traffic carried by the connection to determine its traffic type is as follows: The asynchronous I / O interface of the SSLO gateway captures the first packet of the network connection and temporarily stores the packet data in a memory pool. It extracts the port features and protocol header features of the first packet. If the port features and protocol header features do not have a clear indication, it extracts the payload features. The extracted features are matched with a preset rule base. If the port features or protocol header features of the traffic match the preset rule base, the traffic is directly determined to be encrypted traffic. If the port features and protocol header features of the traffic do not have a clear indication, but the payload features contain encryption signatures, the traffic is further determined to be encrypted traffic. If none of the above features match, the traffic is determined to be unencrypted traffic.
4. The network traffic encryption / decryption method according to claim 1, characterized in that, The dynamically constructed and executed decryption processing path specifically includes: S2a: Dynamically direct all data from the encrypted connection to the first virtual communication port, wherein the first encryption / decryption proxy module listens on the first virtual communication port and is configured as an SSL terminal, thereby performing SSL decryption processing on the encrypted traffic and outputting plaintext data; S2b: The plaintext data output by the first encryption / decryption proxy module is output from the second virtual communication port of the SSLO gateway.
5. The network traffic encryption / decryption method according to claim 1, characterized in that, The dynamic construction and execution of the re-encryption and forwarding path specifically includes: S3a: The plaintext data is dynamically directed to the third virtual communication port, wherein the second encryption / decryption proxy module listens on the third virtual communication port and is configured as an SSL initiator, thereby performing SSL re-encryption on the plaintext data; S3b: The re-encrypted data output by the second encryption / decryption proxy module is forwarded from the fourth virtual communication port of the SSLO gateway to the target backend server.
6. The network traffic encryption / decryption method according to claim 5, characterized in that, The first encryption / decryption proxy module and the second encryption / decryption proxy module are independent reverse proxy service implementations. The first encryption / decryption proxy module and the second encryption / decryption proxy module communicate with the SSLO gateway by binding to the corresponding virtual network interface.
7. A system for performing the network traffic encryption / decryption processing method according to any one of claims 1-6, characterized in that, include: The SSLO gateway module is used to receive network connections, identify traffic types, dynamically construct processing paths, and manage virtual communication ports. The first encryption / decryption proxy module is connected to the SSLO gateway and is used to decrypt encrypted traffic; The second encryption / decryption proxy module is connected to the SSLO gateway and is used to re-encrypt plaintext traffic.
8. A network traffic encryption / decryption processing system according to claim 7, characterized in that, The SSLO gateway includes: Traffic type identification unit is used to analyze the protocol characteristics of network connections and distinguish between encrypted and unencrypted traffic; The path building unit is used to dynamically select the following paths based on traffic type: (1) Encrypted traffic processing path: The encrypted traffic is directed to the first encryption / decryption proxy module for decryption, and then the decrypted plaintext is directed to the second encryption / decryption proxy module for re-encryption; (2) Fast direct connection path: Unencrypted traffic bypasses the first and second encryption / decryption proxy modules and is directly forwarded to the backend server.