A TLS protocol fingerprint steganography construction method and system based on multi-dimensional feature mapping

Abstract

The application relates to the field of TLS fingerprint metamorphic construction, in particular to a TLS protocol fingerprint metamorphic construction method and system based on multi-dimensional feature mapping. The method comprises the following steps: acquiring a target connection scene feature set and a local protocol stack capability feature set, performing scene adaptability screening based on the target connection scene feature set and the local protocol stack capability feature set in combination with a pre-constructed multi-dimensional feature fingerprint image library, generating a candidate fingerprint image set, performing dynamic selection and consistency constraint checking of a target image based on the candidate fingerprint image set, generating a target fingerprint image adapted to a current connection scene, driving TLS handshake metamorphic construction based on the target fingerprint image, iteratively updating the multi-dimensional feature fingerprint image library based on a handshake result, and generating a fingerprint metamorphic construction report. In the TLS fingerprint metamorphic construction process, the fingerprint camouflage is highly consistent with the connection context and the behavior logic is self-consistent, so that the concealment and the connection success rate are greatly improved.

Description

Technical Field

[0001] This application relates to the field of TLS fingerprint mimicry construction, and in particular to a method and system for constructing TLS protocol fingerprint mimicry based on multidimensional feature mapping. Background Technology

[0002] In the field of network security and proactive defense, the TLS (Transport Layer Security) protocol has become the cornerstone for ensuring the privacy and integrity of Internet communications. Its mimicry construction technology of connection fingerprints is a key means to improve the success rate of advanced tasks such as penetration testing, covert communication, and adversarial cyberspace mapping. It is directly related to the stealth of adversarial detection, the stability of resource access, and the effectiveness of tactical operations.

[0003] However, existing TLS fingerprint construction methods mostly adopt static or random strategies, lacking intelligent comprehensive judgment and dynamic adaptation mechanisms for target environment, session state and historical experience. This not only makes it difficult to maintain a long-term stable and reliable connection in complex and ever-changing adversarial scenarios, but may also trigger security alarms of the target system due to inconsistencies or frequent switching of fingerprint features, leading to connection interruption or even identity exposure, thus posing significant operational risks and tactical shortcomings. Summary of the Invention

[0004] This application provides a method and system for constructing TLS protocol fingerprint mimicry based on multidimensional feature mapping to solve the above-mentioned technical problems.

[0005] Firstly, this application provides a method for constructing TLS protocol fingerprint mimicry based on multi-dimensional feature mapping, the method comprising:

[0006] The system acquires a target connection scenario feature set and a local protocol stack capability feature set. Based on these features and a pre-built multi-dimensional feature fingerprint profile library, it performs scenario adaptability screening to generate a candidate fingerprint profile set. Based on this candidate fingerprint profile set, it performs dynamic selection and consistency constraint verification of the target profile to generate a target fingerprint profile adapted to the current connection scenario. Based on the target fingerprint profile, it drives the TLS handshake mimicry construction and iteratively updates the multi-dimensional feature fingerprint profile library based on the handshake results, generating a fingerprint mimicry construction report.

[0007] Through the above technical solutions, by using scenario-based screening and dual consistency verification, the fingerprint spoofing is highly consistent with the connection context and the behavioral logic is self-consistent, which greatly improves the concealment and connection success rate. Its "construction-learning" closed loop allows the system to accumulate experience from each interaction, realize the continuous self-evolution of the fingerprint strategy, and enhance the adaptability and intelligence level of long-term confrontation.

[0008] Optionally, the process of generating the candidate fingerprint profile set includes: extracting target-side features and network features based on the target connection scenario feature set, performing matching analysis with the scenario applicable label set associated with each fingerprint profile in the pre-built multi-dimensional feature fingerprint profile library, and filtering out a preliminary label-matching profile set; performing feasibility verification on the preliminary label-matching profile set based on the local protocol stack capability feature set, removing profiles that contain fingerprint features that are not supported or uncontrollable by the local protocol stack, and generating the candidate fingerprint profile set.

[0009] Optionally, the construction process of the pre-built multi-dimensional feature fingerprint profile library includes: constructing a fingerprint profile object for each simulable TLS client entity, wherein each fingerprint profile object contains a static fingerprint feature set, a scenario-applicable tag set, and a compatibility constraint set; wherein the static fingerprint feature set defines the protocol version, cipher suite list and its order, extension list and its internal data required to construct the ClientHello message; the scenario-applicable tag set is used to describe the network and target environment characteristics applicable to the fingerprint profile object; the compatibility constraint set defines the protocol stack capabilities and business logic prerequisites required to use the fingerprint profile object; and organizing the fingerprint profile objects according to the hierarchy of main profile and variant profiles, wherein the variant profile is formed by recording the difference between it and the corresponding main profile on the static fingerprint feature set, in order to characterize subtle fingerprint variants under the same client category.

[0010] Optionally, the feasibility verification includes: for each set of preliminary label-matching profiles, extracting the fingerprint construction parameters defined by its static fingerprint feature set, and comparing and analyzing them one by one with the list of controllable field capabilities of the local protocol stack; identifying and marking the fingerprint construction parameters that the local protocol stack cannot accurately implement; if there is any fingerprint construction parameter marked as not being accurately implemented, and there is no preset equivalent replacement strategy, then this fingerprint profile is removed from the set of candidate fingerprint profiles.

[0011] Optionally, the process of generating the target fingerprint profile includes: calculating a comprehensive selection score for each fingerprint profile in the candidate fingerprint profile set, the comprehensive selection score including historical performance score, scenario matching score, and profile switching cost score; sorting the candidate profiles in the candidate fingerprint profile set based on the comprehensive selection score, and sequentially performing session consistency verification and destination consistency verification on a predetermined number of the top-ranked candidate profiles; the session consistency verification is used to prevent switching of fingerprint profiles within the same TLS session, and the destination consistency verification is used to ensure the stability of fingerprint profiles and minimize switching within the same destination policy domain; and selecting the candidate profile that passes the verification and has the highest score as the target fingerprint profile.

[0012] Optionally, the session consistency verification includes: before initiating a new TLS connection, checking whether there is a valid active TLS session with the same target server; if so, directly extracting fingerprint features from the historical fingerprint profile bound to the active TLS session for this connection construction, and ignoring the candidate fingerprint profile set and its selection and scoring process.

[0013] Optionally, the destination-side consistency verification includes: mapping the destination-side information of the current connection to a preset policy domain identifier, querying whether there is a fingerprint profile record that has been recently determined and successfully used under the policy domain identifier; if there is, then the fingerprint profile in the fingerprint profile record is used as a strong constraint for this selection, restricting the candidate fingerprint profile set to only include profile variants that are the same as this profile record or have a preset compatibility relationship.

[0014] Optionally, the process of generating the fingerprint mimicry construction report includes: recording the final fingerprint profile used in each TLS handshake, the corresponding target connection scenario feature set, and handshake result information; the handshake result information is classified into success and negotiation failure: for successful handshakes, updating the average handshake latency statistics and success rate statistics of the corresponding fingerprint profile in the matching scenario; for negotiation failures, highlighting the association between the fingerprint profile and the protocol or suite incompatibility information returned by the peer service in this connection; based on the handshake result information, updating the historical performance statistics of the corresponding fingerprint profile in the multi-dimensional feature fingerprint profile library, the historical performance statistics including handshake success rate, average handshake latency, and failure association information; when the handshake fails, executing a fallback mechanism and updating the weight of the relevant fingerprint profile according to the fallback result; and generating the fingerprint mimicry construction report based on the recorded and updated statistical results.

[0015] Optionally, the execution fallback mechanism includes: when a handshake failure based on the target fingerprint profile is detected, automatically selecting the next candidate fingerprint profile according to a predefined or dynamically associated fallback chain; re-initiating the TLS handshake connection based on the candidate fingerprint profile, and repeating this process until the handshake succeeds or the fallback chain is exhausted.

