A logical vulnerability detection method and system for TLS protocol implementation

Abstract

The application relates to the technical field of network security automatic analysis, and discloses a logical vulnerability detection method and system for a TLS protocol implementation, which comprises the following steps: according to the state of a test object, selecting the message type of a test case, and selecting a message tuple subjected to probabilistic mutation according to a predefined TLS message template to splice and encapsulate, receiving response data of the test object after generating a final test case, removing encryption encapsulation and refining information, and judging whether there is a difference in the simplified test information between the test objects; if there is no difference, updating the state of the test object, testing the next level protocol state, and obtaining a test record result. The purpose of deep protocol state testing of the TLS protocol is achieved, the problem of a TLS protocol implementation test Oracle is effectively solved, and then the logical vulnerability detection of a hidden TLS protocol implementation deep protocol state can be realized.

Description

Technical Field

[0001] This invention relates to the field of automated network security analysis technology, and in particular to a method and system for detecting logical vulnerabilities in TLS protocol implementations. Background Technology

[0002] The statements in this section merely refer to the background art related to this invention and do not necessarily constitute prior art.

[0003] The Transport Layer Security (TLS) protocol sits between the application and transport layers of the TCP / IP reference model, providing confidentiality, integrity, and authenticity protection for communication between clients and servers on the Internet. It effectively prevents malicious third-party eavesdropping, tampering, and impersonation of data during transmission. Browsers, email, instant messaging, and other applications widely support the TLS protocol. To achieve secure protection of network communication data, based on TLS-related RFC (Request For Comments) documents, numerous TLS implementation libraries in different programming languages ​​and application platforms have emerged to support TLS communication, such as OpenSSL (an open-source TLS implementation library) and MatrixSSL (an open-source TLS implementation library). However, due to the complexity of the TLS protocol itself and implementation issues by developers, these implementation libraries have been repeatedly exposed to serious security vulnerabilities. A large portion of these vulnerabilities are logical vulnerabilities, which typically do not exhibit obvious software errors (such as program crashes), making them difficult for software testers to detect. However, they often pose serious security risks, such as the Heartbleed vulnerability in OpenSSL and the ChangeCipherSpec injection vulnerability.

[0004] Currently, fuzzing is a relatively mature and popular technique in software testing, used to monitor security issues in software implementations by sending different input data to the test object. However, there is a lack of methods for detecting deep-level protocol state logic vulnerabilities in the TLS protocol implementation. Current fuzzing techniques for detecting logical vulnerabilities in TLS protocol implementations have the following main shortcomings:

[0005] (1) Mainstream general-purpose fuzzing methods (such as AFL) have played an important role in the field of software testing, but their test case generation method based on bit-level mutation is not suitable for complex encryption protocols such as TLS. It is difficult to correctly complete the early interaction of the TLS handshake process, thus failing to efficiently detect potential security problems in the deep protocol state of TLS.

[0006] (2) For fuzzing methods targeting specific domains of TLS, effective test cases can be generated based on the TLS message syntax structure, but detecting logical vulnerabilities in the software implementation requires explicit testing oracles. Currently, fuzzing work for TLS, such as TLS-Attacker and TLS-Anvil, is based on manually defined testing oracles, which has limited test coverage and cannot detect logical vulnerabilities beyond the testers' knowledge.

[0007] (3) Differential fuzzing is an effective method for detecting logical vulnerabilities in software implementation. tls-diff was the first to apply the idea of ​​differential testing to the testing of the TLS handshake protocol. However, since it did not solve the problem of consistency judgment of test input and response messages in deep protocol states, it only implemented the test of the first handshake message ClientHello. In fact, logical vulnerabilities related to the TLS protocol exist in deeper protocol states. Therefore, it is insufficient for detecting logical vulnerabilities in deep protocol states in the TLS protocol implementation. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention provides a method and system for detecting logical vulnerabilities in TLS protocol implementations. In actual differential fuzzing testing, by removing encrypted encapsulation and extracting key information, consistency judgment is performed on the simplified response message. A method for consistency judgment in TLS differential fuzzing testing is proposed, achieving the goal of deep-level protocol state testing of the TLS protocol. This effectively solves the problem of TLS protocol implementation testing oracles, and thus enables the detection of logical vulnerabilities in the hidden deep-level protocol state of the TLS protocol implementation.

