Security testing method, device, computer equipment and computer readable storage medium

By using random numbers to update the cipher suite in the encrypted communication library in the security test method, multiple greeting packets are generated, the problem of incomplete test samples in the existing security test method is solved, and concurrent testing of verification fingerprints of multiple clients is realized, improving the accuracy of the test results.

CN119324834BActive Publication Date: 2025-04-22CHINA TELECOM CLOUD TECH CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202411859344.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2024-12-17
Publication Date
2025-04-22
Estimated Expiration
2044-12-17

AI Technical Summary

Technical Problem

The existing security testing methods can only be tested based on the JA3 fingerprint of one client, resulting in incomplete test samples and low accuracy of test results.

Method used

By updating the cipher suite in the encrypted communication library based on random numbers, multiple different greeting data packets are generated, thereby simulated generating verification fingerprints for each client, and batch sending the test request set corresponding to these verification fingerprints to the server to enrich the test samples and improve the accuracy of the test results.

Benefits of technology

Through the random number update password suite, multiple greeting data packets are generated, and verification fingerprints of multiple clients are simulated. Concurrent testing of verification fingerprints of multiple clients is realized, which enriches the test samples and improves the accuracy of test results.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119324834B_ABST
    Figure CN119324834B_ABST
Patent Text Reader

Abstract

The present application relates to a security testing method, device, computer equipment and computer-readable storage medium. The method includes: updating the cryptographic suite in the encryption communication library based on a random number to obtain an updated cryptographic suite; generating a greeting data packet according to the updated cryptographic suite until the number of cycles of updating the cryptographic suite reaches a preset cycle number threshold, and obtaining each greeting data packet; sending each greeting data packet to a server, instructing the server to batch generate each verification fingerprint according to each greeting data packet; and determining the test result of the server based on the test request set corresponding to each verification fingerprint. The use of this method can improve the accuracy of the security testing method.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This application relates to the field of communication technology, and in particular to a security testing method, apparatus, computer equipment, and computer-readable storage medium. Background Technology

[0002] Data transmission between the client and server is conducted via the QUIC (Quick UDP Internet Connections, UDP stands for User Datagram Protocol) protocol. The server receives requests from the client and intercepts them by matching them against a blacklist based on the JA3 fingerprint (Just Another SSL / TLS Fingerprint, SSL / TLS stands for Secure Sockets Layer / Transport Layer Security). However, before executing data transmission, the JA3 fingerprint's protection capabilities must be tested using security testing methods to ensure server security.

[0003] Current security testing methods involve the client sending a Client Hello data packet to the server. The server receives the client Hello data packet and hashes it using a fingerprint algorithm to obtain a JA3 fingerprint. This JA3 fingerprint serves as the test sample. The client then uses this test sample to test the server's security and obtains the test results.

[0004] However, current security testing methods only use one client for testing, and one client can only generate one JA3 fingerprint. This means that the client can only test the server's security based on one test sample, resulting in incomplete test samples. Consequently, this leads to lower accuracy of the test results. Summary of the Invention

[0005] Therefore, it is necessary to provide a security testing method, apparatus, computer equipment, and computer-readable storage medium to address the aforementioned technical problems.

[0006] Firstly, this application provides a security testing method, including:

[0007] The cipher suite in the encrypted communication library is updated based on random numbers to obtain the updated cipher suite;

[0008] Greeting data packets are generated based on the updated cipher suite until the number of cycles for updating the cipher suite reaches a preset cycle number threshold, thus obtaining each greeting data packet;

[0009] Each of the greeting data packets is sent to the server, which is then instructed to generate each verification fingerprint in batches based on the greeting data packets.

[0010] The test results of the server are determined based on the test request set corresponding to each of the verification fingerprints.

[0011] In one embodiment, updating the cipher suite in the encrypted communication library based on random numbers to obtain the updated cipher suite includes:

[0012] The encrypted communication library is invoked through a request middleware, and random numbers are generated based on a preset random number range.

[0013] A cipher suite is determined in the encrypted communication library, and the random number is added at the target location of the cipher suite to obtain an updated cipher suite.

[0014] In one embodiment, the step of generating greeting data packets based on the updated cipher suite until the number of loops for updating the cipher suite reaches a preset loop count threshold, and obtaining each greeting data packet, includes:

[0015] Generate a greeting data packet based on the updated cipher suite, transport layer security version, extension, elliptic curve, and elliptic curve dot format;

[0016] Update the loop count of the cipher suite and determine whether the updated loop count reaches a preset loop count threshold;

[0017] If the updated number of cycles does not reach the cycle count threshold, the step of updating the cipher suite in the encrypted communication library based on random numbers is executed until the updated number of cycles reaches the cycle count threshold, and each greeting data packet is obtained.

[0018] In one embodiment, before sending each of the greeting data packets to the server, the method further includes:

[0019] Determine whether there is a duplicate target cipher suite in each of the aforementioned greeting data packets;

[0020] If a duplicate target cipher suite exists, delete the greeting data packet containing the duplicate target cipher suite;

[0021] Adjust the range of the random numbers, and generate new random numbers based on the adjusted range;

[0022] The cipher suite is updated based on the new random number, and a new greeting data packet is generated based on the updated cipher suite.

[0023] In one embodiment, determining the server's test results based on the test request set corresponding to each of the verification fingerprints includes:

[0024] The test request set corresponding to each verification fingerprint is sent in batches to the server; the test request set is used to test whether the protection function of the verification fingerprint is normal, and a protection result set is obtained.

[0025] Receive the protection result set of each of the test request sets, and determine the test result of the server based on each of the protection result sets.

[0026] In one embodiment, determining the test results of the server based on each of the protection result sets includes:

[0027] The initial test result of the verification fingerprint is determined based on the number of protection results in each protection result set.

[0028] If the initial test result is not a failure, the server-side test result is determined to be a success, and the server-side security is determined to meet the standards.

[0029] If an initial test result indicates that the test failed, the verification fingerprint corresponding to the initial test result is determined as the issue verification fingerprint, and the test result of the server is constructed based on the server's security failure and the issue verification fingerprint.

[0030] In one embodiment, determining the initial test result of the verification fingerprint based on the number of protection results in each protection result set includes:

[0031] For each set of test requests corresponding to a set of protection results, determine whether the number of protection results in the set of protection results is equal to the number of normal requests in the set of normal test requests.

[0032] If the number of results is equal to the number of normal requests, the initial test result of the verification fingerprint is determined to be a successful test.

[0033] If the number of results is not equal to the number of normal requests, the initial test result of the verification fingerprint is determined to be a test failure.

[0034] Secondly, this application also provides a security testing device, comprising:

[0035] The update module is used to update the cipher suites in the encrypted communication library based on random numbers, thereby obtaining the updated cipher suites.

[0036] The generation module is used to generate greeting data packets based on the updated cipher suite until the number of cycles for updating the cipher suite reaches a preset cycle number threshold, thereby obtaining each greeting data packet;

[0037] The sending module is used to send each of the greeting data packets to the server, and instruct the server to generate each verification fingerprint in batches according to each of the greeting data packets;

[0038] The determination module is used to determine the test results of the server based on the test request set corresponding to each of the verification fingerprints.

[0039] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0040] The cipher suite in the encrypted communication library is updated based on random numbers to obtain the updated cipher suite;

[0041] Greeting data packets are generated based on the updated cipher suite until the number of cycles for updating the cipher suite reaches a preset cycle number threshold, thus obtaining each greeting data packet;

[0042] Each of the greeting data packets is sent to the server, which is then instructed to generate each verification fingerprint in batches based on the greeting data packets.

[0043] The test results of the server are determined based on the test request set corresponding to each of the verification fingerprints.

[0044] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0045] The cipher suite in the encrypted communication library is updated based on random numbers to obtain the updated cipher suite;

[0046] Greeting data packets are generated based on the updated cipher suite until the number of cycles for updating the cipher suite reaches a preset cycle number threshold, thus obtaining each greeting data packet;

[0047] Each of the greeting data packets is sent to the server, which is then instructed to generate each verification fingerprint in batches based on the greeting data packets.

[0048] The test results of the server are determined based on the test request set corresponding to each of the verification fingerprints.

[0049] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0050] The cipher suite in the encrypted communication library is updated based on random numbers to obtain the updated cipher suite;

[0051] Greeting data packets are generated based on the updated cipher suite until the number of cycles for updating the cipher suite reaches a preset cycle number threshold, thus obtaining each greeting data packet;

[0052] Each of the greeting data packets is sent to the server, which is then instructed to generate each verification fingerprint in batches based on the greeting data packets.

[0053] The test results of the server are determined based on the test request set corresponding to each of the verification fingerprints.

[0054] The aforementioned security testing method, apparatus, computer equipment, and computer-readable storage medium update the cipher suites in the encrypted communication library based on random numbers to obtain updated cipher suites; generate greeting data packets based on the updated cipher suites until the number of iterations for updating the cipher suites reaches a preset threshold, resulting in various greeting data packets; send each greeting data packet to the server, instructing the server to generate verification fingerprints in batches based on each greeting data packet; and determine the server's test results based on the test request sets corresponding to each verification fingerprint. Using this method, different greeting data packets can be generated by updating the cipher suites with random numbers, thereby simulating the generation of verification fingerprints for each client. Then, by sending the test request sets corresponding to each verification fingerprint to the server, the verification fingerprints of multiple clients can be tested simultaneously, enriching the test sample and improving the accuracy of the test results. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 This is a diagram illustrating the application environment of a security testing method in one embodiment;

[0057] Figure 2 This is a flowchart illustrating a security testing method in one embodiment;

[0058] Figure 3 This is a schematic diagram of the process for updating a cipher suite in one embodiment;

[0059] Figure 4 This is a schematic diagram of the process for generating a greeting data packet in one embodiment;

[0060] Figure 5 This is a flowchart illustrating the process of determining whether greeting data packets are duplicated in one embodiment;

[0061] Figure 6 This is a flowchart illustrating the process of determining test results in one embodiment;

[0062] Figure 7 This is a flowchart illustrating the process of determining test results in another embodiment;

[0063] Figure 8 This is a flowchart illustrating the process of determining the initial test results in one embodiment;

[0064] Figure 9 A flowchart illustrating the sending of a greeting data packet in an exemplary embodiment;

[0065] Figure 10 This is a structural block diagram of a safety testing device in one embodiment;

[0066] Figure 11 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0067] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0068] The security testing method provided in this application embodiment can be applied to, for example... Figure 1 The security testing system 100 shown includes a client 110 and a server 120. The client 110 communicates with the server 120 via a network. The client 110 can be, but is not limited to, various personal computers, laptops, smartphones, tablets, IoT devices, and portable wearable devices. IoT devices can be smart speakers, smart TVs, smart air conditioners, smart in-vehicle devices, projection devices, etc. Portable wearable devices can be smartwatches, smart bracelets, head-mounted devices, etc. Head-mounted devices can be virtual reality (VR) devices, augmented reality (AR) devices, smart glasses, etc. The server 120 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing cloud computing services.

[0069] In one exemplary embodiment, such as Figure 2 As shown, a security testing method is provided, which is applied to Figure 1 Taking client 110 (hereinafter referred to as the client) as an example, the explanation includes the following steps 202 to 208. Wherein:

[0070] Step 202: Update the cipher suite in the encrypted communication library based on the random number to obtain the updated cipher suite.

[0071] A cipher suite is a combination of encryption protocols and algorithms used to protect the security of network communications. It is used in TLS (Transport Layer Security) or SSL (Secure Sockets Layer) to ensure the confidentiality, integrity, and authentication of data transmitted between clients and servers.

[0072] In practice, the client generates a random number based on a random number range and updates the cipher suite in the encrypted communication library based on the random number to obtain the updated cipher suite.

[0073] Specifically, the client invokes the encrypted communication library through the message middleware and determines the cipher suite within the encrypted communication library. Then, the client generates a random number and adds the random number to the cipher suite to obtain the updated cipher suite.

[0074] Step 204: Generate greeting data packets based on the updated cipher suite until the number of cycles for updating the cipher suite reaches a preset cycle number threshold, and obtain each greeting data packet.

[0075] The greeting data packet is the Client Hello data packet, which is used to establish secure communication based on TLS / SSL.

[0076] In implementation, the client pre-sets the number of cycles for the cipher suite and a cycle count threshold. The client generates a greeting data packet based on the updated cipher suite and updates the cycle count. Then, the client determines whether the updated cycle count reaches the preset cycle count threshold. If the updated cycle count reaches the threshold, the client receives the greeting data packets.

[0077] In an optional embodiment, if the updated loop count does not reach the loop count threshold, the client executes step 202 above until the updated loop count reaches the loop count threshold, at which point the client receives each greeting data packet.

[0078] Optionally, the loop count threshold can be set to, but is not limited to, 5, depending on the testing requirements. This application embodiment does not limit the loop count threshold.

[0079] Step 206: Send each greeting data packet to the server, instructing the server to generate each verification fingerprint in batches based on each greeting data packet.

[0080] The verification fingerprint is a JA3 fingerprint.

[0081] In implementation, the client sends all greeting data packets together to the server, instructing the server to generate verification fingerprints in batches based on each greeting data packet. The server receives each greeting data packet and groups them into greeting data groups. Then, the server generates a verification fingerprint group corresponding to each greeting data group according to a preset fingerprint algorithm. The client initiates a QUIC request or an HTTPS (Hypertext Transfer Protocol Secure) request to the server, thereby establishing a secure connection between the client and the server.

[0082] Specifically, the client and server connect via a network. The client sends greeting data packets to the server via the network connection, instructing the server to generate JA3 fingerprints in batches. The server receives the greeting data packets via the network connection. Then, the server divides the greeting data packets into greeting data packet groups according to a preset number of groups. The server then hashes the values ​​of each field in each greeting data packet group to obtain the verification fingerprint group.

[0083] In one exemplary embodiment, the server pre-sets a number of groups. This number is 3. The server receives 12 greeting data packets. The server divides each greeting data packet into 4 greeting data packet groups according to preset components. Each greeting data packet contains an updated cipher suite, a Transport Layer Security (TLS) version, an extension, elliptic curves (Supported_Groups), and elliptic curve point formats (ec_point_formats, where ec_point_formats represents elliptic curve point format). Multiple processing processes exist on the server. The server simultaneously distributes 3 greeting data packets from one greeting data packet group to 3 processing processes, enabling one processing process to generate JA3 fingerprints based on the greeting data packets; that is, the server can generate verification fingerprints in batches. Specifically, each processing process on the server formats the greeting data packets and concatenates the updated cipher suite, TLS version, extension, elliptic curves, and elliptic curve format from the greeting data packets according to a preset field order to obtain a concatenated string. The fields are ordered as follows: Transport Layer Security Version, Updated Cipher Suite, Elliptic Curve, Elliptic Curve Format, and Extension. Then, the processing step calculates the MD5 (Message Digest Algorithm 5) hash value on the concatenated string to obtain the JA3 fingerprint.

[0084] Step 208: Determine the test results on the server side based on the test request set corresponding to each verification fingerprint.

[0085] In implementation, the client sends test request sets corresponding to each verification fingerprint to the server and determines the server's test results based on each test request set. The test results characterize the server's security. If the test result is "pass," the server's security meets the standards. If the test result is "fail," the server's security does not meet the standards.

[0086] Specifically, to expedite the testing process, the client sends batch test request sets corresponding to each verification fingerprint to the server and receives protection result sets corresponding to each test request set. Then, the client determines the server's test results based on each protection result set.

[0087] In the aforementioned security testing method, updating the cipher suite with random numbers generates different greeting data packets, thereby simulating the generation of verification fingerprints for each client. Then, by sending the test request set corresponding to each verification fingerprint to the server, the verification fingerprints of multiple clients can be tested simultaneously, enriching the test sample and improving the accuracy of the test results.

[0088] In one exemplary embodiment, such as Figure 3 As shown, the specific processing steps of step 202 include steps 302 to 304. Wherein:

[0089] Step 302: Call the encrypted communication library through the request middleware and generate a random number based on a preset random number range.

[0090] In implementation, a random number range is pre-defined in the client. The client establishes a request middleware and calls the encrypted communication library through the request middleware. The client generates random numbers according to the preset random number range.

[0091] Specifically, the client establishes a request middleware using `roundTripper := &http3.RoundTripper`. `roundTripper := &http3.RoundTripper` assigns `http3.RoundTripper` to `roundTripper`. `http3.RoundTripper` is the interface for handling HTTP / 3 (Hypertext Transfer Protocol version 3) requests. HTTP / 3 is a QUIC-based version of HTTP designed to provide faster network connections, better congestion control, and more efficient multiplexing. `roundTripper` is the established message middleware. Then, the client calls the utls encrypted communication library using `roundTripper.TLSClientConfig := &utls.Config`. `roundTripper.TLSClientConfig := &utls.Config` assigns the `Config` from the utls encrypted database to the `TLSClientConfig` method in the `roundTripper` request middleware. The utls library is a library in Go (an open-source programming language) specifically designed for TLS (Transport Layer Security) communication. The utls library is a fork of the crypto / tls library, primarily designed to provide greater flexibility and more functionality. The crypto / tls library is a package in the Go standard library used to implement the Transport Layer Security (TLS) protocol and Secure Sockets Layer (SSL), primarily for secure communication. The client then generates random numbers based on a preset range of random data.