[0016] Secondly, this application provides a TLS protocol fingerprint mimicry construction system based on multi-dimensional feature mapping, the system comprising:

[0017] The candidate fingerprint profile module is used to acquire the target connection scenario feature set and the local protocol stack capability feature set. Based on the target connection scenario feature set and the local protocol stack capability feature set, combined with a pre-built multi-dimensional feature fingerprint profile library, scenario adaptability screening is performed to generate a candidate fingerprint profile set. The target fingerprint profile module is used to perform dynamic selection and consistency constraint verification of the target profile based on the candidate fingerprint profile set to generate a target fingerprint profile adapted to the current connection scenario. The fingerprint construction report module is used to drive TLS handshake mimicry construction based on the target fingerprint profile and iteratively update the multi-dimensional feature fingerprint profile library based on the handshake result to generate a fingerprint mimicry construction report. Attached Figure Description

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

[0019] Figure 1 This is a schematic diagram illustrating an application scenario provided in one embodiment of this application;

[0020] Figure 2 A flowchart illustrating a TLS protocol fingerprint mimicry construction method based on multidimensional feature mapping, provided as an embodiment of this application;

[0021] Figure 3 This is a schematic diagram of a TLS protocol fingerprint mimicry construction system based on multidimensional feature mapping, provided as an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, 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, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0023] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0024] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0025] Existing TLS fingerprint construction methods mostly employ static or random strategies, lacking intelligent comprehensive judgment and dynamic adaptation mechanisms for target environment, session state, and historical experience. This not only makes it difficult to maintain a long-term stable and reliable connection in complex and ever-changing adversarial scenarios, but may also trigger security alarms in the target system due to inconsistencies or frequent switching of fingerprint features, leading to connection interruption or even identity exposure, thus posing significant operational risks and tactical shortcomings.

[0026] Based on this, this application provides a method and system for constructing TLS protocol fingerprint mimicry based on multi-dimensional feature mapping. First, combining the specific scenario of the current connection (such as the target service type) and local system capabilities, a logically reasonable set of candidate fingerprints is intelligently selected from a pre-built fingerprint database. Next, a target fingerprint is initially selected from the candidate set through dynamic scoring, and a dual verification of "fingerprint invariance within the same session" and "fingerprint stability at the same service provider" is enforced to ensure realistic behavior. Finally, the final fingerprint is used to perform a TLS handshake, and the scoring weights of the fingerprint database are automatically updated based on the success or failure result. A retry mechanism for automatically switching to a backup fingerprint after failure is introduced, and a report is output to the user. This solution, through scenario-based filtering and dual consistency verification, makes the fingerprint masquerading highly consistent with the connection context and its behavioral logic self-consistent, greatly improving concealment and connection success rate. Its "construction-learning" closed loop allows the system to accumulate experience from each interaction, achieving continuous self-evolution of the fingerprint strategy and enhancing its adaptability and intelligence level in long-term adversarial situations.

[0027] Figure 1 This is a schematic diagram illustrating an application scenario provided by this application. In the TLS fingerprint mimicry construction process, this application applies the method provided herein, enabling the fingerprint spoofing to closely match the connection context and exhibit self-consistent behavioral logic, greatly improving concealment and connection success rate.

[0028] Specifically, the method of this application is applied to any server that communicates with the network detection system and the local operating system, and obtains the target connection scenario feature set provided by the network detection system and the local protocol stack capability feature set provided by the local operating system through the server.

[0029] For specific implementation details, please refer to the following examples.

[0030] Figure 2 This is a flowchart illustrating a TLS protocol fingerprint mimicry construction method based on multi-dimensional feature mapping, as provided in one embodiment of this application. The method of this embodiment can be applied to servers in the above scenarios. Figure 2 As shown, the method includes:

[0031] S201. Obtain the target connection scenario feature set and the local protocol stack capability feature set. Based on the target connection scenario feature set and the local protocol stack capability feature set, and combined with the pre-built multi-dimensional feature fingerprint profile library, perform scenario adaptability screening and generate a candidate fingerprint profile set.

[0032] The target connection scenario feature set can be a multi-dimensional feature data set describing the specific context of this TLS connection. This feature set typically covers three levels: destination-side features, client environment features, and policy intent features. The data originates from a network probing system. The local protocol stack capability feature set can refer to the feature set of the actual TLS protocol capabilities supported by the client system running this method. The data originates from the local operating system. The multi-dimensional feature fingerprint profile library can be a pre-built and maintained structured fingerprint feature database. Each "fingerprint profile" is a complete description of the observable feature set presented by a specific client software (such as Chrome 120 or iOS Safari 17) during the TLS handshake phase. The candidate fingerprint profile set can be a set containing multiple candidate fingerprint profiles that has undergone preliminary screening. It originates from the output of the "pre-built multi-dimensional feature fingerprint profile library" after "scenario adaptability screening." Each fingerprint profile in this set initially meets the basic logical requirements of the current connection scenario (e.g., matching the target service type and being compatible with the local environment) and awaits final evaluation.

[0033] Specifically, the core challenge of TLS fingerprint mimicry technology lies in the fact that even the most realistic, isolated, static fingerprint will behave abnormally and be easily detected if applied to an inappropriate connection scenario. For example, using a typical "Windows enterprise browser" fingerprint to connect to an API server usually only accessed by "mobile social applications" would trigger a security system's alarm due to this context mismatch. Existing technologies mostly focus on the sophisticated forgery or random rotation of the fingerprint itself, but lack a mechanism to deeply and dynamically correlate fingerprint selection with the context of the specific connection task, resulting in "mimicry for the sake of mimicry," which is exposed due to illogical behavior. This step aims to solve this fundamental problem. By systematically collecting and analyzing the "target connection scenario feature set," we construct a dynamic, multi-dimensional contextual profile for each connection; combined with the "local protocol stack capability feature set," we ensure that the selected mimicry scheme is technically feasible. Building upon this foundation, the matching process with the "pre-built multi-dimensional feature fingerprint profile library" involves more than simple random selection. Instead, it employs a scenario-adaptability screening process: based on the destination characteristics of the current connection (such as the target service type), fingerprint profiles frequently observed within that service category are selected; based on client environment characteristics, fingerprint profiles logically compatible with the current host environment are selected (e.g., avoiding the use of macOS-only browser fingerprints on Linux servers); and finally, the selected profiles are prioritized based on policy intent characteristics. This ensures that the subsequent selection process unfolds within a high-quality candidate pool that is both logically consistent with the context and technically feasible, laying a solid foundation for the reliability and concealment of the entire mimicry process.

[0034] S202. Based on the candidate fingerprint profile set, perform dynamic selection and consistency constraint verification of the target profile to generate a target fingerprint profile that is adapted to the current connection scenario.

[0035] Dynamic selection of the target fingerprint profile can be the process of selecting the optimal fingerprint for this connection construction from the candidate fingerprint profile set based on real-time calculation or a predefined scoring model. Consistency constraint verification can be a set of mandatory logical checks applied during the dynamic selection process or after the initial target is determined. These checks aim to ensure that the selected fingerprint application does not violate the client's expected stable behavior pattern, primarily including session consistency verification and destination-side consistency verification. The target fingerprint profile can be a specific fingerprint profile that is ultimately selected and used for this TLS connection construction. It originates from the unique result determined after "dynamic selection and consistency constraint verification" of the "candidate fingerprint profile set," and serves as the final and specific instruction blueprint guiding the TLS handshake mimicry construction.