[0009] In a first aspect, the present invention provides a logical vulnerability detection method for TLS protocol implementation;

[0010] A logical vulnerability detection method for TLS protocol implementations includes:

[0011] Obtain the RFC documents related to the TLS protocol message structure definition;

[0012] For the RFC document, after extracting the type and description information of the message fields, they are classified to obtain message tuples, and a mutation strategy is defined for each type of message tuple;

[0013] Based on the state of the test object, select the message type of the test case, and select message tuples that have undergone probabilistic mutation according to the predefined TLS message template for concatenation and encapsulation to generate the final test case. After synchronously sending it to multiple test objects, receive the response data of the test objects, remove the encrypted encapsulation and extracted information from the response data to obtain simplified test information, and determine whether there are differences in the simplified test information between the test objects. If there are no differences, update the state of the test object, perform the test of the next layer of protocol state, and obtain the test record results.

[0014] By using a coding classification and statistical analysis method, the test record result files were analyzed to identify the security issues present in the TLS protocol implementation library.

[0015] Furthermore, the methods for extracting the type and description information of message fields include: document block segmentation, regular expression matching, word segmentation, dependency parsing, and part-of-speech tagging.

[0016] Furthermore, the steps for defining the mutation strategy include: acquiring vulnerabilities in the TLS implementation library, filtering out vulnerabilities in cryptographic implementation and certificate verification, retaining only vulnerabilities triggered by message streams, performing statistical analysis on the triggering conditions of vulnerabilities, recording whether the triggering conditions are related to the anomalies of a certain message field, and defining a mutation strategy for each type of message tuple based on the characteristics of different message tuples.

[0017] Furthermore, if there are discrepancies in the simplified test information between the test objects, the TLS session will be interrupted.

[0018] Furthermore, the test record results include: TLS session count, whether it is a normal response, whether there are response differences, simplified test information of test cases and test responses, record of message tuple mutations involved in the test cases, and test time.

[0019] Furthermore, the first stage of the coding classification statistical analysis method is as follows: tuple mutation records that fail to produce differential responses are screened out, and tuple mutation records that cause differential responses and contain normal responses are marked as requiring the second stage of analysis.

[0020] Furthermore, the second stage of the coding classification statistical analysis method is as follows: for tuple mutation records marked as requiring the second stage analysis, multiple filtering conditions are used for screening, the screening results are analyzed, and the causes of the differential response are determined.

[0021] Secondly, the present invention provides a logic vulnerability detection system for TLS protocol implementation;

[0022] A logic vulnerability detection system for TLS protocol implementations includes:

[0023] The message tuple and mutation policy definition module is configured to: obtain RFC documents related to the TLS protocol message structure definition; extract the type and description information of the message fields from the RFC documents; classify them to obtain message tuples; and define a mutation policy for each type of message tuple.

[0024] The TLS protocol implements a deep differential fuzz testing module, which is configured to: select the message type of the test case according to the state of the test object, and select message tuples that have undergone probabilistic mutation according to the predefined TLS message template for concatenation and encapsulation to generate the final test case. After synchronously sending it to multiple test objects, it receives the response data of the test objects, removes the encrypted encapsulation and extracted information from the response data to obtain simplified test information, and determines whether there is a difference between the simplified test information of the test objects. If there is no difference, it updates the state of the test object, performs the test of the next layer of protocol state, and obtains the test record results.

[0025] The test result classification and statistical analysis module is configured to: use a coding classification and statistical analysis method to analyze the test record result file and obtain the security issues existing in the TLS protocol implementation library.

[0026] Thirdly, the present invention provides an electronic device, comprising:

[0027] Memory, used for non-transitory storage of computer-readable instructions; and

[0028] Processor, for executing the computer-readable instructions,

[0029] When the computer-readable instructions are executed by the processor, they perform the method described in the first aspect above.