[0092] Optionally, the range of random numbers can be, but is not limited to, natural numbers between [0, 5]. The range of random numbers is set according to the testing requirements, and this embodiment of the application does not limit the range of random numbers.

[0093] Step 304: Determine the cipher suite in the encrypted communication library and add a random number at the target location of the cipher suite to obtain the updated cipher suite.

[0094] The target location is typically at the end of the cipher suite.

[0095] In implementation, the client determines the cipher suite from the encrypted communication library. Then, the client appends a random number to the end of the cipher suite to obtain the updated cipher suite.

[0096] A typical Cipher Suite usually includes the following components:

[0097] Key exchange algorithm: Used to securely exchange session keys between the client and server. Common key exchange algorithms include Elliptic Curve Diffie-Hellman (ECDH), etc.

[0098] Authentication algorithm: Used to verify the identities of both parties in a communication.

[0099] Encryption algorithms: used to encrypt data to ensure the confidentiality of data transmission.

[0100] Message Authentication Code (MAC) or integrity protection algorithm: used to ensure data integrity and prevent data from being tampered with during transmission. Common algorithms include SHA-256, SHA-384, etc.

[0101] In an exemplary embodiment, a typical Cipher Suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, with the following meanings: TLS: Uses the TLS protocol; ECDHE: Uses Elliptic Curve Diffie-Hellman for key exchange; RSA: Uses the RSA algorithm (Rivest-Shamir-Adleman algorithm, an asymmetric encryption algorithm) for authentication; AES_128_GCM: Uses a 128-bit AES (Advanced Encryption Standard, a symmetric encryption algorithm) encryption algorithm in GCM mode (Galois / Counter Mode); SHA256: Uses SHA-256 (a cryptographic hash function used to generate a digital digest (also called a hash value or fingerprint), where SHA stands for "Secure Hash Algorithm" and 256 indicates that the secure hash algorithm generates a 256-bit hash value) for integrity protection. The client-generated random number is 5. The client appends the random number 5 to the end of the cipher suite, resulting in the updated cipher suite. The updated cipher suite is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256_5.

[0102] In an alternative embodiment, the target location can also be the beginning of the cipher suite, where the client adds a random number at the beginning of the cipher suite to obtain the updated cipher suite.

[0103] In this embodiment, the cipher suites of each client are simulated by updating the cipher suites with random numbers, which facilitates the subsequent simulation of generating greeting data packets for each client.

[0104] In one exemplary embodiment, such as Figure 4As shown, the specific processing procedure of step 204 includes steps 402 to 406. Wherein:

[0105] Step 402: Generate a greeting data packet based on the updated cipher suite, transport layer security version, extension, elliptic curve, and elliptic curve point format.

[0106] The greeting packet is the first packet in the TLS / SSL handshake process, sent by the client to the server to initiate a secure connection. The transport layer security version is the highest TLS / SSL version supported by the client. The elliptic curve represents the elliptic curve cryptography algorithm supported by the client. The elliptic curve point format is the representation format of elliptic curve points supported by the client.

[0107] In implementation, the client combines the updated cipher suite, transport layer security version, extensions, elliptic curves, and elliptic curve format to generate a greeting packet to initiate a secure connection between the client and the server.

[0108] Specifically, the client generates a greeting packet based on Handshake Type, Length (total length of the greeting packet), TLS Version, Session ID, Cipher Suites, Compression Methods, Extensions, elliptic curves, and elliptic curve format.

[0109] Step 404: Update the loop count of the cipher suite and determine whether the updated loop count reaches the preset loop count threshold.

[0110] In implementation, the client pre-sets the loop count and a loop count threshold for the cipher suite. The loop count is set to 0. The client adds the current loop count to 1 to obtain the updated loop count. Then, the client checks if the updated loop count is greater than or equal to the loop count threshold. If the updated loop count is less than the loop count threshold, the client determines that the updated loop count has not reached the loop count threshold. If the updated loop count is greater than or equal to the loop count threshold, the client determines that the updated loop count has reached the loop count threshold. A greeting packet represents a scenario where a client establishes a secure connection with the server. Therefore, by generating greeting packets, multiple scenarios of clients establishing secure connections with the server can be simulated.

[0111] In one exemplary embodiment, the current cipher suite has a loop count of 11, and the loop count threshold is 12. The client adds the current loop count of 11 to 1 to obtain an updated loop count of 12. Then, the client determines whether the updated loop count is greater than or equal to the loop count threshold. Since the updated loop count is equal to the loop count threshold, the client determines that the updated loop count has reached the loop count threshold.

[0112] In an optional embodiment, if the updated loop count reaches the loop count threshold, the client stops generating greeting data packets and executes step 206 as described above. The specific processing procedure of step 206 has been described in detail in the above embodiments and will not be repeated here.

[0113] Step 406: If the updated number of cycles does not reach the number of cycles threshold, execute the step of updating the cipher suite in the encrypted communication library based on random numbers until the updated number of cycles reaches the number of cycles threshold and obtain each greeting data packet.

[0114] The threshold for the number of loops is the number of greeting data packets.

