Method for extracting tls protocol extension sni based on fpga

Abstract

This application relates to the field of network security technology and discloses a method for extracting the TLS protocol extension SNI based on FPGA. The method includes: receiving network packets; extracting layer 2, 3, and 4 protocol header information and calculating and locating the payload content and starting position; determining whether the packet is a TLS Client Hello packet under the TCP protocol based on the payload content; if so, parsing the common fields of the payload according to the TLS Client Hello packet format and calculating the starting offset of the first extension header field; starting from this starting offset, sequentially parsing and matching the type-length-value format of the extension header fields until the SNI extension header field is identified or all extension header fields have been traversed; if the SNI extension header field is identified, extracting and outputting the SNI information from the corresponding value field according to its length indicator field. This method is implemented based on FPGA hardware logic, has high extraction accuracy, low logic resource consumption, and can achieve parallel processing of multiple packets, meeting the actual requirements of network traffic splitting devices for SNI information extraction.

Description

Technical Field

[0001] This application relates to the field of network security technology, specifically to a method for extracting the TLS protocol extension SNI based on FPGA. Background Technology

[0002] HTTPS, as a secure version of HTTP, ensures the security and integrity of data transmission by adding a TLS encryption layer at the transport layer, and has become the mainstream protocol for Internet communication. Server Name Indicator (SNI) is an important extension of the TLS protocol. During the handshake phase, the client sends the target server's hostname to the server via a Client Hello message using the SNI header. This header uses TLV encoding and its position within the message is not fixed.

[0003] Currently, some illegal websites are using the encryption features of the TLS protocol to evade domain name blocking, posing higher demands on network security supervision. Rapid and accurate extraction of SNI information has become a key requirement in network traffic offloading and security monitoring. Existing FPGA-based SNI extraction solutions have significant technical flaws. Mainstream pipeline extraction solutions, due to their fixed design of the number of TLS extension headers to be parsed, cannot adapt to situations where the number of extension headers is variable, easily leading to missed SNI information extraction. On the other hand, full-packet byte-by-byte sliding matching solutions based on SNI feature formats not only consume a large amount of FPGA logic resources—the larger the data processing bit width, the greater the resource consumption—but are also prone to feature mismatches, resulting in distorted extracted SNI information.

[0004] In summary, existing FPGA extraction solutions struggle to balance the accuracy of SNI information extraction with low logic resource consumption, failing to meet the practical application requirements for efficient and accurate SNI information extraction in high-speed network environments. Therefore, a new FPGA-based TLS protocol extension SNI extraction method is urgently needed to address these issues. Summary of the Invention

[0005] The purpose of this application is to provide a method for extracting the TLS protocol extension SNI based on FPGA, so as to solve the problems mentioned in the background art.

[0006] According to one aspect of this application, a method for extracting the TLS protocol extension SNI based on FPGA is provided, comprising the following steps: Step S1: Receive network packets, extract the layer 2, 3, and 4 protocol header information of the packets, and calculate and locate the payload content and payload start position of the packets based on the layer 2, 3, and 4 protocol header information. Step S2: Based on the payload content, determine whether the message is a TLS Client Hello message under the TCP protocol; Step S3: If yes, then based on the TLS Client Hello message format, parse the common fields in the payload content and calculate the starting offset of the first extended header field; Step S4: Starting from the initial offset of the first extension header field, perform type-length-value format parsing and matching on the extension header fields in the payload content in sequence until an extension header field with extension type Server Name Indicator (SNI) is identified or all extension header fields have been traversed. Step S5: If the extended header field of the Server Name Indicator (SNI) is identified, the Server Name Indicator (SNI) information is extracted from the value field of the extended header field of the Server Name Indicator (SNI) according to its length indication field and output.

[0007] Preferably, determining whether the message is a TLS Client Hello message under the TCP protocol includes: Verify the header information of the four-layer protocol to determine whether the four-layer protocol is a TCP protocol; If it is a TCP protocol, the TLS content type field is extracted from a preset position in the payload content, and it is determined whether the TLS content type field is a handshake type; If it is a handshake type, the handshake type field is extracted from the payload content at a preset position adjacent to the TLS content type field, and it is determined whether the handshake type field is of type Client Hello.

[0008] Preferably, parsing the common fields in the payload content includes: Based on the starting position of the payload content, calculate the internal starting offset of the core content of the Client Hello message; Based on the internal starting offset, the version field, random number field, and session identifier field are parsed sequentially; Based on the length of the session identifier field, locate and extract the cipher suite length field; Calculate the end offset of the cipher suite field based on the cipher suite length field; Based on the end offset of the cipher suite field, locate and extract the compression method length field; Based on the compression method length field, calculate the end offset of the compression method field, which is the starting position of the total length field of the extension header.

