A method for collecting and labeling API encrypted traffic based on middleman proxy
Through the middleman proxy technology, the problem of inaccurate encrypted API traffic collection and labeling in the existing technology is solved, accurate traffic collection and labeling in a customized environment is achieved, a decryptable data set is generated, and the accuracy and flexibility of traffic research are improved.
Patent Information
- Application Number
- CN202310769946.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2023-06-27
- Publication Date
- 2025-09-19
- Estimated Expiration
- 2043-06-27
AI Technical Summary
Existing traffic collection and annotation methods cannot provide specific parameter information of encrypted API traffic, resulting in inaccurate annotation, limited scope of application, and inability to perform detailed processing in customized environments.
A middleman-proxy-based method is adopted to detect and intercept network access requests from application terminals through the middleman proxy client, generate API interface documents, simulate network access requests on the cloud server side, generate simulated traffic, collect and decrypt encrypted communication traffic, and record communication logs and parameter information.
It achieves complete collection and accurate labeling of encrypted API traffic, can simulate requests with different parameters in a custom environment, generate decryptable traffic data sets, and improve the accuracy and flexibility of traffic research.
Smart Images

Figure CN116723238B_ABST
Abstract
Description
Technical Field
[0001] The present invention belongs to the technical field of network traffic data collection, and in particular to a method for collecting and labeling API encrypted traffic based on a middleman proxy. Background Art
[0002] With the rapid development of the internet, a wide range of applications, including web applications, mobile applications, and PC applications, have taken over people's lives. People use these applications to browse the web, acquire knowledge, shop online, and chat with friends. However, this has also raised security concerns: whether analyzing traffic can reveal user privacy, particularly the communication traffic between the target application and the server's Application Program Interface (API). Although most applications currently encrypt their traffic, encrypted traffic cannot completely conceal the underlying user behavior and application traffic characteristics. Therefore, analyzing and studying application network traffic requires large-scale collection and targeted annotation of encrypted application API traffic data. Therefore, the "API Encrypted Traffic Collection and Annotation System" can effectively meet these needs.
[0003] The current mainstream method for collecting application traffic is passive traffic collection, which mostly uses backbone network nodes of network service providers or other network interfaces that provide public network access services to specific organizations. While these key network nodes can capture large-scale web traffic data, they cannot provide detailed information about the traffic, particularly the source API, limiting their usefulness for traffic analysis.
[0004] Existing mainstream application traffic labeling methods primarily utilize DPI (Deep Packet Inspection) technology. This involves using existing DPI tools to parse collected data packets and identify fields with clear classification characteristics to classify the traffic. However, this method primarily targets unencrypted HTTP traffic and is ineffective for encrypted HTTPs traffic because it cannot parse encrypted packets. Furthermore, this method is difficult to achieve complete accuracy and is completely unsuitable for unfamiliar traffic from unknown web applications.
[0005] Existing data collection technologies mainly perform large-scale data collection on backbone network nodes. They are unable to refine the factors affecting traffic data and implement customized environmental parameters. The collected traffic data is usually interfered by unknown request parameter influencing factors, resulting in a single statistical distribution of traffic data or obvious fluctuations, which seriously affects subsequent research work. Therefore, traditional technologies are no longer suitable for labeling HTTPS traffic. Summary of the Invention
[0006] The purpose of the present invention is to provide an API encrypted traffic collection and labeling method based on a middleman proxy to solve the technical problems that the existing traffic collection and labeling methods cannot provide specific parameter information of encrypted API traffic or the information is incomplete, resulting in inaccurate encrypted traffic labeling and a small scope of application.
[0007] In order to achieve the above object, the present invention adopts the following technical solutions:
[0008] A method for collecting and labeling API encrypted traffic based on a middleman proxy, in which the following steps are performed in a system including a cloud server and an application terminal equipped with a middleman proxy client:
[0009] The middleman proxy client detects and intercepts network access requests (using real user parameters) sent by the application terminal's application to the application server (such as a web server), parses the network access requests to generate corresponding API interface documents, which contain network request links and request parameters for different APIs of the target application server; the middleman proxy client generates simulated network access requests within its variable parameter range based on the real traffic information of the application terminal, simulates the application program to establish a connection and communicate with the application server, sends the content returned by the application server to the corresponding application program, and simultaneously records and stores communication log files and API interface documents, and uploads the communication log files and API interface documents to the cloud server;
[0010] The cloud server generates corresponding script code for each API interface document, randomly selects parameters from the interface parameter dictionary and replaces the parameters of each API interface document, generates a simulated network access request and sends it to the application server, that is, the cloud server generates the communication traffic of the corresponding API according to the API interface document and the parameter dictionary; when sending the simulated network access request to the application server, the cloud server collects the encrypted communication traffic and communication private key generated by the same API interface, and generates a traffic log file for traffic marking when collecting the encrypted communication traffic, and records the collected communication private key for decrypting the encrypted communication traffic.
[0011] Furthermore, the request parameters in the API interface document include: the encryption algorithm and key information used for each handshake.
[0012] Furthermore, the application program of the application terminal includes user preference settings and cookie cache (data stored on the user's local terminal in order to identify the user and track the session), and can access different web applications.
[0013] Furthermore, the middleman proxy client parses the network access request and generates and stores the corresponding API interface document, specifically including:
[0014] Filter and screen the traffic protocol types in network access requests, retaining http and https protocol traffic;
[0015] Parse the network data packet of the network access request according to the corresponding protocol format, extract the URL link and parameter fields, and store them in the XML file format.
[0016] Furthermore, the middleman proxy client obtains the process corresponding to the current application by reading the process ID (PID) in the operating system of the application terminal, and obtains the traffic corresponding to the current application through the process source port number. In other words, the present invention maps the PID to a specific system application through the package management application program interface of the operating system, and obtains the mapping relationship between the traffic and the application. In other words, the annotation method is a fine-grained correspondence from application, process, source port to API traffic.
[0017] Furthermore, the middleman proxy client includes an API request location interception module, an API request forwarding module, and an API request parameter recording module;
[0018] Among them, the API request location interception module is used to detect and intercept the network access request sent by the application to the application page server, parse the network access request to generate the corresponding API interface document;
[0019] The API request forwarding module is used to generate simulated network access requests, simulate the application program to establish a connection and communicate with the application server, and send the content returned by the web server to the corresponding application program;
[0020] The API request parameter recording module is used to record communication log files and API interface documents.
[0021] Furthermore, the cloud server is deployed at a physical network location that can establish a stable connection with the application server, and includes a packet sender and a traffic collector;
[0022] The packet sender is used to generate corresponding script code for each API interface document, randomly select parameters from the interface parameter dictionary and replace the parameters of each API interface document, generate a simulated network access request and send it to the application server;
[0023] The traffic collector monitors and collects the encrypted communication traffic and communication private key generated by the same API interface based on the preset traffic capture tool (such as tcpdump).
[0024] Furthermore, the packet sender of the cloud server generates a simulated network access request and sends it to the application server specifically as follows:
[0025] Generate the corresponding API communication traffic based on the API interface document and preset parameter dictionary
[0026] Parse the API interface document, read the URL link and request parameters, load the parameter dictionary on the cloud server, replace the relevant request parameters, generate the corresponding Python code, execute the Python code to generate a simulated network access request and send it to the application server.
[0027] Furthermore, the traffic collector stores the collected encrypted communication traffic according to the specified encrypted communication traffic.
[0028] Furthermore, the traffic storage format is a format in which an API request of a web application corresponds to a traffic pcap record.
[0029] Furthermore, the traffic collector annotates the collected encrypted communication traffic based on the API log files uploaded by the middleman proxy client by comparing URL links. Since only the parameters are modified and the links are unchanged, only the URL links are compared.
[0030] The technical solution provided by the present invention brings at least the following beneficial effects:
[0031] (1) The present invention can collect a complete and decryptable traffic data set of API request plaintext. Through the middleman proxy method, the private key for encrypted communication between the application terminal (user end) and the application server end can be obtained. The private key refers to the private key of the user end, which can be used to decrypt the server's response message. The middleman proxy client monitors and intercepts the plaintext messages from the application. When both plaintext and encrypted messages are mastered, it is more conducive to network traffic security research.
[0032] (2) The present invention can customize and simulate API requests with different parameters. An API interface document can be generated for the user-side application and the server, which contains different API interface documents of the server, including the interface address and request parameters. Then, by continuously changing the request parameters, the encrypted traffic of the same interface under different devices and network environments is simulated. The encrypted traffic is then captured using a traffic collection tool, where the parameter changes are determined by a pre-stored parameter dictionary. BRIEF DESCRIPTION OF THE DRAWINGS
[0033] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.
[0034] Figure 1 This is a structural diagram of the API encrypted traffic collection and annotation system based on the middleman proxy provided by the present invention;
[0035] Figure 2 A flowchart of the method for collecting and labeling API encrypted traffic based on a middleman proxy provided by the present invention;
[0036] Figure 3 This is a functional structure diagram of the intermediary proxy client certificate replacement and acquisition, forwarding, and recording requests provided by the present invention.
[0037] The reference numerals are as follows:
[0038] 1——PC computer, 2——middleman proxy client, 3——cloud server, 4——traffic collector, 5——browser, 6——packet sender. DETAILED DESCRIPTION
[0039] To make the objectives, technical solutions and advantages of the present invention more clear, the embodiments of the present invention will be described in further detail below with reference to the accompanying drawings.
[0040] The present invention discloses a method for collecting and labeling API encrypted traffic based on a middleman proxy. This method uses a middleman proxy client to detect all network access requests from applications on an application terminal (e.g., a PC), parses the targeted http / https traffic, extracts URLs, parameters, and other information, and forms an API interface document. Mapping between the target application process, the target application process ID (PID), and the API traffic source port is used to match the TLS (Transport Layer Security) encrypted network flow with the specific application, thereby labeling the API encrypted traffic and generating a corresponding log document. Based on a client-server model, the present invention improves the efficiency and scalability of traffic collection and labeling, achieving a distributed architecture and collecting application API encrypted traffic and corresponding keys, enabling the acquisition of application and API-level traffic classification labels based on traffic collection. The present invention can automatically simulate multiple user API request parameters and generate and collect API request traffic in a targeted manner. Furthermore, the storage of encrypted traffic keys facilitates the exploration of factors influencing encrypted traffic, an area currently under investigation in the field of encrypted traffic analysis.
[0041] like Figure 1 As shown, an embodiment of the present invention provides a method for collecting and labeling encrypted API traffic based on a middleman proxy. In a system comprising a cloud server and a PC with a middleman proxy client installed, the PC is installed with various applications (e.g., a browser) and a forged certificate replaced by the middleman proxy client. The middleman client implements its functions through session acquisition and certificate replacement. Session acquisition simulates the application software establishing a connection and communication with a remote web server, while also simulating the web server forwarding messages to the PC. The middleman proxy client simultaneously holds the session keys and certificates of the PC (middleman proxy client) and the session keys and certificates of the middleman proxy client (middleman proxy client) with the web server. It can decrypt and analyze the encrypted traffic between both parties and extract the URLs and parameters of the HTTP / HTTPS traffic of interest to form an API interface document. The middleman proxy client is designed to deceive the PC and web server into establishing a connection using two sets of protocol certificates. If the signatures do not match or are from an untrusted party, the third-party security client will simply disconnect and refuse to proceed.
[0042] Therefore, certificate replacement can be used to address the aforementioned issues. This requires manually generating a complete certificate. To ensure that the PC trusts the intermediary proxy server, the generated certificate must be added to the trusted root certificate list. This certificate (used for TLS authentication) is the identity verification mechanism used in the encrypted TLS protocol used by HTTPS. It is a digitally signed file containing the certificate owner's public key and third-party certificate information. Certificates are divided into two categories: self-signed certificates and CA certificates. Generally, self-signed certificates cannot be used for identity authentication. During the TLS key negotiation process, CA-certificate-based identity authentication between the application client and application server works as follows: First, the application client must trust the application server's CA certificate (for example, if the certificate is in the operating system's trusted certificate list, or if the user has added the CA's public and private keys to the trusted list using methods such as "Install Root Certificate"). The CA then signs the application server's original certificate (encrypting it with its private key) to generate the final certificate. After receiving the final certificate, the application client decrypts it using the public key contained in the certificate to obtain the application server's original certificate. Taking RSA encryption as an example, if decryption is successful using the CA's public key, it means that the certificate was indeed encrypted using the CA's private key, and the application server can be considered trustworthy.
[0043] In addition, the present invention is organized in a distributed client-cloud server manner, monitoring the network traffic of PC device applications, parsing the http / https traffic of interest, extracting the API interface documents, and uploading them to the server for traffic replay, thereby achieving the purpose of obtaining traffic classification label data at the application and API interface granularity level based on traffic collection.
[0044] As a possible implementation method, an embodiment of the present invention provides a method for collecting and annotating API encrypted traffic based on a middleman proxy. In a system including a PC 1 and a cloud server 3, the PC is installed with a browser 5 and a middleman proxy client 2; the browser 5 includes user preference settings and cookie cache, and can access different web applications; the middleman proxy client 2 includes an API request location interception module, an API request forwarding module, and an API request parameter recording module (i.e., Figure 3 API request parameter recording device), such as Figure 3As shown, the request sent by the browser to the web server is intercepted by the API request positioning interception module (the detected network request uses the parameters of the real user), and then the API request forwarding module simulates the browser to communicate with the web server, and sends the content returned by the web server to the browser, while the API request parameter recording device records the request parameters. The middleman proxy client 2 replaces the middleman CA certificate on the PC computer 1 end, and the middleman proxy client 2 API request positioning interception module intercepts all network requests for the browser installed on the PC computer 1 to access the web application. The API request forwarding module replaces the PC computer 1 to communicate with the web server and forwards the network access request of the PC computer 1. The API request parameter recording device records the encryption algorithm and key information used for each handshake for decryption and acquisition, thereby obtaining the complete application request data and request parameters on the middleman proxy client 2; the cloud server 3 is deployed at a physical network location (such as a physical network location) that can establish a stable connection with the web server. Figure 3 As shown), the cloud server 3 includes a packet sender 6 and a traffic collector 4, wherein the packet sender 6 generates simulated user traffic based on the real user request data, parameter dictionary, and time delay recorded by the middleman proxy client 2; the traffic collector 4 uses a traffic capture tool such as tcpdump to collect the traffic generated by the packet sender 6, and at the same time generates a log file to facilitate the annotation of the collected traffic. When collecting the network requests generated by the packet sender 6, the session key is recorded to facilitate the subsequent decryption analysis of the encrypted traffic.
[0045] In an embodiment of the present invention, an API encrypted traffic collection and labeling method based on a middleman proxy is provided. On the one hand, a middleman proxy client 2 is used to detect all network access requests of user applications, parse the http and https traffic of interest, extract the URL link and parameters of the network access request, and generate a corresponding interface document so that some parameters such as User-Agent can be adjusted, which can simulate the traffic generated by different network devices in different network environments; the middleman proxy client 2 will generate a log file while detecting http / https traffic. The log file records the application name and the URL link of the application request, and the format is such as ("Application 1": {"https: / / request1.com"}, "Application 2": {"https: / / request2.com", "https: / / request3.com"}), so that the application can be quickly labeled in subsequent traffic collection; the client-server design framework greatly improves the efficiency of traffic collection and labeling, by extracting API interface documents and log files from a small amount of application traffic on PC computer 1, and then using cloud server 3 to simulate the generated traffic.
[0046] As a possible implementation, Figure 2 As shown, the specific implementation steps of a method for collecting and labeling API encrypted traffic based on a middleman proxy provided by an embodiment of the present invention include:
[0047] Step S1: using a middleman proxy client 2 to monitor network access requests of applications installed in a PC 1 .
[0048] In order to collect pure application API traffic, the application traffic needs to be proxy forwarded, that is, all traffic of the target application process is proxied to the designated port, and the middleman proxy client 2 listens to the port in real time to parse and forward the traffic.
[0049] The application traffic proxy forwarding method varies depending on the application type. It is relatively simple for common web applications because browsers basically implement the http / https traffic proxy function, which can proxy all browser traffic to the specified IP and port. The proxy plug-in is used to build a routing table to complete the API request forwarding function. By configuring rules, different web application traffic can be forwarded to different ports, which is obviously more conducive to traffic collection and labeling.
[0050] For general user applications and system applications, you can use the traffic proxy tool to configure the corresponding rules to forward the target application's traffic to the listening port of the middleman proxy client 2.
[0051] In order for the middleman proxy client 2 to obtain the session between the target application and the target application server, the target application needs to trust and use the middleman proxy client's certificate. In this way, the middleman proxy client can obtain the session key between the target application and the middleman proxy client 2 and the session key between the middleman proxy client 2 and the target application server (web server), thereby enabling the decryption of encrypted traffic.
[0052] Step S2: The middleman proxy client 2 exports and stores the API interface document generated by parsing the network access request and the log information saved by comparing the PID.
[0053] The middleman proxy client 2 will parse the format of all network request data packets of the application according to the TCP / IP protocol stack format. It will first determine the protocol type of the data packet. Since this embodiment mainly collects http / https traffic, it will ignore traffic of other protocol types. For http / https protocol data packets, the middleman proxy client 2 will determine whether the data packet is encrypted using the TLS / SSL encryption suite. If the data packet is not encrypted, it will parse the application layer of the data packet according to the http protocol format to obtain the required URL link, request method, request header fields, etc. If the data packet is encrypted using an encryption algorithm, since the middleman proxy client 2 obtains the communication key through certificate replacement and session acquisition methods, the middleman proxy client 2 can use the communication key to decrypt the encrypted application layer payload, and then decrypt the decrypted application layer plaintext data in the same processing method as http.
[0054] The middleman proxy client 2 parses the http / https data packet to obtain the URL link, request header field and other contents to form the corresponding API interface document, which is stored in the format of {API request url connection, parameter form, traffic network delay}. The record contains all the information of the data packet request. The packet sender randomly changes the parameter form and traffic network delay based on the record format to achieve the ability to generate API requests. The parameter form includes the request method, request header and request data. The request method includes various http protocol request methods such as GET, POST, HEAD, etc. The request header contains the various header field information of the request line such as Cookie, User-Agent, Host, etc. The request data contains some important data that needs to be encrypted and transmitted using the POST method.
[0055] The middleman proxy client 2 generates a specific log file by comparing the mapping relationship between the application process PID and the source port of the data packet. For example, it uses the "netstat -aon|findstr'source port'" command to monitor the port occupied by the network connection, and uses the "tasklist|findstr'PID'" command to monitor the port status owned by the process, thereby forming a one-to-one mapping relationship between the API interface traffic data packet and the application process PID (the mapping relationship is only stored locally on PC 1), thereby realizing the ability to accurately collect traffic.
[0056] Step S3: The middleman proxy client 2 uploads the saved API interface document and log file to the cloud server 3.
[0057] The middleman client 2 will write the relationship between the API interface and the application obtained in real time into a log file in the form of "application name-flow five-tuple (source address, destination address, source port, destination port, protocol type) list-API interface information", and will upload it to the cloud server 3 at the same time as the API interface document generated during the period.
[0058] Step S4: The cloud server 3 receives multiple API interface documents sent by the middleman proxy client 2, stores all API records and integrates the parameter form and network delay in the records to obtain the parameter dictionary and network delay variation range. For each API interface document, it can generate corresponding Python script code, and based on the parameter dictionary and delay variation range combined with the stored API records, generate a new API request, execute the Python code to send the corresponding network request, and then use tcpdump to capture the communication encryption traffic and communication private key generated by the same interface.
[0059] That is, in step S4, the cloud server 3 receives API interface documents and log files sent from multiple middleman proxy clients 2. The packet sender 6 on the cloud server 3 uses the information provided by the API interface document to generate Python script code. Because the API interface document contains all the necessary information for network requests, the postman tool can be used to automatically generate the Python packet sending script. The packet sender 6 then loads the parameter dictionary library and the time delay factor library, continuously replaces the relevant parameter information of the corresponding API, and then executes the Python script to send different data packets. The parameter dictionary mainly contains the GET parameters in the API URL link, the User-Agent and other related fields in the http / https header, which are used to simulate different users and different devices initiating network requests in different environments. The TLS / SSL certificate used by the Python script of the packet sender 6 is controllable. The present invention replaces it so that the present invention can decrypt the encrypted traffic collected by the traffic collector, which helps to realize the analysis of encrypted traffic. The traffic collector 4 of the cloud server 3 is mainly implemented using tcpdump, which is used to collect network requests issued by the python script, generate the original traffic file (Pcap file), and then compare it with the log document corresponding to the API interface document, and statistically generate the corresponding API interface communication traffic of the target application. At the same time, it obtains the private key in the certificate used by the packet sender 6. Different API interface documents of the same application are stored in the same folder, which contains the pcap files collected by different API interface traffic and the private keys corresponding to the pcap files.
[0060] By analyzing the encrypted traffic of API interfaces that are unique to a certain type of application, we can further explore some traffic characteristics and behavior patterns of such applications. In particular, we can decrypt and analyze the collected encrypted traffic. This can not only analyze the influencing factors of the encrypted traffic, but also explore potential user behavior pattern characteristics, which helps to determine whether a certain type of application has behaviors that leak user privacy.
[0061] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, rather than to limit it. Although the present invention has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present invention.
[0062] The above are only some embodiments of the present invention. For those skilled in the art, several modifications and improvements can be made without departing from the inventive concept of the present invention, which all fall within the scope of protection of the present invention.
Claims
1. A method for collecting and labeling API encrypted traffic based on a middleman proxy, characterized in that: In a system including a cloud server and an application terminal provided with an intermediate proxy client, the following steps are performed: The middleman proxy client detects and intercepts network access requests sent by the application terminal application to the application server, parses the network access requests and generates corresponding API interface documents, which contain network request links and request parameters for different APIs of the application server; The middleman proxy client generates simulated network access requests within its variable parameter range based on the actual traffic information of the application terminal, simulates the application to establish a connection and communicate with the application server, sends the content returned by the application server to the corresponding application, and simultaneously records and stores the communication log file and API interface document, and uploads the communication log file and API interface document to the cloud server; the communication log file records the application name and the URL link requested by the application; The cloud server generates corresponding script code for each API interface document, randomly selects parameters from the interface parameter dictionary and replaces the parameters of each API interface document, generates a simulated network access request and sends it to the application server. When sending the simulated network access request to the application server, the cloud server collects the encrypted communication traffic and communication private key generated by the same API interface, and generates a traffic log file for traffic marking when collecting the encrypted communication traffic, and records the collected communication private key for decrypting the encrypted communication traffic.
2. The method according to claim 1, wherein The request parameters in the API interface document include: the encryption algorithm and key information used for each handshake.
3. The method according to claim 1, wherein The application on the application terminal contains user preferences and cookie cache, and can access different web applications.
4. The method according to claim 1, wherein The middleman proxy client parses the network access request and generates and stores the corresponding API interface document, specifically including: Filter and screen the traffic protocol types in network access requests, retaining http and https protocol traffic; Parse the network data packet of the network access request according to the corresponding protocol format, extract the URL link and parameter fields, and store them in the XML file format.
5. The method according to claim 1, wherein The middleman proxy client obtains the process corresponding to the current application by reading the process ID in the operating system of the application terminal, and obtains the traffic corresponding to the current application through the process source port number, that is, the process ID is mapped to a specific system application through the package management application interface of the operating system to obtain the mapping relationship between the traffic and the application.
6. The method according to claim 1, wherein The middleman proxy client includes an API request location interception module, an API request forwarding module and an API request parameter recording module; Among them, the API request location interception module is used to detect and intercept the network access request sent by the application to the application server, parse the network access request to generate the corresponding API interface document; The API request forwarding module is used to generate simulated network access requests, simulate the application program to establish a connection and communicate with the application server, and send the content returned by the application server to the corresponding application program; The API request parameter recording module is used to record communication log files and API interface documents.
7. The method according to claim 1, wherein The cloud server is deployed at a physical network location that can establish a stable connection with the application server, and includes a packet sender and a traffic collector; The packet sender is used to generate corresponding script code for each API interface document, randomly select parameters from the interface parameter dictionary and replace the parameters of each API interface document, generate a simulated network access request and send it to the application server; The traffic collector monitors and collects the encrypted communication traffic and communication private keys generated by the same API interface based on the preset traffic capture tool.
8. The method according to claim 7, wherein The packet sender of the cloud server generates a simulated network access request and sends it to the application server as follows: Generate the corresponding API communication traffic based on the API interface document and preset parameter dictionary Parse the API interface document, read the URL link and request parameters, load the parameter dictionary on the cloud server, replace the relevant request parameters, generate the corresponding Python code, execute the Python code to generate a simulated network access request and send it to the application server.
9. The method according to claim 7, wherein: The storage format of the collected encrypted communication traffic by the traffic collector is: a format corresponding to an API request of a web application and a traffic pcap record.