[0115] In implementation, if the updated loop count does not reach the loop count threshold, the client determines that a sufficient number of greeting data packets have not yet been generated and executes step 202 above until the updated loop count reaches the loop count threshold, at which point the client obtains the number of greeting data packets corresponding to the loop count threshold. The specific processing procedure of step 202 has been described in detail in the above embodiments and will not be repeated here.

[0116] In one exemplary embodiment, the updated loop count is 10. The loop count threshold is 12. At this point, since the updated loop count of 10 is less than the loop count threshold of 12, the client determines that the updated loop count has not reached the loop count threshold. Then, the client performs step 202 as described above, thereby generating more greeting data packets until the updated loop count reaches the loop count threshold. The client receives 12 greeting data packets.

[0117] In this embodiment, when the number of iterations has not reached the threshold, different updated cipher suites can be used to simulate the generation of greeting data packets from different clients on a single client. This facilitates the subsequent generation of various verification fingerprints, enriching the test samples. Furthermore, by testing the security of the server using these verification fingerprints, the accuracy of the test results is improved.

[0118] In one exemplary embodiment, the greeting data packets need to be checked before being sent to the server to ensure that each greeting data packet is different. Figure 5As shown, before step 206 is executed, the specific processing procedure of this security testing method further includes steps 502 to 508. Wherein:

[0119] Step 502: Determine whether there are duplicate target cipher suites in each greeting data packet.

[0120] The remaining greeting data packets are the greeting data packets in each greeting data packet excluding the current greeting data packet.

[0121] In implementation, for each greeting data packet, the client determines whether the cipher suite in the greeting data packet is the same as the cipher suite in the other greeting data packets. If the cipher suite in the greeting data packet is the same as the cipher suite in the other data packets, the client identifies the duplicate cipher suite as the target cipher suite.

[0122] In one exemplary embodiment, if the range of random numbers is set too small and the number of greeting data packets to be generated is too large, duplicate greeting data packets may occur, meaning that the cipher suites in the greeting data packets may be repeated. To prevent duplicate greeting data packets, the client identifies each greeting data packet in each greeting data packet as the current greeting data packet and determines whether the cipher suite in the current greeting data packet is duplicated with the cipher suites in the other greeting data packets. If the cipher suite in the current greeting data packet is duplicated with the cipher suites in the other greeting data packets, the client identifies the duplicated cipher suite as the target cipher suite.

[0123] In an optional embodiment, if no duplicate target cipher suite is found, the client continues with step 206. The specific processing procedure of step 206 has been described in detail in the above embodiments, and will not be repeated here.

[0124] Step 504: If a duplicate target cipher suite exists, delete the greeting data packet containing the duplicate target cipher suite.

[0125] In practice, if there are duplicate target cipher suites, the client determines that the greeting data packet containing the target cipher suite is the target greeting data packet and deletes the duplicate target greeting data packets, leaving only one target greeting data packet.

[0126] In one exemplary embodiment, if three target cipher suites are duplicated, the client identifies the greeting data packet containing each duplicate target cipher suite as the target greeting data packet. Then, the client deletes two of the three target greeting data packets, leaving one target greeting data packet.

[0127] Step 506: Adjust the range of random numbers and generate new random numbers based on the adjusted range of random numbers.

[0128] The deletion quantity refers to the number of target greeting data packets that were deleted.

[0129] In implementation, the client adjusts the range of random numbers upwards to obtain an adjusted range that is larger than the range of random numbers before adjustment. Then, the client generates new random numbers based on the adjusted range and the number of deletions.

[0130] In one exemplary embodiment, the deletion quantity is 2. The range of the random number is [0, 5]. The client adjusts the range of the random number upwards so that the adjusted range of the random number is [0, 10]. Then, the client generates two new random numbers, 8 and 9, using the adjusted range of the random number.

[0131] Step 508: Update the cipher suite based on the new random number, and generate a new greeting data packet based on the updated cipher suite.

[0132] In implementation, the client invokes the encrypted communication library through the request middleware, determines the cipher suite in the encrypted communication library, and adds a new random number at the target position of the cipher suite to obtain the updated cipher suite. Then, the client generates a new greeting data packet based on the updated cipher suite, transport layer security version, extension, elliptic curve, and elliptic curve point format. The process of generating a new greeting data packet based on the new random number is the same as the process of generating the greeting data packet, and has been described in detail in steps 202 to 204, and will not be repeated here in this embodiment.

[0133] In this embodiment, by detecting whether the cipher suites of each greeting data packet are duplicated, and regenerating a new greeting data packet when a duplicate cipher suite is detected, it is ensured that the greeting data packets are not duplicated, thereby realizing the simulation generation of verification fingerprints for different clients.

[0134] In one exemplary embodiment, such as Figure 6 As shown, the specific processing procedure of step 208 includes steps 602 to 604. Wherein:

[0135] Step 602: Send the test request set corresponding to each verification fingerprint to the server in batches.

[0136] The test request set is used to test whether the fingerprint protection function is working properly, resulting in a protection result set. Each test request set contains normal test requests and abnormal test requests. Abnormal test requests are stored in the blacklist of the protected fingerprint.

[0137] In implementation, the client obtains the test request sets corresponding to each verification fingerprint. The client divides these test request sets into test request set groups. Then, the client sends each test request set group to the server. The server receives each test request group and performs protection processing on the test request set group according to each verification fingerprint group, obtaining the protection result set for each test request set.

[0138] Specifically, the client pre-sets the number of groups. This number is the same as the number of groups set on the server. The client obtains the test request set corresponding to each verification fingerprint, thus obtaining each test request set. The client divides each test request set into a test request group according to the pre-set number of groups and sends each test request group to the server. The server processes the normal test requests in each test request set within the test request group based on the verification fingerprint group, obtaining the protection result set, and intercepts the abnormal test requests in the test request set.