[0009] Preferably, calculating the starting offset of the first extended header field includes adding the starting position of the total length of the extended header field to the fixed length of the total length of the extended header field itself.

[0010] Preferably, the extended header fields in the payload content are sequentially parsed and matched using the type-length-value format, including: For the current extended header field to be matched, extract the extended type field from its starting offset; Determine whether the value of the extended type field is equal to the preset type value representing the Server Name Indicator (SNI); If not, then extract the extension length field from the extension header field; Based on the starting offset of the current extension header field to be matched, the length of the extension type field, the length of the extension length field, and the value of the extension length field, calculate the starting offset of the next extension header field to be matched; The starting offset of the next extension header field to be matched is used as the new current extension header field to be matched, and the extraction of extension type fields and subsequent steps are repeated.

[0011] Preferably, it further includes a validity determination step: After calculating the starting offset of the next extension header field to be matched, it is compared with the total length of the core content of the Client Hello message in the payload content; If the starting offset of the next header field to be matched is less than the total length, then it is determined that there is a next header field to be matched. If the starting offset of the next header field to be matched is greater than or equal to the total length, then it is determined that all header fields have been traversed.

[0012] Preferably, extracting the server name indication information from the value field of the extended header field of the server name indication based on its length indication field includes, Extract the server name type field and server name length field from the value field of the extended header field indicated by the server name; When the server name type field is a preset type value representing a hostname, a byte sequence of the corresponding length is extracted from the value field as the server name indication information based on the value of the server name length field.

[0013] Preferably, step S4 is implemented in the FPGA hardware logic through an extension header matching module. The extension header matching module receives the starting offset of the current extension header field to be matched and the payload content, and outputs the matching result and the starting offset of the next extension header field to be matched.

[0014] Preferably, it further includes a matching process control step: The selection logic unit is configured to control the initiation and switching of the extension header matching process for different packets based on the matching results output by the extension header matching module. When the matching result indicates that the extended header field indicated by the server name is not matched and there is a next extended header field to be matched, the selection logic unit controls the input of the starting offset of the next extended header field to be matched to the extended header matching module, and starts the next matching for the same message; When the matching result indicates that no extension header field indicated by the server name is matched and there is no next extension header field to be matched, or when the matching result indicates that the extension header field indicated by the server name is matched, the selection logic unit controls the initiation of the extension header matching process for the newly received message.

[0015] This application also provides an electronic device comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the FPGA-based TLS protocol extension SNI extraction method as described above.

[0016] In another aspect, this application provides a storage medium storing computer program instructions that can be executed by a processor to implement the FPGA-based TLS protocol extension SNI extraction method as described above.

[0017] Another aspect of this application provides a computer program product, including a computer program that, when executed by a processor, implements the FPGA-based TLS protocol extension SNI extraction method as described above.

[0018] This application implements TLS protocol extended SNI extraction based on FPGA hardware logic. It achieves precise filtering of target packets through Client Hello message judgment, reducing the number of packets to be processed at the source, significantly reducing the traffic pressure on subsequent parsing modules, and indirectly improving extraction performance. By performing multiple matches on the extended header, it achieves full packet coverage extraction of SNI extended header fields, solving the omission problem of traditional pipelined solutions. Furthermore, it performs targeted matching only on extended header fields, avoiding the high resource consumption and misidentification problems of traditional sliding matching schemes. This method significantly reduces the FPGA logic resource utilization, adapts to the processing requirements of high-speed network packets, and enables parallel processing of multiple packets, resulting in a significant improvement in extraction performance compared to traditional solutions. Simultaneously, the hardware logic design of this method has good scalability, allowing flexible adjustment of parsing and matching rules according to new versions of the TLS protocol. Only the identifier values ​​of some fields and the parsing logic need to be modified to adapt to new protocol versions, meeting the actual needs of network traffic splitting devices for high accuracy, low resource consumption, and high processing performance in SNI information extraction. Attached Figure Description

[0019] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0020] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 A schematic diagram illustrating a method for extracting the TLS protocol extension SNI based on FPGA, provided in an embodiment of this application; Figure 2 This is a schematic diagram of the Client Hello message decision process provided in an embodiment of this application; Figure 3 This is a schematic diagram of the Client Hello message format provided in an embodiment of this application; Figure 4 This is a schematic diagram of a single extended header matching process provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] It should be noted that all user information (including but not limited to user device information, user personal information, object information corresponding to device usage data, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, device usage data, etc.) involved in all embodiments of this application are information and data authorized by the user or fully authorized by all parties.