[0036] Specifically, even after scenario-adaptability screening, the candidate set may still contain multiple seemingly reasonable fingerprints. Simple random selection or fixed priority selection cannot cope with complex and ever-changing network environments, nor can it fully utilize historical experience. Dynamic selection mechanisms use a scoring model that incorporates multiple factors (such as the historical success rate of the profile in similar scenarios, handshake performance overhead, fit with the current local protocol stack capabilities, and simulated resource consumption) to calculate a dynamic score for each candidate profile, thereby achieving intelligent selection based on real-time "value judgment." However, dynamic selection alone is insufficient. In real network interactions, a legitimate client's fingerprint characteristics are highly stable over a short period, especially within a single TCP / TLS session or when facing the same service provider. Some existing dynamic solutions frequently switch fingerprints in pursuit of change, creating the biggest behavioral vulnerability—a "client" repeatedly connecting to the same service with different fingerprints within minutes is tantamount to self-declaring itself an automated script or attack tool. Therefore, consistency constraint verification is introduced as a crucial security gate. It includes two key checks: First, session consistency check: Before initiating a connection, it enforces a check to see if a valid TLS session with the same target server already exists. If so, the fingerprint used when that session was established must be used, completely skipping the dynamic selection process. This simulates the behavior of a real client when resuming a session, avoiding the technical anomalies and risks of fingerprint mutations within the same session. Second, destination-side consistency check: It maps the target server to a broader "policy domain" (such as the same company or the same cloud service) and queries for fingerprint records that have been successfully used recently within that domain. If found, it mandates that this selection must be based on that historical fingerprint or a compatible variant. This simulates the user's habit of accessing a specific service using a single or a few clients, preventing "split personality" fingerprints from appearing on the same service provider. These two checks, as strong constraints, add the necessary "stability" constraint to the "flexibility" of dynamic selection, ensuring realistic behavior.

[0037] S203. Based on the target fingerprint profile, drive the TLS handshake mimicry construction, and iteratively update the multi-dimensional feature fingerprint profile library based on the handshake results to generate a fingerprint mimicry construction report.

[0038] Driving a TLS handshake mimicry involves using a selected target fingerprint profile to precisely construct and send a matching ClientHello message during the actual TLS handshake negotiation process, and handling subsequent handshake procedures to establish an encrypted connection. A fingerprint mimicry construction report is a summary document generated after each or batch of mimicry construction processes, containing key operations, decision-making basis, result statistics, and anomalies.

[0039] Specifically, after selecting the target fingerprint profile, the key lies in precise execution. Driving the TLS handshake mimicry construction means hooking or rewriting the function in the local TLS library that constructs the ClientHello message, filling in the protocol version, cipher suite list, extension list, and their respective contents according to the detailed specifications of the target profile (accurate to byte order). This step ensures that it "sounds exactly like the target." However, an advanced mimicry system must not be "open-loop." Network environments and server policies are constantly changing; a fingerprint that is valid today may be invalid tomorrow. Existing technologies often treat fingerprint databases as static assets, discarding them after use, unable to learn from failures or consolidate successful experiences. The iterative update mechanism is precisely to build a complete closed loop of "perception-decision-execution-learning." This step will record the handshake result in detail (success, negotiation failure, network failure, etc.). If successful, it will update the fingerprint profile's success rate, average latency, and other positive indicators under the corresponding scenario characteristics; if it fails, especially due to protocol or suite incompatibility, it will record specific error information and reduce the profile's weight in the relevant scenario. More importantly, this method integrates an intelligent fallback mechanism: when the initial handshake fails, it doesn't directly report an error, but automatically switches to a backup profile in the candidate set for retrying according to preset rules. The result of this process updates the weights of the initial profile (penalty) and the final successful profile (reward). This transforms the profile library from a static database into a dynamic knowledge base with collective intelligence, capable of automatically eliminating fingerprints that perform poorly in specific scenarios and strengthening the position of the preferred fingerprints. Finally, all key data—including the target profile used, scenario characteristics, selection decision path, detailed handshake results, fallback process, and library update status—are integrated to generate a fingerprint mimicry construction report. This report can be used not only for immediate problem diagnosis and strategy optimization but also as valuable data for long-term analysis of attack evolution trends and optimization of the overall mimicry strategy.

[0040] The method provided in this embodiment first intelligently filters a logically reasonable set of candidate fingerprints from a pre-built fingerprint database, based on the specific scenario of the current connection (such as the target service type) and the capabilities of the local system. Then, it dynamically scores the target fingerprint from the candidate set and enforces dual verification of "fingerprint invariance within the same session" and "fingerprint stability within the same service provider" to ensure realistic behavior. Finally, it performs a TLS handshake using the final fingerprint and automatically updates the scoring weights of the fingerprint database based on the success or failure result. It also introduces a retry mechanism that automatically switches to a backup fingerprint after failure and outputs a report to the user. This solution, through scenario-based filtering and dual consistency verification, makes the fingerprint spoofing highly consistent with the connection context and its behavioral logic self-consistent, greatly improving concealment and connection success rate. Its "construction-learning" closed loop allows the system to accumulate experience from each interaction, achieving continuous self-evolution of the fingerprint strategy and enhancing its adaptability and intelligence in long-term adversarial situations.

[0041] In some embodiments, based on the target connection scenario feature set, target side features and network features are extracted and matched with the scenario applicable label set associated with each fingerprint profile in the pre-built multi-dimensional feature fingerprint profile library to select a preliminary label matching profile set; based on the local protocol stack capability feature set, the feasibility of the preliminary label matching profile set is verified, and profiles containing fingerprint features that are not supported or uncontrollable by the local protocol stack are removed to generate a candidate fingerprint profile set.

[0042] Destination-side features can refer to a subset of features extracted from the target connection scenario feature set to describe the attributes related to the target server, including the target server's domain name, IP address, organization, or industry classification. Network features can refer to a subset of state features extracted from the target connection scenario feature set to describe the client's current network environment, such as the geographical location of the network exit and network type (e.g., mobile network, corporate intranet). The scenario applicability tag set can be a set of descriptive tags associated with each fingerprint profile object in a pre-built multi-dimensional feature fingerprint profile library, used to identify the network environment and target service type that the fingerprint profile is typically applicable to (e.g., "corporate intranet browser access," "mobile API call"). Matching analysis can refer to the logical process of comparing the extracted destination-side features, network features, and the scenario applicability tag set of the fingerprint profile. The preliminary tag-matching profile set can refer to the preliminary set of fingerprint profiles that, after matching analysis, conform to the current connection context in terms of scenario applicability. Feasibility verification can refer to comparing the static fingerprint feature set (such as a specific cipher suite or TLS extension) of each profile in the initial label matching profile set with the local protocol stack capability feature set one by one to verify whether the local system has the technical capability to accurately construct all the features of the fingerprint.

[0043] Specifically, traditional fingerprint spoofing schemes often use random selection or ranking based on general popularity when generating candidate sets. Their fundamental flaw lies in completely ignoring the two key constraints of "target environment adaptability" and "local technical feasibility." For example, when accessing an API that only accepts mobile application clients, if desktop browser fingerprints are mixed into the candidate set, this obvious scenario mismatch can easily trigger server-side anomaly detection. Similarly, selecting a fingerprint that relies on specific hardware acceleration or private TLS extensions, which the local system cannot support, will directly lead to handshake construction failure. To address these issues, this step first extracts target-side features and network features, and then performs matching analysis with the scenario-applicable tag set in the fingerprint profile library. This ensures that the preliminary profile set is highly consistent with the current connection intent and environment in terms of behavioral logic. For example, it only matches fingerprint profiles tagged with "mobile" and "common for this e-commerce domain" for the scenario of accessing "a certain e-commerce mobile API." Secondly, a mandatory technical review of feasibility verification is introduced. For each profile in the initial set, its defined fingerprint construction parameters (such as requirements for support of TLS_AES_256_GCM_SHA384 cryptography and application_layer_protocol_negotiation extension) are rigorously compared with the controllable capability list of the local protocol stack. If any mandatory feature that cannot be precisely implemented locally is found (e.g., local support for a certain elliptic curve or inability to forge the order of a specific extension), and there is no pre-defined equivalent degradation or alternative strategy, then this profile is removed from the candidate set. Through these two progressive screenings, the final set of candidate fingerprint profiles is generated.