[0030] Fourthly, the present invention also provides a storage medium for non-transitory storage of computer-readable instructions, wherein, when the non-transitory computer-readable instructions are executed by a computer, the instructions for the method described in the first aspect are executed.

[0031] Compared with the prior art, the beneficial effects of the present invention are:

[0032] In the actual differential fuzzing test process, this invention removes the encrypted encapsulation and extracts key information to perform consistency judgment on the simplified response message. By using the TLS differential fuzzing consistency judgment method, it achieves the purpose of deep protocol state testing of the TLS protocol, effectively solving the problem of TLS protocol implementation test oracle, and thus enabling the detection of logical vulnerabilities in the hidden deep protocol state of the TLS protocol implementation.

[0033] In the test result analysis stage, this invention uses a coding classification statistical analysis method. First, based on the classification statistical results, tuple mutation types that do not require further analysis are screened out. Then, more granular analysis is performed on key tuple mutations, enabling rapid and effective analysis of massive differential test results. Attached Figure Description

[0034] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments of this application and their descriptions are used to explain this application and do not constitute an undue limitation of this application.

[0035] Figure 1 This is a flowchart of a logic vulnerability detection method for a TLS protocol implementation as described in Embodiment 1;

[0036] Figure 2 This is a diagram defining the message tuple and mutation strategy types as described in Example 1;

[0037] Figure 3 This is a flowchart of the TLS differential fuzzing test described in Example 1;

[0038] Figure 4 This is a core code diagram of the vulnerability in MatrixSSL session reuse using an empty master key as described in Example 1. Detailed Implementation

[0039] It should be noted that the following detailed descriptions are exemplary and intended to provide further explanation of this application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains.

[0040] It should be noted that the terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the exemplary embodiments according to this application. As used herein, the singular form is intended to include the plural form as well, unless the context clearly indicates otherwise. Furthermore, it should be understood that when the terms "comprising" and / or "including" are used in this specification, they indicate the presence of features, steps, operations, devices, components, and / or combinations thereof.

[0041] Example 1

[0042] This embodiment provides a method for detecting logical vulnerabilities in TLS protocol implementations.

[0043] This embodiment provides a logical vulnerability detection method for TLS protocol implementations, based on deep differential fuzzing testing.

[0044] This embodiment provides a logical vulnerability detection method for TLS protocol implementation. During differential fuzzing of TLS, it abstracts and categorizes field types based on the diverse nature of TLS message types but the presence of similar or identical message field types, defining the concept of message tuples. This simplifies the complexity of mutation strategy definition in traditional TLS domain-specific fuzzing methods. The method guides the selection of message types for test cases based on the response state of the test object, and uses predefined message templates to select message tuples that have undergone probabilistic mutations for splicing and encapsulation, generating highly likely effective test cases and reducing useless testing. By removing encryption encapsulation and extracting key information from the original test data, it solves the problem of inconsistency in the original test data of deeper protocol states caused by the participation of random fields, avoiding interruption of testing deeper protocol states in the current TLS session due to inconsistent judgments of response messages. The testing process encodes and records message types, message tuples, specific fields, and tuple mutation types, using this encoding for classification and statistical analysis of test results, greatly simplifying the analysis of massive amounts of differential test results.

[0045] This embodiment provides a logical vulnerability detection method for TLS protocol implementations, such as... Figure 1 As shown, it includes the following steps:

[0046] Step 1: Extract the type and description information of the message fields in the RFC document, abstract and classify the field types, and define message tuples.

[0047] In step 1, the message structure, message field types, and descriptions for different message types are extracted. Natural language processing methods such as document block partitioning, regular expression matching, word segmentation, dependency parsing, and part-of-speech tagging are used to automate the extraction of this information. The code is implemented using Python's `re` and `spaCy` libraries. After obtaining this information, the field types and their descriptions are analyzed, and field types that are similar or identical in form are abstracted and categorized, defined as message tuples for subsequent test case assembly and encapsulation. This abstract categorization avoids the need to define mutation strategies separately for different message fields of each message type.