[0023] This method is applicable to network splitter design, specifically for applications using FPGA (Field-Programmable Gate Array) hardware architecture to extract SNI (Server Name Indicator) information under the TLS (Transport Layer Security) protocol. It is compatible with various network security monitoring and network data splitting hardware systems equipped with FPGA processing units. This FPGA hardware architecture typically needs to support parallel processing of high-speed network packets, possessing basic hardware resources for packet caching, data computation, and logic matching. Hardware logic for parsing layer 2, 3, and 4 protocol headers, judging TLS Client Hello messages, and matching extension headers can be programmed using a hardware description language. This meets the practical requirements of network splitting devices for high accuracy, low logic resource consumption, and high-speed processing of SNI information extraction. It can receive and process network packets conforming to mainstream TLS protocol versions. During the testing phase, functional verification can be completed by sending test data containing TLS packets under the TCP protocol using test instruments. A single TCP segment contains a complete TLS record layer Client Hello message; for cross-segment scenarios, TCP reassembly can be performed by a front-end module.

[0024] For example, all processing steps of this method are implemented through FPGA hardware logic without software intervention. The hardware description language used can be flexibly selected according to the FPGA chip model. The programmed hardware logic can realize pipelined parsing of messages and multiple matching processes of extended headers. Each step is executed sequentially to form a complete SNI information extraction process. The specific implementation method of each step is described in detail below.

[0025] like Figure 1 As shown in the figure, this application discloses a schematic diagram of a method for extracting the TLS protocol extension SNI based on FPGA, including the following method steps: Step S1: Receive network packets, extract the layer 2, 3, and 4 protocol header information of the packets, and calculate and locate the payload content and payload start position of the packets based on the layer 2, 3, and 4 protocol header information. Step S2: Based on the payload content, determine whether the message is a TLS Client Hello message under the TCP protocol; Step S3: If yes, then based on the Client Hello message format of the TLS protocol, parse the common fields in the payload content and calculate the starting offset of the first extended header field; Step S4: Starting from the initial offset of the first extension header field, perform type-length-value format parsing and matching on the extension header fields in the payload content in sequence until an extension header field with extension type Server Name Indicator (SNI) is identified or all extension header fields have been traversed. Step S5: If the extended header field of the Server Name Indicator (SNI) is identified, the Server Name Indicator (SNI) information is extracted from the value field of the extended header field of the Server Name Indicator (SNI) according to its length indication field and output.

[0026] In some embodiments, for step S1, the FPGA hardware logic receives network packets through a preset message input interface. This interface is adaptable to the transmission rates of Gigabit Ethernet and 10 Gigabit Ethernet. The received network packets are temporarily stored in the message buffer module inside the FPGA. The message buffer module adopts first-in-first-out (FIFO) buffer logic to ensure the consistency of the order of message reception and processing. For example, the FPGA hardware logic only reads and parses the first preset byte length of data in each packet. This preset byte length can be configured to meet the requirements of parsing the Layer 2, 3, and 4 protocol headers and the TLS protocol header. The read packet data is transmitted to the header parsing logic unit to perform the parsing operation of the Layer 2, 3, and 4 protocol headers.

[0027] The header parsing logic unit parses the Layer 2, Layer 3, and Layer 4 protocol headers sequentially. It first extracts the content and length information of each field in the Layer 2 protocol header, denoted as the length of the Layer 2 protocol header. Based on the end position of the Layer 2 protocol header, extract the content and length information of each field in the Layer 3 protocol header, and denote the length of the Layer 3 protocol header as... Then, based on the end position of the Layer 3 protocol header, extract the content and length information of each field in the Layer 4 protocol header, and denote the length of the Layer 4 protocol header as... All parsed field content and length information are stored in the FPGA's internal information cache module, enabling high-speed data reading, writing, and subsequent retrieval.

[0028] Based on the length information of the layer 2, 3, and 4 protocol headers, the FPGA hardware logic calculates the starting offset of the message payload using the following formula:

[0029] In the formula, The initial offset of the message payload is set with the starting position of the message as the zero point of the offset. This is the length of the Layer 2 protocol header; This refers to the length of the three-layer protocol header; This is the length of the layer 4 protocol header.

[0030] FPGA hardware logic based on the total length of the message Offset from net load The length of the net load is calculated using the following formula:

[0031] In the formula, The length of the message payload; The total length of the network message; This is the initial offset of the message payload.