[0044] The method provided in this embodiment, based on a dual filtering mechanism of scene label matching and feasibility verification, ensures the rationality of the candidate fingerprint set in terms of behavioral logic and the feasibility of its technical implementation from the source, significantly improving the success rate of the subsequent dynamic selection process and the robustness of the overall mimicry system.

[0045] In some embodiments, a fingerprint profile object is constructed for each emulated TLS client entity. Each fingerprint profile object includes a static fingerprint feature set, a scenario-applicable tag set, and a compatibility constraint set. The static fingerprint feature set defines the protocol version, cipher suite list and its order, extension list and its internal data required to construct the ClientHello message. The scenario-applicable tag set describes the network and target environment characteristics to which the fingerprint profile object is applicable. The compatibility constraint set defines the protocol stack capabilities and business logic prerequisites required to use the fingerprint profile object. The fingerprint profile objects are organized hierarchically into a main profile and variant profiles. The variant profile is formed by recording the difference between it and the corresponding main profile on the static fingerprint feature set, which is used to characterize subtle fingerprint variants under the same client category.

[0046] A fingerprint profile object can be a digital model created for each emulated TLS client entity in the network (such as a specific version of a browser or mobile application), used to fully describe the set of observable characteristics it exhibits during the TLS handshake phase. The static fingerprint feature set can be the core data part of the fingerprint profile object, precisely defining all protocol parameters and their order required to construct a ClientHello message consistent with the behavior of that client entity. Specifically, this includes the mandatory TLS protocol version, a list of cipher suites strictly ordered according to a specific priority, and all required TLS extensions (such as server_name, supported_groups) and their internal data format and order. The scenario applicability tag set can be a set of metadata tags associated with the fingerprint profile object, used to describe the network environment and target service type to which the fingerprint profile is adapted (e.g., "enterprise office network accessing O365", "mobile 4G network accessing social media APIs"). The compatibility constraint set can be a set of preconditions that must be met to apply the fingerprint profile object, including necessary local protocol stack capabilities (such as support for the TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 suite) and business logic constraints (such as only applicable to initiating HTTPS requests, not applicable to DTLS). The master profile can be a baseline fingerprint profile object representing a class of TLS clients (such as "Chrome browser main version 120"). A variant profile can be a derived object created based on a master profile. It does not store the complete static fingerprint feature set, but rather forms it by recording the differences between itself and the corresponding master profile on the static fingerprint feature set. The difference can refer to the parameter difference records between the variant profile and the corresponding master profile on the static fingerprint feature set, which can be represented as a set of add, delete, or modify operation instructions for one or more feature items. Subtle fingerprint variants can refer to specific instances of the same TLS client class (such as "Chrome 120") exhibiting minute but detectable differences on the static fingerprint feature set under different operating systems, patch levels, or hardware / software configurations.

[0047] Specifically, traditional methods for building fingerprint databases often employ a simple, flat list storage approach, where each fingerprint entry is independent and complete. This approach has several drawbacks: First, it suffers from severe redundant storage. A large number of fingerprints belonging to the same family and exhibiting highly similar characteristics are repeatedly stored, resulting in a bloated database and inefficient retrieval. Second, it lacks semantic association and hierarchical management. The system cannot perceive the kinship between "Chrome 120 for Windows" and "Chrome 120 for macOS," and can only perform blind traversal during selection and rollback, failing to achieve intelligent switching within the same family. Third, it is difficult to update and maintain. When a security update is released for a client category, causing even minor changes to its baseline fingerprint, all relevant entries need to be manually searched and modified, which is highly prone to errors or omissions. To address the above issues, this step first constructs a complete fingerprint profile object for each simulable TLS client entity. This object encapsulates its static fingerprint feature set (e.g., defining that its ClientHello must use TLS 1.2, the cipher suite list in the order [0xCCA9, 0xCCA8, 0xC02B], and must include the elliptic_curves extension with the curve list [0x0017, 0x0018]), scenario-applicable tag set (e.g., tagged "desktop browser" and "enterprise environment"), and compatibility constraint set in structured data form. Then, a hierarchical organization logic for the main profile and variant profiles is introduced: the most representative and common version is established as the main profile; for other versions with only minor differences, variant profiles are created. Variant profiles do not replicate all features of the main profile, but only record the differences. For example, a variant profile might only record one difference: "Add the ecdsa_secp384r1_sha384 algorithm to the signature_algorithms extension." When the variant profile is needed, the system can dynamically synthesize the target fingerprint by loading the complete features of the main profile and applying the recorded differences.

[0048] The method provided in this embodiment, which employs a master-variant hierarchical differential storage mechanism, greatly reduces the storage space of the fingerprint database and establishes a clear fingerprint kinship map, laying a solid data foundation for subsequent intelligent selection, accurate rollback, and efficient database maintenance.

[0049] In some embodiments, for each set of preliminary label-matching profiles, the fingerprint construction parameters defined by its static fingerprint feature set are extracted and compared with the list of controllable field capabilities of the local protocol stack one by one; fingerprint construction parameters that the local protocol stack cannot accurately implement are identified and marked. If any fingerprint construction parameter is marked as not being accurately implemented and there is no preset equivalent replacement strategy, then this fingerprint profile is removed from the set of candidate fingerprint profiles.

[0050] Fingerprint construction parameters can refer to specific, executable protocol parameter definitions extracted from the static fingerprint feature set of the fingerprint profile object. Examples include the required TLS protocol version number (e.g., TLS 1.3), a strictly ordered list of cipher suite identifiers (e.g., [0x1301, 0x1303]), and the specific type code and internal data structure of each TLS extension (e.g., the list of elliptic curve groups specified in the key_share extension [0x0017]). The list of controllable field capabilities can be a detailed list obtained through local protocol stack self-checks, configuration, or probes. It enumerates the TLS protocol fields that the local system can precisely control and set, along with their possible value ranges. Examples include the highest / lowest supported protocol versions, all available cipher suites and their priority adjustment capabilities, the types of TLS extensions that can be simulated, and the granularity of control over the filling and sorting of the internal data of these extensions (e.g., the list of curves in supported_groups). Comparison analysis can refer to the logical process of matching each fingerprint construction parameter as a constraint with the corresponding item in the list of controllable field capabilities to determine whether the local system possesses the precise implementation capability to satisfy the constraint. Equivalent substitution strategies can be pre-defined rules for downgrades or replacements for specific fingerprint features that cannot be implemented. These rules are derived from analyses of protocol compatibility and common client downgrade behaviors. For example, when a fingerprint requires a cipher suite that is not natively supported (such as TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256), the strategy may allow a replacement with another high-priority suite that is natively supported and common in the client family (such as TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256).