[0139] In one exemplary embodiment, the server is a Web (World Wide Web) application firewall. This Web application firewall is configured with various JA3 fingerprints, each containing a blacklist. The client obtains the test request set corresponding to each JA3 fingerprint, thus obtaining each test request set. The client divides each test request set into test request groups according to a preset number of groups and sends each test request group to the Web application firewall. The Web application firewall intercepts abnormal test requests in each test request set within the test request group based on the blacklist in the JA3 fingerprint, while allowing normal test requests within the test request set, thus obtaining a protection result set for normal test requests. By configuring JA3 fingerprints, it is verified whether the server can accurately intercept requests matching the JA3 fingerprint blacklist and allow other requests not matching the blacklist when accessing via the QUIC protocol with multiple different JA3 fingerprints.

[0140] In one optional embodiment, the server-side DDoS (Distributed Denial of Service) protection is configured. The DDoS protection on the server side configures JA3 fingerprints for each target port, and each JA3 fingerprint contains a blacklist. The client obtains the test request set corresponding to each JA3 fingerprint, thus obtaining each test request set. The client divides each test request set into test request groups according to a preset number of groups and sends each test request set group to the DDoS protection via the target port. The DDoS protection intercepts abnormal test requests in each test request set within the test request set group based on the blacklist in the JA3 fingerprint, while allowing normal test requests in the test request set to proceed, thus obtaining a protection result set for normal test requests. By configuring JA3 fingerprints, it is verified whether the DDoS protection can accurately parse the JA3 fingerprint of the QUIC protocol accessed through the target port, correctly intercept requests matching the JA3 fingerprint blacklist, and not affect QUIC requests not matching the blacklist.

[0141] Step 604: Receive the protection result set of each test request set, and determine the test result of the server based on each protection result set.

[0142] In implementation, the server sends the protection result sets of each test request set to the client. The client receives the protection result sets corresponding to each test request set. Then, the client determines the initial test result for the verification fingerprint for each protection result set, and determines the server's test result based on each initial test result.

[0143] Specifically, the server sends the protection result sets of each test request set to the client via a network connection. The client receives each protection result set. Each protection result set represents the interception result of a verification fingerprint and is also the initial test result of the verification fingerprint. The client determines the initial test result of the verification fingerprint based on the number of protection results in each protection result set. Then, the client determines the server's test result based on each initial test result, thereby determining the server's security.

[0144] In this embodiment, concurrent verification of fingerprints is achieved by sending test request sets to the server in batches. Furthermore, since the server generates verification fingerprints for each client, frequent modifications and reloading of the verification fingerprint protection configuration are unnecessary during testing, improving testing efficiency and better reflecting real-world online usage scenarios.

[0145] In one exemplary embodiment, such as Figure 7 As shown, the specific processing steps for determining the server's test results based on each protection result set in step 604 include steps 702 to 706. Wherein:

[0146] Step 702: Determine the initial test result for verifying the fingerprint based on the number of results of the protection results in each protection result set.

[0147] In implementation, the client determines the corresponding test request set for each protection result set. Then, the client determines the initial test result for verifying the fingerprint based on the number of normal requests in the test request set and the number of protection results in the protection result set.

[0148] Specifically, for each protection result set in each protection result set, the client determines the corresponding test request set. Then, the client counts the normal test requests in the test request set to obtain the number of normal requests, and counts the protection results in the protection result set to obtain the number of results. The client then determines whether the number of results equals the number of normal requests, obtains the determination result, and uses the determination result to determine the initial test result for verifying the fingerprint.

[0149] Step 704: If there is no initial test result indicating that the test failed, determine that the test result on the server side has passed and confirm that the security of the server side meets the standards.

[0150] During implementation, the client checks if any of the initial test results indicate a test failure. If no initial test result indicates a test failure, meaning all initial test results indicate a test success, the client determines that the server's test result is successful. Simultaneously, the client confirms that the server's security meets the required standards. Security compliance means that the server can accurately block requests matching the JA3 fingerprint blacklist when multiple QUIC or HTTPS protocols with different JA3 fingerprints are configured, while allowing other requests that do not match the blacklist.

[0151] Step 706: If the initial test result is "test failed", determine the verification fingerprint corresponding to the initial test result as the problem verification fingerprint, and construct the test result of the server based on the server's security failure and the problem verification fingerprint.

[0152] In implementation, if an initial test result is "test failed," the client will use this initial test result as the target initial test result and the verification fingerprint corresponding to the target initial test result as the issue verification fingerprint. Then, the client will determine that the server's security is substandard and construct the server's test result using the information about the server's security failure and the issue verification result corresponding to the target initial test result.

[0153] In an optional embodiment, the client feeds back the server's test results to the target user through an interface, so that the target user can adjust the issue verification fingerprint based on the test results.

[0154] Optionally, the client can send the test results to the target user's terminal via SMS or email. The target user can be, but is not limited to, testers. This application embodiment does not limit the notification method or the target user.

[0155] In this embodiment, the test results of the server are determined by the initial test results of each verification fingerprint, which clarifies whether the verification fingerprint protection function in the server is normal and effectively verifies the verification fingerprint protection effect of the QUIC protocol.

[0156] In one exemplary embodiment, such as Figure 8 As shown, the specific processing procedure of step 702 includes steps 802 to 806. Wherein:

[0157] Step 802: For each set of test requests corresponding to the protection result set, determine whether the number of protection results in the protection result set is equal to the number of normal requests in the normal test request set.

[0158] In implementation, for each test request set corresponding to a protection result set, the client determines the number of protection results in the protection result set. Simultaneously, the client determines the number of normal requests among the normal test requests in the test request set. Then, the client checks whether the number of results equals the number of normal requests.