[0032] Based on the calculated net load initial offset with net load length The FPGA hardware logic locates and extracts the corresponding payload content from the message cache module, stores the payload location information and payload content information in the information cache module, and stores them in association with the layer 2, 3 and 4 protocol header information.

[0033] In some embodiments, for step S2, the FPGA hardware logic reads the four-layer protocol header information, payload location information, and payload content information from the information cache module, performs a decision operation on the Client Hello message, and filters out non-target messages through precise message filtering, allowing only TLS Client Hello messages under the TCP protocol to enter the subsequent parsing process. This solves the technical problem of traditional extraction schemes not pre-screening messages, resulting in non-target messages occupying a large amount of logic resources and low extraction performance. The principle is that SNI information only exists in TLS Client Hello messages under the TCP protocol. Through multi-layer progressive verification, the target message is accurately identified, reducing the number of messages that need to be processed from the source and indirectly improving the extraction performance of SNI information.

[0034] Please see Figure 2 , Figure 2 This is a schematic diagram of the Client Hello message judgment process provided in this application embodiment. In S201, the FPGA hardware logic reads the protocol type identifier field of the Layer 4 protocol header from the information cache module to determine whether the Layer 4 protocol of the current message is TCP. For example, if the Layer 3 protocol is IP, then when the protocol number field of the Layer 3 protocol header is a preset value, it indicates that the Layer 4 protocol is TCP, and the preset value is the standard identifier value of the TCP protocol. If the verification result is that the Layer 4 protocol is not TCP, then the current message is determined to be a non-target message, and the FPGA hardware logic directly removes the message from the processing flow, while clearing the cached data of the message in the message cache module and the information cache module, releasing on-chip storage resources; if the verification result is that the Layer 4 protocol is TCP, then the subsequent TLS content type field verification step is performed.

[0035] In S202, the TLS Content Type field is extracted from the payload content. The FPGA hardware logic is based on the payload start offset in the information cache module. The TLS content type field is extracted from the payload content. This field is the first byte of the TLS message payload and is a core identification field of the TLS protocol used to identify the type of TLS message. When the value of this field is the preset handshake type identifier value, it indicates that the TLS message is a handshake type message. If the value of this field is not the handshake type identifier value, the current message is determined to be a non-target message, and the FPGA hardware logic removes it from the processing flow and clears the relevant cached data. If the value of this field is the handshake type identifier value, the subsequent handshake type field verification step is performed.

[0036] In S203, after confirming that the TLS message is a handshake type message, the FPGA hardware logic extracts the handshake type field from the payload content. This field, located at a preset position after the TLS content type field, is a unique identifier field for Client Hello messages. When the value of this field is the preset Client Hello type identifier value, it indicates that the handshake message is a Client Hello message, i.e., a handshake request message sent by the client to the server; if the value of this field is not the Client Hello type identifier value, the current message is determined to be a non-target message, and the FPGA hardware logic removes it from the processing flow and clears the relevant cached data.

[0037] If all three verification steps above pass, the FPGA hardware logic determines that the current message is the target message from which SNI information needs to be extracted, marks the message's identification information as the target message, and separately stores the message's layer 2, 3, and 4 protocol header information, payload location information, and payload content information from the information cache module. Then, it outputs all relevant information of the target message to the subsequent Client Hello public field parsing step.

[0038] In some embodiments, after completing the Client Hello message decision, the FPGA hardware logic can periodically clean up the information cache module, remove all data related to non-target messages, further release on-chip storage resources, improve the resource utilization of the FPGA hardware system, and ensure that no resource overflow occurs during high-speed network message processing.

[0039] In some embodiments, for step S3, if the message determination result is a TLS Client Hello message under the TCP protocol, the FPGA hardware logic reads the payload location information and payload content information of the target message from the information cache module. Based on the Client Hello message format of the TLS protocol, it performs pipelined parsing on the common fields in the payload content. This parsing method ensures the parsing speed of the common fields, so that the extension header matching only needs to be performed on the extension header fields, rather than processing the entire message data, thus reducing the amount of data processing. Figure 3 As shown, Figure 3 This is a schematic diagram of the Client Hello message format provided in an embodiment of this application.

[0040] Based on the starting position of the payload content, calculate the internal starting offset of the core content of the Client Hello message. This internal starting offset is the offset position after skipping the Content Type, Protocol Version, and Length fields in the TLS packet payload, and the calculation formula is as follows:

[0041] In the formula, The internal starting offset of the core content of the Client Hello message, with the starting position of the payload as the offset zero point; The length of the Content Type field; The length of the ProtocolVersion field; This is the length of the Length field.