[0048] Specifically, RFC documents related to the TLS protocol message structure definition were collected. The test version of this invention is TLS 1.2, and the corresponding RFC documents include RFC5246, RFC6066, and RFC6520. Natural language processing was performed on these RFC documents as follows:

[0049] (1) Document Block Division: The RFC document to be processed is divided into document blocks according to chapters, and the hierarchical relationship between the chapter titles is recorded. By dividing the document into document blocks by chapters, it is possible to ensure that the field information in the same context as the structure is extracted, thereby avoiding the ambiguity of parsing the same field name in different structures and reducing the search scope for extracting relevant descriptive text.

[0050] (2) Extraction of Structures and Enumeration Types: In TLS-related RFC documents, messages are usually defined in the form of structures. The definition types of message fields include structure types, enumeration types, and common basic types such as "uint24" and "opaque". Based on the document feature structure, corresponding regular expressions were designed, and then all structures and enumeration types were automatically extracted from the pre-processed text blocks.

[0051] (3) Extracting Message Field Types: Within the extracted structures, regular expressions are used to parse out the types of each field. After traversing each text block, the types of fields are globally traced based on the fields in each structure. This step is to supplement field definitions declared outside the structure.

[0052] (4) Extracting Field Description Information: The sources for extracting relevant information in this step are as follows: First, usually following the structure declaration, the RFC will interpret the fields sequentially. Its structure is specific, and it can be extracted directly through simple string matching. Second, other text in the section may provide supplementary descriptions of certain fields. Natural language processing methods such as word segmentation, dependency parsing, and part-of-speech tagging are used to determine whether they are related to a specific field, thereby extracting the sentence text. Third, related text for a certain field may further describe the field by referencing other chapter titles. Based on the preprocessed chapter division, the corresponding text block is located through the title, and then processed in the same way as the second source. Extracting field description information can assist in the subsequent abstraction and classification of field types.

[0053] The above steps are implemented using Python and the third-party libraries re and spaCy. Through the automated extraction process, the structures, field types, and descriptions of different TLS message types are obtained. Observation and analysis reveal that different message types exhibit similar or identical message field types. This formal similarity refers to the fact that some field types, despite different content definitions, share the same format. For example, the CipherSuites field and the support_versions extension field in the ClientHello message, while having completely different content, are both similar list types providing optional content and can be abstractly categorized. Therefore, this invention abstracts and categorizes these field types, proposing the concept of message tuples. Message tuples are used for the subsequent assembly and encapsulation of test cases. In other words, the concept of message tuples is an abstract categorization definition for identical or similar field types. Compared to traditional TLS domain-specific fuzzing methods, this categorization approach greatly simplifies the definition of mutation strategies.

[0054] Step 2: Define the corresponding mutation strategy for each type of message tuple.

[0055] In step 2, this invention crawled historical vulnerabilities from 2014 to the present from the CVE Details official website for mainstream TLS protocol implementation libraries such as OpenSSL and MatrixSSL, and filtered out vulnerabilities related to password implementation and certificate verification, retaining only vulnerabilities triggered by message flow. Vulnerabilities whose triggering conditions are caused by abnormal message fields were recorded and analyzed. Combining the characteristics of the message tuples defined in step 1, a corresponding tuple mutation strategy (abnormal mutation probability) was defined, and the mutation strategy of message tuples was defined in the configuration file tuples.xml.

[0056] Specifically, this embodiment crawled all vulnerabilities of mainstream TLS implementation libraries from 2014 to the present from the CVE Details website, and filtered out vulnerabilities related to cryptographic implementation and certificate verification, retaining only message stream-triggered vulnerabilities. Statistical analysis was performed on the triggering conditions of these vulnerabilities, recording whether the triggering conditions were related to anomalies in a particular message field. Combining the inherent characteristics of different message tuples, corresponding mutation strategies were defined for each type of message tuple. The inherent characteristics of message tuples refer to the possible anomalies inherent in different message tuple types. These mutations stem from the understanding of conventional type definitions and the restrictive descriptions in RFC documents. For example, the Length tuple used for length indication clearly exhibits anomalies of becoming longer (Longer) and shorter (Shorter).