[0051] Specifically, traditional feasibility verification often relies on coarse capability matching, such as simply checking whether the local system "supports TLS 1.2" or "contains the AES-GCM suite." This coarse-grained checking has a fundamental flaw: it ignores the fact that the uniqueness of a fingerprint is determined precisely by the precise arrangement and subtle differences of its parameters. A fingerprint may differ significantly from another fingerprint due to subtle differences in the order of the cipher suite list (such as placing TLS_AES_128_GCM_SHA256 at the beginning of the list instead of the second) or the inclusion of an extension whose specific internal data cannot be constructed locally (such as requiring padding extensions to be padded to a specific byte length). Including these fingerprints that cannot be precisely implemented locally in the candidate set will directly lead to the constructed ClientHello message not matching the expected profile, resulting in protocol negotiation failure at best, and exposing the spoofing intent at worst due to contradictory fingerprint features. To address these issues, this step, based on each fingerprint profile in the initial tag-matching profile set, first extracts the complete fingerprint construction parameters defined by its static fingerprint feature set. Then, these parameters are rigorously compared and analyzed against the list of controllable field capabilities of the local protocol stack. For example, the system checks: whether the local system can precisely arrange the list of cipher suites in the order [0xC02B, 0xC02F, 0xCCA9]; whether it can generate the `signature_algorithms` extension and make its internal algorithm list completely consistent with the profile definition (e.g., [ecdsa_secp256r1_sha256, rsa_pkcs1_sha256]); and whether it can include only the `secp256r1` curve in the `supported_groups` extension. If any parameter cannot be precisely implemented locally (e.g., the local system does not support the `secp384r1` curve required by the profile), the system will mark it. Finally, for all marked parameters, it checks whether there is a preset equivalent replacement strategy (e.g., replacing `secp384r1` with `secp256r1`). If there is a mandatory parameter that cannot be precisely implemented and has no effective replacement strategy, the fingerprint profile will be considered technically infeasible and completely removed from the candidate fingerprint profile set.

[0052] The method provided in this embodiment ensures the absolute technical constructibility of each fingerprint in the candidate set through refined comparison and alternative strategy review at the protocol field level, fundamentally eliminating the risk of construction failure due to capability mismatch and guaranteeing the smooth execution of the subsequent mimicry construction process.

[0053] In some embodiments, a comprehensive selection score is calculated for each fingerprint image in the candidate fingerprint image set. The comprehensive selection score includes a historical performance score, a scenario matching score, and an image switching cost score. Based on the comprehensive selection score, the candidate images in the candidate fingerprint image set are sorted, and a preset number of candidate images at the top of the sort are sequentially subjected to session consistency verification and destination consistency verification. Session consistency verification is used to prevent switching of fingerprint images within the same TLS session, and destination consistency verification is used to ensure the stability of fingerprint images and minimize switching within the same destination policy domain. The candidate image that passes the verification and has the highest score is selected as the target fingerprint image.

[0054] The comprehensive selection score can be a multi-dimensional quantitative evaluation value calculated for each profile in the candidate fingerprint profile set, used to comprehensively measure the profile's suitability as the fingerprint for this connection. The historical performance score can be a quantitative score calculated based on the fingerprint profile's performance data in historical connection records (such as handshake success rate and average latency). The scenario matching score can be a quantitative score calculated based on the matching degree between the fingerprint profile's scenario applicable tag set and the current target connection scenario feature set. The profile switching cost score can be a quantitative evaluation of the "cost" required to switch from the currently active fingerprint (or default fingerprint) to this candidate fingerprint. The preset quantity can be a pre-configured integer threshold (e.g., 3 or 5) used to limit the number of candidate profiles entering the subsequent verification process, balancing selection quality and verification overhead. Session consistency verification can be a logical check mechanism designed to ensure that the fingerprint characteristics exhibited by the client remain absolutely consistent throughout the lifecycle of the same logical TLS session, preventing abnormal behaviors such as session hijacking or man-in-the-middle attacks from being exposed due to fingerprint mutations. Destination-side consistency verification can be a policy constraint mechanism designed to ensure that the fingerprint profile used in connections initiated to the same target server (or associated servers under the same policy domain) within a short period of time remains relatively stable or only varies within a preset range of compatible variants, in order to simulate the long-term access behavior patterns of real clients and avoid triggering risk control alarms on the target side due to frequent and irregular switching of fingerprints.

[0055] Specifically, traditional fingerprint selection schemes either rely on random selection or rank profiles based solely on a single dimension (such as static popularity). Their fundamental flaw lies in neglecting two crucial aspects: comprehensive performance optimization and behavioral consistency constraints in the selection process. For example, a fingerprint with a high historical success rate but a completely mismatched scenario label (such as using a fingerprint with a mobile cellular network label in an enterprise intranet environment) may experience a sharp drop in connection success rate. Similarly, a fingerprint with a high score that differs significantly from the fingerprints of currently active sessions or recent accesses to the same server can easily be identified as abnormal by the target server's security model, leading to connection blocking or account banning. Therefore, it is essential to introduce multi-dimensional comprehensive evaluation and mandatory behavioral consistency rules into the selection process. To address these issues, this step first calculates a comprehensive selection score for each profile in the candidate set. The score is calculated by weighting historical performance (e.g., a recent handshake success rate of 0.95 corresponds to a score of 0.95), scenario matching score (e.g., in the current scenario of "enterprise intranet access to O365", the profile tag matching score is 0.8), and profile switching cost score (e.g., switching from the currently active "Chrome 115" fingerprint to the candidate "Firefox 120" fingerprint, where the feature difference is large and the risk is high, the cost score is 0.3) according to a preset weight (e.g., 5:3:2). Then, the profiles are sorted in descending order according to the score, and the top N (a preset number, e.g., the top 3) high-scoring profiles are selected for the verification stage. Next, session consistency verification (checking and reusing existing active session fingerprints on the same target server) and destination-side consistency verification (querying, for example, the recently successfully used "Edge 118" profile under the "mail.office.com" domain policy domain, and forcing this selection to be limited to compatible variants) are performed sequentially. Finally, the profile that passes all verifications and has the highest overall score is determined as the target fingerprint profile.

[0056] The method provided in this embodiment ensures optimal performance of the selected system based on multi-dimensional comprehensive scoring, and enforces the logical coherence and time stability of client behavior through a dual consistency verification mechanism. This improves the connection success rate while greatly reducing the risk of being identified and blocked by the target system due to abnormal fingerprint behavior.

[0057] In some embodiments, before initiating a new TLS connection, it is checked whether there is a valid active TLS session with the same target server. If there is, fingerprint features are directly extracted from the historical fingerprint profile bound to the active TLS session for the construction of this connection, and the candidate fingerprint profile set and its selection and scoring process are ignored.

[0058] A valid, active TLS session refers to an encrypted communication session that has successfully completed a TLS handshake and been established with a specific target server within the current system or application context, and has not yet timed out or been disconnected. This session typically contains a session identifier that can be used for session reuse. A bound historical fingerprint profile refers to the fingerprint profile object that was actually successfully used to construct the ClientHello message and complete the handshake when the aforementioned active TLS session was established. This profile is associated with and stored with the session state information at the time of session establishment. The selection and scoring process can be the entire dynamic decision-making process of calculating a comprehensive selection score for the candidate fingerprint profile set, ranking them, and performing verification on the top-ranked profiles.

[0059] Specifically, traditional or simple fingerprint selection mechanisms typically re-execute the complete fingerprint selection logic for each independent TCP connection. This "one-time pad" approach works in most cases, but completely ignores a crucial feature of the TLS protocol layer: session reuse. In real network interactions, when a client communicates with the same server multiple times (e.g., a browser loading multiple resources from a webpage), it attempts to reuse the TLS session established by the first connection to avoid repeating the complete and costly handshake negotiation. If a simulated client uses drastically different fingerprints for two consecutive connections within the same logical session's lifecycle (e.g., the first connection uses the "Chrome 120" fingerprint to establish the session, while the second connection attempts to reuse the session using the "Firefox 119" fingerprint), this inconsistency constitutes a serious protocol-level behavioral anomaly. This is highly likely to be identified by the target server's TLS stack or security middleware as a sign of session hijacking, man-in-the-middle attacks, or automated scripts, leading to immediate session termination or connection blocking. Therefore, absolute consistency within the session must be prioritized at the very top of the selection logic. To address the above issues, this step, upon initiating any new TLS connection construction request, first queries the locally maintained session state table to check if a valid, active TLS session exists with the same target server (identified by IP address and port). If the check indicates an existence (e.g., a successful connection to api.example.com:443 was established and a reusable session was created 5 minutes ago), the system completely bypasses all subsequent complex scenario matching, feasibility verification, and selection scoring processes. Instead, the system directly extracts the complete static fingerprint feature set from the historical fingerprint profile bound to the active TLS session and strictly uses these features to construct the ClientHello message for this connection.