[0159] Specifically, since the verification fingerprint is used to block requests from the blacklist, the server intercepts abnormal test requests in the test request set and processes normal test requests to obtain the protection result. The number of protection results is sufficient to determine whether the server correctly blocked the requests, i.e., whether the verification fingerprint test passed. The client counts the protection results in the protection result set corresponding to each test request set, obtaining the number of results. Simultaneously, the client counts the normal test requests in the test request set, obtaining the number of normal requests. Then, the client determines whether the number of results equals the number of normal requests, obtaining the judgment result.

[0160] Step 804: If the number of results equals the number of normal requests, determine that the initial test result of the fingerprint verification is a successful test.

[0161] In practice, if the number of results equals the number of normal requests, the client determines that the server has successfully intercepted the request and determines the initial test result of fingerprint verification as a successful test.

[0162] Step 806: If the number of results is not equal to the number of normal requests, determine that the initial test result of fingerprint verification is a test failure.

[0163] In practice, if the number of results is not equal to the number of normal requests, the client determines that there is an abnormal interception on the server side and determines the initial test result of fingerprint verification as a test failure.

[0164] In this embodiment, by measuring the number of normal requests and the number of protection results in the normal test request, it is determined whether the verification fingerprint can successfully intercept abnormal requests and whether the protection fingerprint function is working properly, which facilitates the subsequent determination of the server's security.

[0165] In one exemplary embodiment, Figure 9 This is a flowchart illustrating the sending of a greeting data packet in an exemplary embodiment. Figure 9 As shown, a method for sending a greeting data packet is provided, the method including:

[0166] Step 901: Import the utls library.

[0167] Step 902: Create a for loop and set the threshold for the number of iterations.

[0168] Step 903: Create a 9-digit random number M.

[0169] Step 904: Establish a message middleware using http3.RoundTripper.

[0170] Step 905: Build Cipher Suite and write a random number M to the end of Cipher Suite.

[0171] Step 906: The roundTripper is passed to http.Client, a greeting data packet is generated, and an HTTP request is initiated.

[0172] Step 907, update the loop count, N = N + 1;

[0173] Step 908: Determine if the updated loop count is greater than the loop count threshold. If the updated loop count is greater than the loop count threshold, terminate the method. If the updated loop count is less than or equal to the loop count threshold, execute step 903 above.

[0174] It should be understood that although the steps in the flowcharts of the embodiments described above are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the embodiments described above may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0175] Based on the same inventive concept, this application also provides a security testing apparatus for implementing the security testing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more security testing apparatus embodiments provided below can be found in the limitations of the security testing method described above, and will not be repeated here.

[0176] In one exemplary embodiment, such as Figure 10 As shown, a security testing device 1000 is provided, including: an update module 1001, a generation module 1002, a sending module 1003, and a determination module 1004, wherein:

[0177] Update module 1001 is used to update the cipher suite in the encrypted communication library based on random numbers to obtain the updated cipher suite.

[0178] The generation module 1002 is used to generate greeting data packets based on the updated cipher suite until the number of cycles for updating the cipher suite reaches a preset cycle number threshold, thus obtaining each greeting data packet.

[0179] The sending module 1003 is used to send each greeting data packet to the server, instructing the server to generate each verification fingerprint in batches based on each greeting data packet.

[0180] The determination module 1004 is used to determine the test results of the server based on the test request set corresponding to each verification fingerprint.

[0181] In one exemplary embodiment, the update module 1001 includes:

[0182] The first generation submodule is used to call the encrypted communication library through the request middleware and generate random numbers based on a preset random number range.

[0183] The first addition submodule is used to determine the cipher suite in the encrypted communication library and add a random number at the target position of the cipher suite to obtain the updated cipher suite.

[0184] In one exemplary embodiment, the generation module 1002 includes:

[0185] The second generation submodule is used to generate greeting data packets based on the updated cipher suite, transport layer security version, extension, elliptic curve, and elliptic curve point format.

[0186] The second update submodule is used to update the number of cycles of the cipher suite and determine whether the updated number of cycles reaches the preset number of cycles threshold.

[0187] The first execution submodule is used to perform the step of updating the cipher suite in the encrypted communication library based on random numbers if the updated loop count does not reach the loop count threshold, until the updated loop count reaches the loop count threshold and the greeting data packets are obtained.

[0188] In one exemplary embodiment, the security testing apparatus 1000 further includes:

[0189] The judgment module is used to determine whether there is a duplicate target cipher suite in each greeting data packet.

[0190] The generation module is used to delete the greeting data packet containing the duplicate target cipher suite if duplicate target cipher suites exist.

[0191] The adjustment module is used to adjust the range of random numbers and generate new random numbers based on the adjusted range.

[0192] The second generation module is used to update the cipher suite based on the new random number and generate a new greeting data packet based on the updated cipher suite.

[0193] In one exemplary embodiment, the determining module 1004 includes:

[0194] The first sending submodule is used to send test request sets corresponding to each verification fingerprint to the server in batches; the test request sets are used to test whether the protection function of the verification fingerprint is normal and obtain the protection result set.

[0195] The first receiving submodule includes receiving the protection result set of each test request set and determining the test result of the server based on each protection result set.

[0196] In an exemplary embodiment, the first receiving submodule includes a second receiving submodule and a first determining submodule. The first determining submodule includes:

[0197] The second determination submodule is used to determine the initial test result of the verification fingerprint based on the number of results of the protection results in each protection result set.

[0198] The third determination submodule is used to determine if the server-side test result is successful if there is no initial test result indicating that the test failed, and to determine if the server-side security meets the standards.

[0199] The fourth determination submodule is used to determine the verification fingerprint corresponding to the initial test result as the problem verification fingerprint if the initial test result is a test failure, and to construct the test result of the server based on the server's security failure and the problem verification fingerprint.