[0042] Starting with this internal offset Using the baseline offset, the FPGA hardware logic parses the common fields of the Client Hello message sequentially. First, it parses the version field, random number field, and session identifier field, extracting the length and content information of each field. Based on the length information of each field, it calculates the end offset of the session identifier field, which is the starting offset of the cipher suite length field.

[0043] The FPGA hardware logic extracts the value of the cipher suite length field from the payload content based on the start offset of the cipher suite length field, and calculates the end offset of the cipher suite field based on this value. This end offset is the start offset of the compression method length field. Then, based on the start offset of the compression method length field, it extracts the value of the compression method length field, and calculates the end offset of the compression method field based on this value. This end offset of the compression method field is the starting position of the total length field of the extension header, denoted as […]. .

[0044] The FPGA hardware logic calculates the starting offset of the first expansion head field based on the starting position of the total length field of the expansion head. Since the total length field is a fixed-length field, the starting offset of the first expansion head field is obtained by adding its fixed length to the starting position of the total length field. The calculation formula is as follows:

[0045] In the formula, The starting offset for the first extended header field is based on the internal starting offset of the core content of the Client Hello message; This is the starting position of the total length field of the extended header; This is a fixed length for the total length field of the extended header.

[0046] The FPGA hardware logic stores the offset and length information of all parsed common fields into the information cache module, and sets the starting offset of the first extended header field. As the core parsing result, the total length of the core content of the ClientHello message is also included. Synchronous output.

[0047] In some embodiments, for step S4, the FPGA hardware logic receives the starting offset of the first extended header field from the Client Hello common field parsing step. The core content and total length of the Client Hello message Starting from the initial offset of the first extension header field, the extension header fields in the payload content are sequentially parsed and matched in TLV (Type-Length-Value) format. This embodiment solves the problem of SNI information omission caused by the fixed number of extension headers parsed in the traditional pipeline extraction scheme, as well as the technical problems of large logic resource consumption and easy misidentification in the traditional full-packet sliding matching scheme. Its principle is to perform targeted parsing and matching of each extension header field according to the extension header TLV format specification of the TLS protocol. By performing multiple matching, all extension header fields are traversed, which not only ensures full message coverage of SNI information extraction, but also only performs matching processing on extension header fields, which greatly reduces the number of matching operations, reduces the consumption of FPGA logic resources, and improves the accuracy of matching.

[0048] The input to the extended header matching module is the starting offset of the extended header field to be matched. Core content of the Client Hello message; Total length of the core content of the Client Hello message The output is the matching result. The starting offset of the next extension header field to be matched. The matching results It includes three states: matching an SNI header field, not matching an SNI header field but having another header field to match, and not matching an SNI header field and having traversed all header fields. The starting offset of the next header field to match is also included. This is only valid if the matching result is in the second state.

[0049] Please see Figure 4 , Figure 4This is a schematic diagram of a single extension header matching process provided in an embodiment of this application. In S401, a single extension header matching is performed. In one embodiment, the FPGA hardware logic sets the starting offset of the first extension header field... The starting offset of the current header field to be matched as the first match The input is sent to the header matching module to perform a single header matching operation. The single matching strictly follows the TLV format specification of the TLS protocol header.

[0050] The FPGA hardware logic is based on the starting offset of the current extension header field to be matched. Extract the extended type field from the core content of the ClientHello message. This field is a 2-byte unsigned integer and serves as the type identifier for the extended header field, denoted as [insert field name here]. ,when When the value is a preset SNI type identifier value, it indicates that the extension header field is an SNI extension header field.

[0051] The extended header matching module matches extended type fields. The values ​​are matched and judged. If If the match is equal to the preset SNI type identifier value, then it is determined that an SNI extension header field has been matched, and the matching result is... Marking a match in the SNI extension header field, the extension header matching module stops offset calculation and sends a successful match signal to subsequent information extraction and output steps; if If the value is not equal to the preset SNI type identifier value, it is determined that no SNI extension header field was matched this time, and the process proceeds to the offset calculation step of the next extension header field to be matched.

[0052] The extended header matching module extracts the extended length field from the core content of the Client Hello message. This field, located after the extended type field, is a 2-byte unsigned integer, denoted as . , indicates the length of the current extended header field value field.

[0053] The header matching module calculates the total length of the current header field according to the TLV format specification, and then determines the length based on the starting offset of the header field to be matched. Calculate the starting offset of the next extended header field to be matched, using the following formula:

[0054] In the formula, The starting offset for the next extended header field to be matched is based on the internal starting offset of the core content of the Client Hello message; 2 represents the starting offset of the current extended header field to be matched; 2 represents the fixed length of the extended type field; 2 represents the fixed length of the extended length field; This is the value for the extended length field.

[0055] The extended header matching module performs a validity check step, calculating the starting offset of the next extended header field to be matched. Total length of the core content of the Client Hello message If a comparison is made, If the current message contains a new header field to be matched, then the matching result is determined. Mark as no matching SNI header field found but a next header field to be matched exists, and adjust the starting offset of the next header field to be matched. As a valid output; if If the current message has traversed all extended header fields, then it is determined that the matching result is... The starting offset of the next unmatched SNI header field after all header fields have been traversed. Invalid output.

[0056] In S402, the process control involves multiple matching operations. When the extended header matching module performs a single matching operation, there is a fixed clock delay. For example, this clock delay is 5 FPGA clock cycles, meaning it takes 5 clock cycles from the start offset of the input extended header field to the output matching result. The FPGA hardware logic setting selection logic unit fully considers this clock delay and adjusts the matching result output by the extended header matching module accordingly. The corresponding flow control operations are executed to achieve parallel processing of multiple messages and multiple loop matching of a single message. The specific control rules are as follows: If no matching result is returned under the current clock, it means the extended header matching module is still performing a single matching operation and has not output a matching result. If the selected logic unit controls the start of the extended header matching process for the next message, the first matching operation will be performed on other subsequently received Client Hello messages. This rule can realize parallel processing of multiple messages and improve the overall SNI information extraction efficiency.

[0057] If a matching result is returned under the current clock, and the matching result... If no SNI extension header field is matched and all extension header fields have been traversed, the selected logic unit controls the start of the extension header matching process for the next message. At the same time, the identification information of the current message is marked as having no SNI information and stored in the information cache module. This result can be directly output later.

[0058] If a matching result is returned under the current clock, and the matching result... If no SNI extension header field is matched but a next extension header field exists to be matched, the selection logic unit controls the starting offset of the next extension header field to be matched output by the extension header matching module. As the starting offset of the new current header field to be matched The input is sent to the header matching module, which initiates the next header matching operation for the current message until the SNI header field is matched or all header fields have been traversed.

[0059] In some embodiments, the FPGA hardware logic can parallelize the header matching module, building multiple independent header matching sub-modules within the FPGA chip. Each sub-module can independently perform TLV format parsing and matching operations for the header, and the hardware logic of each sub-module is independent and does not interfere with each other. This parallel design can perform multiple matching operations on multiple Client Hello messages simultaneously, with each message corresponding to an independent header matching sub-module, further enhancing the FPGA hardware system's ability to process high-speed network messages and adapting to gigabit and 10-gigabit high-speed network transmission scenarios. Simultaneously, the logic resource consumption of this parallel design is significantly lower than that of the parallel design of traditional full-packet sliding matching schemes.

[0060] Through the above-described multiple matching process, for Client Hello messages with any number of extended header fields, the FPGA hardware logic can accurately identify the SNI extended header fields through one or more matching operations. If the SNI extended header field appears at the position of the Nth extended header field, the FPGA hardware logic will perform N matching operations until the SNI extended header field is identified in the Nth matching operation. This method does not require a fixed number of extended header fields to be parsed and can achieve full message coverage extraction of SNI extended header fields, completely solving the problem of missed extraction in traditional pipeline extraction schemes.

[0061] In some embodiments, for step S5, if the SNI extension header field is identified in the multiple extension header matching steps, the FPGA hardware logic receives a matching success signal from the extension header matching module, extracts the SNI information from the value field of the extension header field based on the TLS protocol SNI extension header field format, and completes the information format conversion and output according to the requirements of the subsequent module; if the SNI extension header field is not matched after traversing all extension header fields in the multiple extension header matching steps, the FPGA hardware logic directly outputs the result that the current message has no SNI information.

[0062] Specifically, the FPGA hardware logic extracts the Server Name Type field and Server Name Length field sequentially from the value field of the SNI extension header. The Server Name Type field is a 1-byte unsigned integer, which identifies the SNI information type. When this field's value is a preset hostname identifier, it indicates that the subsequent byte sequence contains the server hostname that the client needs to connect to, i.e., the core SNI information to be extracted. The Server Name Length field is a 2-byte unsigned integer, denoted as... , indicating the byte length of the SNI core information.