[0060] By using the method provided in this embodiment, the risk of inconsistencies in fingerprint features within the same session is fundamentally eliminated by prioritizing the inheritance of fingerprints from active sessions. This ensures the absolute logical correctness and consistency of protocol behavior, which is the core foundation for advanced fingerprint spoofing to remain stable and undetected for a long time.

[0061] In some embodiments, the destination information of the current connection is mapped to a preset policy domain identifier, and the presence of a fingerprint profile record that has been recently identified and successfully used is queried under the policy domain identifier. If such a fingerprint profile record exists, the fingerprint profile in the fingerprint profile record is used as a strong constraint for this selection, restricting the candidate fingerprint profile set to only include profile variants that are the same as or have a preset compatibility relationship with this profile record.

[0062] Destination-side information can refer to the characteristic information of the target server to which the current TLS connection request points, typically including the target domain name, IP address, port number, and optional application protocol type (such as HTTP, SMTP). Predefined policy domain identifiers can be a set of predefined logical grouping rules based on security policies and behavioral simulation requirements, used to group multiple target servers with the same security policies or consistent behavior into the same logical domain. Fingerprint profile records can be fingerprint profile objects that have recently successfully completed TLS handshakes and are recorded under a specific policy domain identifier, along with their usage timestamps. Strong constraints can refer to mandatory selection conditions with the highest priority in this selection decision process; they directly limit the scope of candidate profiles and have higher effectiveness than other scoring factors. Predefined compatibility relationships can be a set of rules predefined in the fingerprint profile database, used to describe the association between two different fingerprint profiles that can be considered "natural evolutions or reasonable variations of the same client." Their source is usually based on real-world observations; for example, different minor versions of the same browser major version (such as Chrome 120.0.6099.130 and Chrome 120.0.6099.210) are considered compatible variations.

[0063] Specifically, traditional fingerprinting models often treat each connection in isolation, striving to select an "optimal" fingerprint for each connection, while ignoring the long-term behavioral patterns of the same client accessing a specific service provider in a real network environment. For example, a real user accessing Gmail using their device over a period of time (e.g., a day) typically has a stable TLS fingerprint or evolves naturally within a small range (e.g., changing from Chrome 121.0.6167.85 to 121.0.6167.160 with automatic browser updates). If a simulated system uses three distinct core fingerprints—"Chrome," "Firefox," and "Edge"—to access mail.google.com sequentially within a short period, this chaotic and unstable fingerprint display pattern is easily identified as automated scripts or malicious crawling behavior by the target service provider's advanced threat detection system, leading to mass blocking of IPs or sessions. Therefore, behavioral stability constraints must be established in addition to session consistency across time and target dimensions. To address the above issues, when destination-side consistency verification is required in this step, the system first converts the destination-side information of the current connection request (such as the target domain login.microsoftonline.com) into its corresponding preset policy domain identifier (such as "Azure_AD") through a pre-configured rule mapping table. Then, the system queries the historical usage logs under the "Azure_AD" policy domain to determine if there is a fingerprint profile record that has been successfully used recently (e.g., within the past 12 hours). If it exists (e.g., the record shows that the fingerprint profile "Edge_118_Win11" was successfully used 8 hours ago), this record will be established as a strong constraint for this selection. Based on this, the system will restrict the current candidate fingerprint profile set to only include profiles that are exactly the same as the historical record (i.e., "Edge_118_Win11" itself), or its variants filtered according to preset compatibility relationships (e.g., variants of "Edge_118_Win10" under the same main profile, or upgraded versions of "Edge_119_Win11" that are configured to be allowed). Ultimately, the selection and evaluation process will only be conducted within this strictly constrained subset.

[0064] By enforcing the historical inheritance and smooth evolution of fingerprint usage at the policy domain level, the method provided in this embodiment effectively simulates the long-term stable behavior characteristics of real clients accessing specific services. This greatly reduces the risk of triggering risk control rules due to irregular and abrupt changes in fingerprints on the target side, and improves the long-term survivability and concealment of the mimicry system.

[0065] In some embodiments, the final fingerprint profile used for each TLS handshake, the corresponding target connection scenario feature set, and the handshake result information are recorded. The handshake result information is classified into success and negotiation failure: for successful handshakes, the average handshake latency statistics and success rate statistics of the corresponding fingerprint profile in the matching scenario are updated; for negotiation failures, the association between the fingerprint profile and the protocol or suite incompatibility information returned by the peer service in this connection is highlighted; based on the handshake result information, the historical performance statistics of the corresponding fingerprint profile in the multi-dimensional feature fingerprint profile library are updated, and the historical performance statistics include handshake success rate, average handshake latency, and failure association information; when the handshake fails, a fallback mechanism is executed, and the weights of the relevant fingerprint profiles are updated according to the fallback results; based on the recorded and updated statistical results, a fingerprint mimicry construction report is generated.

[0066] Handshake result information can refer to the collection of final state and related metadata about the connection attempt collected by the system after a single TLS handshake process is completed. Average handshake latency statistics can be a quantitative performance indicator obtained by calculating the moving average of the time taken for each successful handshake (from sending ClientHello to receiving the Finished message) for a specific fingerprint profile in a specific scenario. Success rate statistics can be the ratio of the number of successful handshakes to the total number of attempts for a specific fingerprint profile in a specific scenario, used to measure the overall reliability of the profile in that scenario. Protocol or suite incompatibility information can be information parsed from the Alert message returned by the peer server when a TLS handshake fails due to cryptographic parameter mismatch, indicating the specific incompatibility reason (such as handshake_failure, insufficient_security). Failure association information can be a diagnostic record formed by binding a specific handshake failure event with its possible causes (such as a specific incompatible cipher suite), the fingerprint profile used at the time, and the target scenario. A fallback mechanism can refer to a fault-tolerant process in which, after a TLS handshake based on the preferred fingerprint fails, the system automatically abandons the preferred fingerprint and switches to an alternative fingerprint to re-initiate the connection attempt according to a predetermined strategy.

[0067] Specifically, traditional TLS fingerprinting solutions often treat fingerprint construction as a one-time static configuration, lacking continuous monitoring and closed-loop optimization of application performance. This prevents the system from learning from failures: for example, a fingerprint profile might repeatedly fail at a specific cloud service provider due to lack of support for the TLS_AES_256_GCM_SHA384 cipher suite, yet the system will still repeatedly use it, causing unnecessary connection latency and resource waste. Simultaneously, the lack of quantitative tracking of successful profile performance (such as latency) makes it impossible to identify which profiles perform better in specific network environments. Furthermore, when the preferred fingerprint fails, the absence of an automatic switching mechanism will lead to a complete connection interruption, impacting business continuity. To address these issues, this step meticulously records the final fingerprint profile used, the target connection scenario feature set, and handshake result information after each TLS handshake attempt. For successful handshakes, the system updates the average handshake latency statistics for that profile in the matching scenario (e.g., if the current latency is 180ms, the updated historical average latency becomes 185ms) and success rate statistics (e.g., incrementing the number of successful attempts and the total number of attempts by 1). For handshakes that fail to resolve, the system parses the Alert message returned by the peer, extracts protocol or suite incompatibility information (such as `handshake_failure`, or more specifically `no_application_protocol`), and highlights this information as failure-related information in the fingerprint profile's history. All handshake results are used to update the profile's historical performance statistics. When a handshake failure is detected, the system executes a fallback mechanism, such as selecting the next profile from a predefined fallback chain (e.g., falling back from "Chrome 120" to "Firefox 119") to retry. Regardless of whether the fallback is successful, the system updates the weights of relevant profiles in reverse order based on the success or failure of each profile in the fallback chain (e.g., reducing the weight of the profile that caused the initial failure and appropriately increasing the weight of the profile that ultimately succeeded). Finally, the system generates a fingerprint mimicry construction report containing all operation records and the latest statistical view.