[0057] The definitions of message tuples and mutation strategy types in this embodiment are as follows: Figure 2 As shown, Figure 2The hexadecimal values ​​in the first two columns “[]” are 4-bit encoded information of the message tuple and its mutation strategy.

[0058] Step 3: Obtain the message tuple mutation policy configuration information defined in Step 1 and Step 2, and perform deep differential fuzz testing on the target TLS implementation library.

[0059] In step 3, firstly, the configuration file `tuples.xml` is read to obtain the mutation strategies for various message tuples. During the test, the message type of the test case is selected based on the current state of the test object. Then, message tuples that have undergone probabilistic mutation are selected according to the predefined TLS message template, concatenated, and encapsulated to generate the final test case, which is simultaneously sent to multiple test objects. After receiving the original test response data from the test object, the encryption encapsulation is removed and key information is extracted (eliminating the interference of random fields on the consistency judgment of messages in the deep protocol state, thus achieving the purpose of TLS deep protocol state differential testing). The simplified message is analyzed to determine whether there are response differences between test objects. If there are, the current TLS session is interrupted and a new TLS session test begins; if not, the current state of the test object is updated according to the response message, and the test of deeper protocol states continues. During the test, the simplified message is recorded in the test result file `refine.csv`, and the original data during the test is recorded and saved to `packets.pcap` using Winpcap.

[0060] Specifically, the differential fuzzing testing process for the TLS protocol is as follows: Figure 3 As shown, the outer dashed box represents the main loop of differential fuzzy testing, and the inner dashed box represents the single TLS session test process. When generating test cases, the current state of the test object is first determined based on its response message type. Then, based on this current state, the message type of the test case is selected according to the TLS protocol flow, i.e., which step of the TLS handshake message test should be performed. Then, message tuples with probabilistic mutations are selected according to predefined TLS message templates (message structures for different message types defined by RFC documents), concatenated, and encapsulated to generate the final test case. After receiving the response message data of the test object, the encryption encapsulation is first removed, and key information (message type, protocol version, indicator length, random nature of padding or random fields, etc.) is extracted to obtain simplified test information. It is then observed whether there are differences between the simplified messages of the test objects. If there are, the current TLS session is interrupted, and a new session test begins. If not, the current state of the test object is updated according to its response message type, and deeper handshake protocol state testing continues.

[0061] Due to significant differences in the implementation details of different TLS protocol libraries, testing more test objects simultaneously increases the probability of generating response discrepancies. Frequent response discrepancies can affect the protocol state depth of differential testing. Therefore, in actual testing, a maximum of three test objects were used simultaneously. This allows them to serve as mutual references while ensuring test depth. During testing, the original test data recording file was packets.pcap, and the simplified test record result file was refine.csv. The refine.csv file contains important test information such as TLS session count, whether the response was normal, whether response discrepancies existed, simplified test information for test cases and test responses, message tuple mutation records involved in this test case, and test time.

[0062] Step 4: The test record results file from Step 3 is categorized and statistically analyzed using coding to identify potential security issues in the differential response entries. Specifically, a coding-based categorized statistical analysis method was used, employing two phases: coarse-grained statistical screening and fine-grained key analysis, to identify potential security issues in the TLS protocol implementation library from the key differential response results.

[0063] In step 4, for the test record file refine.csv, this embodiment proposes a method of encoding classification and statistical analysis, which encodes four types of elements: test message type, message tuple, specific field, and tuple mutation type, with each mutation of a specific field corresponding to a 16-bit encoding. The encoding is recorded during the test. The 16-bit encoding was used to perform a two-stage classification and statistical analysis of the test record results: In the first stage, tuple mutation records that failed to produce a difference response (i.e., all test objects implemented the same logic for handling abnormal situations in this field) were filtered out, and tuple mutation records that caused a difference response and contained normal responses (non-Alert type messages or no response) were marked for further fine-grained analysis. In the second stage, the tuple mutation records filtered out in the first stage were analyzed in detail. The test results were saved in CSV format, and a large number of test results were filtered through multiple filtering conditions (whether there is a difference in the simplified response message, whether there is a normal response conforming to the TLS protocol stream in the response message, the type of mutation encoded record, etc.). The filtered results were then analyzed, and the original test data file packets.pcap and the TLS implementation library source code were checked to analyze the causes of the difference response. The two-stage classification and statistical analysis filtered out a large number of test results, greatly simplifying the analysis of difference test results.