[0063] When the server name type field takes the value of a preset hostname identifier, the FPGA hardware logic determines the value based on the server name length field. Extract subsequent values ​​from the value field of the SNI extension header field. The content consists of 1 byte, which is the SNI information. The FPGA hardware logic stores the extracted SNI information in a dedicated SNI information cache module. This module is a high-speed on-chip storage module of the FPGA, which can ensure the complete storage and high-speed reading of the SNI information.

[0064] The FPGA hardware logic converts the SNI information stored in the SNI information cache module and adjusts the information output format according to the requirements of the subsequent processing module. For example, the subsequent module is the packet processing module of the network traffic splitting device, which requires the output format of source IP address + destination IP address + SNI information. The FPGA hardware logic reads the source IP address and destination IP address of the current packet from the information cache module and concatenates them with the extracted SNI information to form the output data that meets the requirements of the subsequent module.

[0065] The FPGA hardware logic outputs the converted SNI information or the result without SNI information to the subsequent processing module through a preset output interface. This output interface can be adapted to the communication protocol of the subsequent module to realize high-speed, real-time data transmission. The transmission rate of the output interface matches the message processing rate of the preceding steps to ensure the consistency of the rate of the entire SNI information extraction process.

[0066] After outputting SNI information or no SNI information result, the FPGA hardware logic immediately clears all cached data of the current message in the message cache module, information cache module, and SNI information cache module, releasing the FPGA's on-chip storage resources and hardware logic resources, providing resource guarantee for subsequent network message processing, and ensuring that the FPGA hardware system can continuously and efficiently perform SNI information extraction operations.

[0067] This method extracts the TLS protocol extended SNI based on FPGA hardware logic. It achieves precise filtering of target packets through Client Hello message judgment, reducing the number of packets to be processed at the source, significantly reducing the traffic pressure on subsequent parsing modules, and indirectly improving extraction performance. By performing multiple matches on the extended header, it achieves full packet coverage extraction of the SNI extended header fields, solving the omission problem of traditional pipelined solutions. Furthermore, it performs targeted matching only on the extended header fields, avoiding the high resource consumption and misidentification problems of traditional sliding matching schemes. This method significantly reduces the FPGA logic resource utilization, adapts to the processing requirements of high-speed network packets, and enables parallel processing of multiple packets, resulting in a significant improvement in extraction performance compared to traditional solutions. Simultaneously, the hardware logic design of this method has good scalability, allowing flexible adjustment of parsing and matching rules according to new versions of the TLS protocol. Only the identifier values ​​of some fields and the parsing logic need to be modified to adapt to new protocol versions, meeting the actual needs of network traffic splitting devices for high accuracy, low resource consumption, and high processing performance in SNI information extraction.

[0068] It should be noted that although the operations of the method of this application are described in a specific order in the accompanying drawings, this does not require or imply that these operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. On the contrary, the steps depicted in the flowchart can be performed in a different order. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0069] Based on the same inventive concept, this application also provides an electronic device. The method corresponding to the electronic device can be the method in the foregoing embodiments, and its problem-solving principle is similar to that method. The device provided in this application includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the methods and / or technical solutions of the foregoing embodiments of this application.

[0070] Figure 5The diagram illustrates the structure of an electronic device suitable for implementing the methods and / or technical solutions in the embodiments of this application. The device includes a central processing unit (CPU) 501, which can perform various appropriate actions and processes based on a program stored in a read-only memory (ROM) 502 or a program loaded from a storage section 508 into a random access memory (RAM) 503. The RAM 503 also stores various programs and data required for system operation. The CPU 501, ROM 502, and RAM 503 are interconnected via a bus 504. An input section 506, an output section 507, a communication section 509, and an input / output (I / O) interface 505 are also connected to the bus 504.

[0071] In particular, the methods and / or embodiments in this application can be implemented as computer software programs. For example, the embodiments disclosed in this application include a computer program product comprising a computer program carried on a storage medium, the computer program containing program code for performing the methods shown in the flowchart. When the computer program is executed by the central processing unit (CPU) 501, it performs the functions defined in the methods of this application.

[0072] Another embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which can be executed by a processor to implement the methods and / or technical solutions of any one or more embodiments of this application described above.

[0073] The flowcharts or block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-specific system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

Claims

1. A method for extracting the TLS protocol extension SNI based on FPGA, characterized in that, Includes the following steps: Step S1: Receive network packets, extract the layer 2, 3, and 4 protocol header information of the packets, and calculate and locate the payload content and payload start position of the packets based on the layer 2, 3, and 4 protocol header information. Step S2: Based on the payload content, determine whether the message is a TLS Client Hello message under the TCP protocol; Step S3: If yes, then based on the TLS Client Hello message format, parse the common fields in the payload content and calculate the starting offset of the first extended header field; Step S4: Starting from the initial offset of the first extension header field, perform type-length-value format parsing and matching on the extension header fields in the payload content in sequence until an extension header field with extension type Server Name Indicator (SNI) is identified or all extension header fields have been traversed. Step S5: If the extended header field of the Server Name Indicator (SNI) is identified, the Server Name Indicator (SNI) information is extracted from the value field of the extended header field of the Server Name Indicator (SNI) according to its length indication field and output.