[0068] The method provided in this embodiment enables the fingerprint profile database to have self-learning and dynamic evolution capabilities based on continuous quantitative evaluation and correlation analysis. At the same time, the rollback mechanism ensures the business elasticity of the connection layer, thereby systematically improving the overall adaptability, success rate and long-term survivability of the fingerprint mimicry system.

[0069] In some embodiments, when a handshake failure based on the target fingerprint profile is detected, the next candidate fingerprint profile is automatically selected according to a predefined or dynamically associated fallback chain; the TLS handshake connection is re-initiated based on the candidate fingerprint profile, and this process is repeated until the handshake succeeds or the fallback chain is exhausted.

[0070] The fallback chain can be a pre-configured, statically configured, or dynamically generated sequence of fingerprint profiles based on the failure context. This sequence defines the order of alternative attempts the system should follow when a handshake fails based on the current preferred profile. Alternative fingerprint profiles refer to the next-order fingerprint profile object in the fallback chain after the currently failed fingerprint profile, which will be used to re-initiate the connection attempt.

[0071] Specifically, in a dynamic and ever-changing network environment, no single fingerprint profile can guarantee 100% success in all scenarios and at all times. Traditional solutions typically only log the error and terminate the connection when the handshake fails, shifting the responsibility for recovery to upper-layer applications. This not only leads to business interruptions and a degraded user experience but also wastes valuable contextual information revealed by the initial failure (e.g., a specific server temporarily rejecting certain cipher suites). The lack of automated and intelligent failure recovery mechanisms makes the system vulnerable to adjustments in target server policies or temporary compatibility issues, failing to meet high-availability business requirements. Therefore, it is essential to initiate an orderly, non-manually-intervened alternative attempt process as soon as a failure is detected to minimize the risk of single points of failure. To address the above issues, this step, when the system detects a TLS handshake failure based on the target fingerprint profile (e.g., "Chrome 120_Win11") (e.g., receiving a handshake_failure alert), immediately interrupts the current failed connection and operates according to a predefined or dynamically associated fallback chain for the current connection scenario (e.g., a predefined chain of ["Firefox 119_Win11", "Edge 118_Win10"]). The system automatically selects the next candidate fingerprint profile in the chain (i.e., "Firefox 119_Win11") and completely re-initiates the TLS handshake connection based on the static feature set of this candidate fingerprint profile. The system loops this process: if using "Firefox 119_Win11" fails again, it continues to try "Edge 118_Win10" until the handshake succeeds or the fallback chain is exhausted (all candidates fail), at which point the final error is returned to the upper layer.

[0072] The method provided in this embodiment provides multi-layered redundancy protection for each connection attempt. The automated and orderly rollback significantly improves the final success rate of a single connection task and the overall robustness of the system, ensuring the continuity and smoothness of core business flows when facing fingerprint compatibility fluctuations.

[0073] Figure 3 A schematic diagram of a TLS protocol fingerprint mimicry construction system based on multi-dimensional feature mapping, provided in an embodiment of this application, is shown below. Figure 3As shown, the TLS protocol fingerprint mimicry construction system 300 based on multidimensional feature mapping in this embodiment includes: a candidate fingerprint profile module 301, a target fingerprint profile module 302, and a fingerprint construction report module 303.

[0074] The candidate fingerprint profile module 301 is used to acquire the target connection scenario feature set and the local protocol stack capability feature set. Based on the target connection scenario feature set and the local protocol stack capability feature set, and combined with the pre-built multi-dimensional feature fingerprint profile library, scenario adaptability screening is performed to generate a candidate fingerprint profile set. The target fingerprint profile module 302 is used to perform dynamic selection and consistency constraint verification of the target profile based on the candidate fingerprint profile set to generate a target fingerprint profile adapted to the current connection scenario. The fingerprint construction report module 303 is used to drive TLS handshake mimicry construction based on the target fingerprint profile and iteratively update the multi-dimensional feature fingerprint profile library based on the handshake result to generate a fingerprint mimicry construction report.

[0075] Optionally, the candidate fingerprint profile module 301, during the generation process based on the candidate fingerprint profile set, is specifically used for: extracting target-side features and network features based on the target connection scenario feature set, performing matching analysis with the scenario applicable label set associated with each fingerprint profile in the pre-built multi-dimensional feature fingerprint profile library, and filtering out a preliminary label-matching profile set; performing feasibility verification on the preliminary label-matching profile set based on the local protocol stack capability feature set, removing profiles that contain fingerprint features that are not supported or uncontrollable by the local protocol stack, and generating the candidate fingerprint profile set.

[0076] Optionally, during the construction process based on the pre-built multi-dimensional feature fingerprint profile library, the candidate fingerprint profile module 301 is specifically used to: construct a fingerprint profile object for each simulable TLS client entity, each fingerprint profile object including a static fingerprint feature set, a scenario applicable tag set, and a compatibility constraint set; wherein, the static fingerprint feature set defines the protocol version, cipher suite list and its order, extension list and its internal data required to construct the ClientHello message; the scenario applicable tag set is used to describe the network and target environment characteristics applicable to the fingerprint profile object; the compatibility constraint set defines the protocol stack capabilities and business logic prerequisites required to use the fingerprint profile object; and organize the fingerprint profile objects according to the hierarchy of main profile and variant profiles, wherein the variant profile is formed by recording the difference between it and the corresponding main profile on the static fingerprint feature set, in order to characterize subtle fingerprint variants under the same client category.

[0077] Optionally, when performing the feasibility verification, the candidate fingerprint profile module 301 is specifically used to: extract the fingerprint construction parameters defined by the static fingerprint feature set for each preliminary label matching profile set, and compare and analyze them one by one with the controllable field capability list of the local protocol stack; identify and mark the fingerprint construction parameters that the local protocol stack cannot accurately implement; if there is any fingerprint construction parameter marked as not being accurately implemented, and there is no preset equivalent replacement strategy, then remove this fingerprint profile from the candidate fingerprint profile set.

[0078] Optionally, the target fingerprint profile module 302, during the generation process based on the target fingerprint profile, is specifically configured to: calculate a comprehensive selection score for each fingerprint profile in the candidate fingerprint profile set, the comprehensive selection score including historical performance score, scenario matching score, and profile switching cost score; sort the candidate profiles in the candidate fingerprint profile set based on the comprehensive selection score, and sequentially perform session consistency verification and destination consistency verification on a predetermined number of the top-ranked candidate profiles; the session consistency verification is used to prevent switching of fingerprint profiles within the same TLS session, and the destination consistency verification is used to ensure the stability of fingerprint profiles and minimize switching within the same destination policy domain; and select the candidate profile that passes the verification and has the highest score as the target fingerprint profile.

[0079] Optionally, when the target fingerprint profile module 302 is based on the session consistency verification, it is specifically used to: check whether there is a valid active TLS session with the same target server before initiating a new TLS connection; if there is, directly extract fingerprint features from the historical fingerprint profile bound to the active TLS session for the construction of this connection, and ignore the candidate fingerprint profile set and its selection and scoring process.

[0080] Optionally, when the target fingerprint profile module 302 performs the consistency check based on the destination side, it is specifically used to: map the destination side information of the current connection to a preset policy domain identifier, and query whether there is a fingerprint profile record that has been recently determined and successfully used under the policy domain identifier; if there is, the fingerprint profile in the fingerprint profile record is used as a strong constraint for this selection, restricting the candidate fingerprint profile set to only include profile variants that are the same as the profile in this record or have a preset compatibility relationship.