[0064] The following explanation uses a newly discovered high-risk vulnerability in MatrixSSL, CVE-2022-46505, as an example:

[0065] During the analysis of the first-stage classification and statistical results, it was found that there were differences in the response results corresponding to the tuple mutation record "0-5-00" (this record means that the SessionID field of the ClientHello message has a SmallRange mutation) and there were normal responses. This record was marked as needing to be analyzed in the next stage of fine-grained analysis.

[0066] In the second phase of analysis, the results were first filtered according to three criteria: "tuple mutation records contain 0-5-00", "there are response differences", and "all are normal responses". This filtered out 28 results from more than 200,000 results. Subsequently, two records were observed to be special. The response messages contained messages of session reuse. In this case, the length of the SessionID was 1. Further investigation of the original data and the MatrixSSL source code revealed that MatrixSSL did indeed have a security risk in processing the SessionID field, with the possibility of empty master keys being used.

[0067] The core code related to the MatrixSSL 4.5.1 vulnerability is as follows: Figure 4 As shown in the diagram, after receiving the SessionID, the server directly takes the first 4 bytes as the index value (maximum 31) for storing its historical SessionID list. When performing SessionID matching and comparison, the comparison length uses the minimum value between the actual SessionID length and 32, as shown in line 10. Therefore, when the actual SessionID field length is 1, there is a coupling situation. At this time, the corresponding master key in the server's SessionID list may be empty. The key between the client and the server can be calculated using the Random field of both parties.

[0068] The TLS version tested in this embodiment is TLS 1.2, the mainstream version currently used in the market. Furthermore, this invention focuses only on the TLS handshake protocol implementation itself, and not on the cryptographic implementation and certificate verification parts of the TLS protocol implementation library. Therefore, the differential fuzzing test code implementation only implements a portion of the key negotiation and encryption algorithm, and the cipher suite used for testing is TLS_RSA_WITH_AES_256_CBC_SHA. The differential fuzzing test in this embodiment is a black-box test, independent of the implementation language and platform of the test object; the test object is a TLS protocol implementation server.

[0069] This embodiment provides a logical vulnerability detection method for TLS protocol implementations, solving the problem of deep-level protocol state testing oracles in TLS implementations and enabling the detection of deep-level protocol state logical vulnerabilities. Based on natural language processing, it automates the extraction of message structure, field types, and limiting descriptions from TLS-related RFC documents. By analyzing field types, it abstracts and categorizes formally similar or identical field types, proposing the concept of message tuples. By analyzing the historical vulnerability triggering conditions of TLS implementation libraries and the inherent characteristics of message tuples, it defines corresponding mutation strategies for each type of message tuple, simplifying the definition of mutation strategies in the TLS fuzzing process. It guides the selection of message types for test cases based on the current state of the test object, and selects message tuples that have undergone probabilistic mutations according to a predefined message structure template for splicing and encapsulation to generate test cases. In actual differential fuzzing, By removing encrypted encapsulation and extracting key information, a consistency judgment is performed on the simplified response message. This redefinition of TLS differential fuzzing consistency judgment achieves the goal of deep protocol state testing of the TLS protocol. Guided by the state of the test object, message tuples are selected, concatenated, and encapsulated according to a predefined message template to generate test cases, realizing deep differential fuzzing testing of the TLS protocol implementation. Finally, in the test result analysis phase, based on the encoding classification statistical analysis method, tuple mutation types that do not require further analysis are first filtered out according to the classification statistical results. Then, more granular analysis is performed on key tuple mutations, enabling rapid and effective analysis of massive differential test results. This invention achieves efficient differential fuzzing testing of the deep protocol state of the TLS protocol implementation, thereby enabling the detection of more hidden deep-level logical vulnerabilities in the TLS implementation library and discovering actual security issues during testing, including a newly discovered high-risk logical vulnerability.