2. The method for extracting the TLS protocol extension SNI based on FPGA according to claim 1, characterized in that, Determining whether the message is a TLS Client Hello message under the TCP protocol includes: Verify the header information of the four-layer protocol to determine whether the four-layer protocol is a TCP protocol; If it is a TCP protocol, the TLS content type field is extracted from a preset position in the payload content, and it is determined whether the TLS content type field is a handshake type; If it is a handshake type, the handshake type field is extracted from the payload content at a preset position adjacent to the TLS content type field, and it is determined whether the handshake type field is of type Client Hello.

3. The method for extracting the TLS protocol extension SNI based on FPGA according to claim 1, characterized in that, Parsing the common fields in the payload content includes: Based on the starting position of the payload content, calculate the internal starting offset of the core content of the Client Hello message; Based on the internal starting offset, the version field, random number field, and session identifier field are parsed sequentially; Based on the length of the session identifier field, locate and extract the cipher suite length field; Calculate the end offset of the cipher suite field based on the cipher suite length field; Based on the end offset of the cipher suite field, locate and extract the compression method length field; Based on the compression method length field, calculate the end offset of the compression method field, which is the starting position of the total length field of the extension header.

4. The method for extracting the TLS protocol extension SNI based on FPGA according to claim 3, characterized in that, The calculation of the starting offset of the first extended header field includes adding the starting position of the total length of the extended header field to the fixed length of the total length of the extended header field itself.

5. The method for extracting the TLS protocol extension SNI based on FPGA according to claim 1, characterized in that, The extended header fields in the payload content are parsed and matched sequentially using the type-length-value format, including... For the current extended header field to be matched, extract the extended type field from its starting offset; Determine whether the value of the extended type field is equal to the preset type value representing the Server Name Indicator (SNI); If not, then extract the extension length field from the extension header field; Based on the starting offset of the current extension header field to be matched, the length of the extension type field, the length of the extension length field, and the value of the extension length field, calculate the starting offset of the next extension header field to be matched; The starting offset of the next extension header field to be matched is used as the new current extension header field to be matched, and the extraction of extension type fields and subsequent steps are repeated.

6. The method for extracting the TLS protocol extension SNI based on FPGA according to claim 5, characterized in that, It also includes a validity assessment step: After calculating the starting offset of the next extension header field to be matched, it is compared with the total length of the core content of the Client Hello message in the payload content; If the starting offset of the next header field to be matched is less than the total length, then it is determined that there is a next header field to be matched. If the starting offset of the next header field to be matched is greater than or equal to the total length, then it is determined that all header fields have been traversed.

7. The method for extracting the TLS protocol extension SNI based on FPGA according to claim 1, characterized in that, Extracting server name indication information from the value field of the extended header field of the server name indication based on its length indication field includes: Extract the server name type field and server name length field from the value field of the extended header field indicated by the server name; When the server name type field is a preset type value representing a hostname, a byte sequence of the corresponding length is extracted from the value field as the server name indication information based on the value of the server name length field.

8. The method for extracting the TLS protocol extension SNI based on FPGA according to claim 1, characterized in that, Step S4 is implemented in the FPGA hardware logic through an extension header matching module. The extension header matching module receives the starting offset of the current extension header field to be matched and the payload content, and outputs the matching result and the starting offset of the next extension header field to be matched.

9. The method for extracting the TLS protocol extension SNI based on FPGA according to claim 8, characterized in that, It also includes matching process control steps: The selection logic unit is configured to control the initiation and switching of the extension header matching process for different packets based on the matching results output by the extension header matching module. When the matching result indicates that the extended header field indicated by the server name is not matched and there is a next extended header field to be matched, the selection logic unit controls the input of the starting offset of the next extended header field to be matched to the extended header matching module, and starts the next matching for the same message; When the matching result indicates that no extension header field indicated by the server name is matched and there is no next extension header field to be matched, or when the matching result indicates that the extension header field indicated by the server name is matched, the selection logic unit controls the initiation of the extension header matching process for the newly received message.

10. An electronic device, characterized in that, include: At least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the method of any one of claims 1-9.

Images