[0081] Optionally, the fingerprint construction report module 303, during the generation process of the fingerprint mimicry construction report, specifically performs the following: recording the final fingerprint profile used in each TLS handshake, the corresponding target connection scenario feature set, and handshake result information; the handshake result information is classified into success and negotiation failure: for successful handshakes, updating the average handshake latency statistics and success rate statistics of the corresponding fingerprint profile in the matching scenario; for negotiation failures, highlighting the association between the fingerprint profile and the protocol or suite incompatibility information returned by the peer service in this connection; based on the handshake result information, updating the historical performance statistics of the corresponding fingerprint profile in the multi-dimensional feature fingerprint profile library, the historical performance statistics including handshake success rate, average handshake latency, and failure association information; executing a fallback mechanism when the handshake fails, and updating the weight of the relevant fingerprint profile according to the fallback result; and generating the fingerprint mimicry construction report based on the recorded and updated statistical results.

[0082] Optionally, when the fingerprint construction report module 303 is based on the execution fallback mechanism, it is specifically used to: when a handshake failure based on the target fingerprint profile is detected, automatically select the next candidate fingerprint profile according to a predefined or dynamically associated fallback chain; re-initiate the TLS handshake connection based on the candidate fingerprint profile, and repeat this process until the handshake is successful or the fallback chain is exhausted.

[0083] The system in this embodiment can be used to execute the methods of any of the above embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

Claims

1. A method for constructing TLS protocol fingerprint mimicry based on multi-dimensional feature mapping, characterized in that, include: Obtain the target connection scenario feature set and the local protocol stack capability feature set. Based on the target connection scenario feature set and the local protocol stack capability feature set, and combined with the pre-built multi-dimensional feature fingerprint profile library, perform scenario adaptability screening to generate a candidate fingerprint profile set. Based on the candidate fingerprint profile set, the target profile is dynamically selected and its consistency constraint is checked to generate a target fingerprint profile that is adapted to the current connection scenario. Based on the target fingerprint profile, a TLS handshake mimicry construction is driven, and the multi-dimensional feature fingerprint profile library is iteratively updated based on the handshake result to generate a fingerprint mimicry construction report.

2. The method according to claim 1, characterized in that, The process of generating the candidate fingerprint profile set includes: Based on the target connection scene feature set, target side features and network features are extracted and matched with the scene applicable label set associated with each fingerprint portrait in the pre-constructed multi-dimensional feature fingerprint portrait library to screen out a preliminary label matching portrait set. Based on the local protocol stack capability feature set, a feasibility verification is performed on the preliminary label matching profile set, and profiles containing fingerprint features that are not supported or uncontrollable by the local protocol stack are removed to generate the candidate fingerprint profile set.

3. The method according to claim 2, characterized in that, The construction process of the pre-built multidimensional feature fingerprint profile library includes: For each simulable TLS client entity, a fingerprint profile object is constructed, and each fingerprint profile object includes a static fingerprint feature set, a scenario-applicable tag set, and a compatibility constraint set; The static fingerprint feature set defines the protocol version, cipher suite list and its order, extension list and its internal data required to construct the ClientHello message; The scenario-applicable tag set is used to describe the network and target environment characteristics applicable to the fingerprint profile object; The compatibility constraint set defines the protocol stack capabilities and business logic prerequisites required to use the fingerprint profile object; The fingerprint profile objects are organized in a hierarchy of main profile and variant profiles, wherein the variant profiles are formed by recording the difference between them and the corresponding main profile on the static fingerprint feature set, in order to characterize subtle fingerprint variants under the same client category.

4. The method according to claim 2, characterized in that, The execution feasibility verification includes: For each set of preliminary tag-matching profiles, the fingerprint construction parameters defined by its static fingerprint feature set are extracted and compared with the list of controllable field capabilities of the local protocol stack. Identify and mark the fingerprint construction parameters that cannot be accurately implemented by the local protocol stack. If any fingerprint construction parameter is marked as not being accurately implemented and there is no preset equivalent replacement strategy, then remove this fingerprint profile from the candidate fingerprint profile set.

5. The method according to claim 2, characterized in that, The process of generating the target fingerprint profile includes: A comprehensive selection score is calculated for each fingerprint image in the candidate fingerprint image set. The comprehensive selection score includes historical performance score, scene matching score, and image switching cost score. Based on the comprehensive selection score, the candidate images in the candidate fingerprint image set are sorted, and a preset number of the first-ranked candidate images are sequentially subjected to session consistency verification and destination consistency verification. The session consistency check is used to prevent the fingerprint profile from being switched within the same TLS session, and the destination consistency check is used to ensure the stability of the fingerprint profile and minimize switching within the same destination policy domain. The candidate image that passes the verification and has the highest score is used as the target fingerprint image.

6. The method according to claim 5, characterized in that, The session consistency check includes: Before initiating a new TLS connection, check if a valid active TLS session exists with the same target server. If present, fingerprint features are directly extracted from the historical fingerprint profile bound to the active TLS session for this connection construction, and the candidate fingerprint profile set and its selection and scoring process are ignored.

7. The method according to claim 5, characterized in that, The destination-side consistency check includes: Map the current connection's destination information to a preset policy domain identifier, and query whether there is a fingerprint profile record that has been recently identified and successfully used under the policy domain identifier; If it exists, the fingerprint image in the fingerprint image record will be used as a strong constraint for this selection, restricting the candidate fingerprint image set to only include image variants that are the same as the image in this record or have a preset compatibility relationship.

8. The method according to claim 5, characterized in that, The process of generating the fingerprint mimicry construction report includes: Record the final fingerprint profile used in each TLS handshake, the corresponding target connection scenario feature set, and the handshake result information; The handshake result information is classified as success and negotiation failure: for a successful handshake, the average handshake latency statistics and success rate statistics of the corresponding fingerprint profile in the matching scenario are updated; In the event of a failed negotiation, the association between the fingerprint profile and the protocol or suite incompatibility information returned by the peer service during this connection is highlighted. Based on the handshake result information, update the historical performance statistics of the corresponding fingerprint profile in the multidimensional feature fingerprint profile database. The historical performance statistics include handshake success rate, average handshake latency and failure association information. When the handshake fails, a rollback mechanism is executed, and the weights of the relevant fingerprint profiles are updated based on the rollback result; Based on the recorded and updated statistical results, the fingerprint mimicry construction report is generated.

9. The method according to claim 8, characterized in that, The execution rollback mechanism includes: When a handshake failure based on the target fingerprint profile is detected, the next candidate fingerprint profile is automatically selected according to a predefined or dynamically associated fallback chain. Based on the alternative fingerprint profile, a new TLS handshake connection is initiated, and this process is repeated until the handshake is successful or the fallback chain is exhausted.

10. A TLS protocol fingerprint mimicry construction system based on a multi-target fingerprint profile database, characterized in that, The method applied to any one of claims 1-9 includes: The candidate fingerprint profile module is used to obtain the target connection scenario feature set and the local protocol stack capability feature set. Based on the target connection scenario feature set and the local protocol stack capability feature set, combined with the pre-built multi-dimensional feature fingerprint profile library, scenario adaptability screening is performed to generate a candidate fingerprint profile set. The target fingerprint profile module is used to dynamically select and verify the consistency constraint of the target profile based on the candidate fingerprint profile set, and generate a target fingerprint profile that is adapted to the current connection scenario. The fingerprint construction report module is used to drive TLS handshake mimicry construction based on the target fingerprint profile, and to iteratively update the multi-dimensional feature fingerprint profile library based on the handshake result to generate a fingerprint mimicry construction report.

Images