[0070] This embodiment provides a logical vulnerability detection method for TLS protocol implementation, which realizes differential fuzzy testing of the deep protocol state of TLS protocol implementation, effectively solves the problem of TLS protocol implementation test oracle, and thus enables the detection of logical vulnerabilities in the hidden deep protocol state of TLS protocol implementation.

[0071] This embodiment provides a logical vulnerability detection method for TLS protocol implementations. It has completed actual testing on multiple versions of 9 mainstream TLS implementation libraries, and discovered 1 new MatrixSSL high-risk vulnerability CVE-2022-46505, 4 historical CVE vulnerabilities, and 24 other potential security issues.

[0072] Example 2

[0073] This embodiment provides a logic vulnerability detection system for TLS protocol implementation, including three modules: a message tuple and mutation strategy definition module, a TLS protocol implementation deep differential fuzzy testing module, and a test result classification and statistical analysis module.

[0074] The message tuple and mutation strategy definition module is configured to: automatically extract the message structure, message field types and limiting description information of TLS-related RFC documents, abstract and classify the field types, define the concept of message tuples, and define corresponding mutation strategies for each type of message tuple based on historical CVE triggering conditions and the characteristics of message tuples themselves. It also defines configuration files for use in the TLS protocol implementation of the deep differential fuzzing testing module.

[0075] A deep differential fuzzing module for the TLS protocol is configured to: acquire message tuple mutation policy configuration information defined in the previous module; generate test cases through state guidance, concatenating and encapsulating message tuples based on message syntax structure to achieve test cases; and redefine the method for consistency judgment in TLS differential fuzzing. This enables deep differential fuzzing testing of the TLS protocol implementation library's protocol state, thereby achieving the detection of deeper logical vulnerabilities. The testing process encodes message types, message tuples, specific fields, and mutation types, and concisely records test information.

[0076] The test result classification and statistical analysis module is configured to enable rapid and effective analysis of massive amounts of differential test results through a coded classification and statistical analysis method. Specifically, it performs a two-stage coded classification and statistical analysis on the test record result files from the previous module to identify potential security issues from key differential response results.

[0077] The detailed process of each component has been described in Example 1.

[0078] Example 3

[0079] This embodiment also provides an electronic device, including: one or more processors, one or more memories, and one or more computer programs; wherein, the processor is connected to the memory, and the one or more computer programs are stored in the memory. When the electronic device is running, the processor executes the one or more computer programs stored in the memory to cause the electronic device to perform the method described in Embodiment 1.

[0080] It should be understood that in this embodiment, the processor can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0081] Memory may include read-only memory and random access memory, and provides instructions and data to the processor. A portion of memory may also include non-volatile random access memory. For example, memory may also store information about the device type.

[0082] In the implementation process, each step of the above method can be completed by the integrated logic circuits in the processor hardware or by software instructions.

[0083] The method in Embodiment 1 can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor. The software modules can reside in readily available storage media in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, a detailed description is not provided here.

[0084] Those skilled in the art will recognize that the units and algorithm steps described in connection with the various examples of this embodiment can be implemented in electronic hardware or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0085] Example 4

[0086] This embodiment also provides a computer-readable storage medium for storing computer instructions, which, when executed by a processor, complete the method described in Embodiment 1.