[0200] In one exemplary embodiment, the second determining submodule includes:

[0201] The first judgment submodule is used to determine, for each test request set corresponding to the protection result set, whether the number of protection results in the protection result set is equal to the number of normal requests in the normal test request set.

[0202] The fifth determination submodule is used to determine the initial test result of the verification fingerprint as a pass if the number of results equals the number of normal requests.

[0203] The sixth determination submodule is used to determine the initial test result of the verification fingerprint as a test failure if the number of results is not equal to the number of normal requests.

[0204] Each module in the aforementioned safety testing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0205] In one exemplary embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 11As shown, the computer device includes a processor, memory, input / output interfaces, a communication interface, a display unit, and an input device. The processor, memory, and input / output interfaces are connected via a system bus, and the communication interface, display unit, and input device are also connected to the system bus via the input / output interfaces. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The input / output interfaces are used for exchanging information between the processor and external devices. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, mobile cellular networks, Near Field Communication (NFC), or other technologies. When the computer program is executed by the processor, it implements a security testing method. The display unit is used to form a visually visible image and can be a display screen, a projection device, or a virtual reality imaging device. The display screen can be an LCD screen or an e-ink screen. The input device of the computer device can be a touch layer covering the display screen, or buttons, trackballs, or touchpads set on the casing of the computer device, or external keyboards, touchpads, or mice, etc.

[0206] Those skilled in the art will understand that Figure 11 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0207] In one embodiment, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps in the above method embodiments.

[0208] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon that, when executed by a processor, implements the steps in the above method embodiments.

[0209] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps in the above method embodiments.

[0210] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0211] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0212] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A safety testing method, characterized in that: The method comprises: Update the cipher suite in the encryption communication library based on the random number to obtain an updated cipher suite; Generate a hello data packet according to the updated cipher suite until the number of cycles of updating the cipher suite reaches a preset cycle number threshold, thereby obtaining each hello data packet; Sending each of the greeting data packets to a server, instructing the server to batch generate verification fingerprints according to each of the greeting data packets; The test result of the server is determined based on the test request set corresponding to each of the verification fingerprints.

2. The method according to claim 1, characterized in that The method of updating the cryptographic suite in the encryption communication library based on the random number to obtain the updated cryptographic suite includes: The encrypted communication library is called by the request middleware, and a random number is generated based on the preset random number range; A cipher suite is determined in the encryption communication library, and the random number is added at a target position of the cipher suite to obtain an updated cipher suite.

3. The method according to claim 1, characterized in that The generating of the hello data packet according to the updated cipher suite until the number of cycles of updating the cipher suite reaches a preset cycle number threshold, to obtain each hello data packet, includes: generating a hello packet according to the updated cipher suite, transport layer security version, extension, elliptic curve, and elliptic curve point format; Updating the number of cycles of the cipher suite, and determining whether the updated number of cycles reaches a preset number of cycles threshold; If the updated number of cycles does not reach the cycle number threshold, the step of updating the cipher suite in the encryption communication library based on the random number is performed until the updated number of cycles reaches the cycle number threshold, thereby obtaining each greeting data packet.

4. The method according to claim 1, characterized in that: Before sending each of the greeting data packets to the server, the method further includes: Determining whether a target cipher suite is repeated in each of the hello packets; If the target cipher suite is repeated, delete the hello data packet containing the repeated target cipher suite; Adjusting the range of the random number, and generating a new random number based on the adjusted range of the random number; The cipher suite is updated based on the new random number, and a new hello data packet is generated according to the updated cipher suite.

5. The method according to claim 1, characterized in that The determining the test result of the server based on the test request set corresponding to each verification fingerprint includes: Sending a test request set corresponding to each verification fingerprint to the server in batches; the test request set is used to test whether the protection function of the verification fingerprint is normal, and obtain a protection result set; Receive the protection result set of each of the test request sets, and determine the test result of the server based on each of the protection result sets.

6. The method according to claim 5, characterized in that Determining the test result of the server based on each of the protection result sets includes: Determining an initial test result of the verification fingerprint based on the number of results of the protection results in each of the protection result sets; If the initial test result does not indicate that the test fails, determine that the test result of the server is that the test passes, and determine that the security of the server meets the standard; If there is an initial test result that the test fails, the verification fingerprint corresponding to the initial test result is determined as the problem verification fingerprint, and the test result of the server is constructed based on the security failure of the server and the problem verification fingerprint.

7. The method according to claim 6, characterized in that The determining the initial test result of the verification fingerprint based on the result quantity of the protection results in each of the protection result sets includes: For each protection result set corresponding to the test request set, determine whether the number of protection results in the protection result set is equal to the number of normal test requests in the test request set; If the number of results is equal to the number of normal requests, determining that the initial test result of the verification fingerprint is a test pass; If the number of results is not equal to the number of normal requests, it is determined that the initial test result of the verification fingerprint is a test failure.

8. A safety testing device, characterized in that: The device comprises: An update module, used for updating the cipher suite in the encryption communication library based on the random number to obtain an updated cipher suite; A generating module, configured to generate a greeting data packet according to the updated cipher suite until the number of cycles of updating the cipher suite reaches a preset cycle number threshold, thereby obtaining each greeting data packet; A sending module, used to send each of the greeting data packets to a server, and instruct the server to batch generate verification fingerprints according to each of the greeting data packets; A determination module is used to determine the test result of the server based on the test request set corresponding to each verification fingerprint.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 7 are implemented.

Citation Information

Patent Citations

  • Handshake method and system based on datagram secure transmission protocol

    CN108650227A

  • Communication protocol encryption method and device, computer equipment and storage medium

    CN114679299A