[0087] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A logical vulnerability detection method for TLS protocol implementations, characterized in that, include: Obtain the RFC documents related to the TLS protocol message structure definition; For the RFC document, after extracting the type and description information of the message fields, the field types that are similar or identical in form are abstracted and classified to obtain message tuples, and a mutation strategy is defined for each type of message tuple; Based on the state of the test object, select the message type of the test case, and select message tuples that have undergone probabilistic mutation according to the predefined TLS message template for concatenation and encapsulation to generate the final test case. After synchronously sending it to multiple test objects, receive the response data of the test objects, remove the encrypted encapsulation and extracted information from the response data to obtain simplified test information, and determine whether there are differences in the simplified test information between the test objects. If there are no differences, update the state of the test object, perform the test of the next layer of protocol state, and obtain the test record results. By using a coding classification statistical analysis method, the test record result files were analyzed to identify the security issues present in the TLS protocol implementation library. The steps for defining the mutation strategy include: acquiring vulnerabilities in the TLS implementation library, filtering out vulnerabilities in cryptographic implementation and certificate verification, retaining only vulnerabilities triggered by message streams, performing statistical analysis on the triggering conditions of the vulnerabilities, recording whether the triggering conditions are related to the anomalies of a certain message field, and defining a mutation strategy for each type of message tuple based on the characteristics of different message tuples. The first stage of the coding classification statistical analysis method is as follows: tuple mutation records that fail to produce differential responses are screened out, and tuple mutation records that cause differential responses and contain normal responses are marked as requiring the second stage of analysis. The second stage of the coding classification statistical analysis method is as follows: for tuple mutation records marked as requiring the second stage analysis, multiple filtering conditions are used for screening, the screening results are analyzed, and the causes of differential responses are determined.

2. The logical vulnerability detection method for TLS protocol implementation as described in claim 1, characterized in that, The methods for extracting the type and description information of message fields include: document block segmentation, regular expression matching, word segmentation, dependency parsing, and part-of-speech tagging.

3. The logical vulnerability detection method for TLS protocol implementation as described in claim 1, characterized in that, If there are discrepancies in the simplified test information between the test objects, the TLS session will be terminated.

4. The logical vulnerability detection method for TLS protocol implementation as described in claim 1, characterized in that, The test record results include: TLS session count, whether it is a normal response, whether there are response differences, simplified test information of test cases and test responses, record of message tuple mutations involved in the test cases, and test time.

5. A logic vulnerability detection system for TLS protocol implementation, characterized in that, include: The message tuple and mutation strategy definition module is configured to: obtain the RFC document related to the TLS protocol message structure definition; for the RFC document, extract the type and description information of the message fields; abstract and classify the field types that are similar or identical in form to obtain message tuples; and define a mutation strategy for each type of message tuple. The TLS protocol implements a deep differential fuzz testing module, which is configured to: select the message type of the test case according to the state of the test object, and select message tuples that have undergone probabilistic mutation according to the predefined TLS message template for concatenation and encapsulation to generate the final test case. After synchronously sending it to multiple test objects, it receives the response data of the test objects, removes the encrypted encapsulation and extracted information from the response data to obtain simplified test information, and determines whether there is a difference between the simplified test information of the test objects. If there is no difference, it updates the state of the test object, performs the test of the next layer of protocol state, and obtains the test record results. The test result classification and statistical analysis module is configured to: use a coding classification and statistical analysis method to analyze the test record result file and obtain the security issues existing in the TLS protocol implementation library; The steps for defining the mutation strategy include: acquiring vulnerabilities in the TLS implementation library, filtering out vulnerabilities in cryptographic implementation and certificate verification, retaining only vulnerabilities triggered by message streams, performing statistical analysis on the triggering conditions of the vulnerabilities, recording whether the triggering conditions are related to the anomalies of a certain message field, and defining a mutation strategy for each type of message tuple based on the characteristics of different message tuples. The first stage of the coding classification statistical analysis method is as follows: tuple mutation records that fail to produce differential responses are screened out, and tuple mutation records that cause differential responses and contain normal responses are marked as requiring the second stage of analysis. The second stage of the coding classification statistical analysis method is as follows: for tuple mutation records marked as requiring the second stage analysis, multiple filtering conditions are used for screening, the screening results are analyzed, and the causes of differential responses are determined.

6. An electronic device, characterized in that it comprises: Memory is used to store computer-readable instructions in a non-transitory manner. as well as Processor, for executing the computer-readable instructions, When the computer-readable instructions are executed by the processor, they perform the method described in any one of claims 1-4.

7. A storage medium, characterized in that, The computer-readable instructions are stored non-transitory, wherein when the non-transitory computer-readable instructions are executed by a computer, the instructions of the method according to any one of claims 1-4 are executed.

Images