A relay attack verification method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application disclose a relay attack verification method and device, electronic equipment and a storage medium. The method is applied to a client and includes: a first process of the client listening to target traffic and analyzing the target traffic to obtain a first public key; the first process of the client sending a first request to a server based on the first public key; and the first process of the client receiving a first remote proof report sent by the server according to the first request, and verifying the server by judging whether a public key analyzed according to a challenge value in the first remote proof report is the same as the first public key. The method of the embodiments of the present application can effectively resist relay attacks and protect the confidentiality of a session by realizing listening to target traffic by an independent process and verifying the remote proof report of the server according to the public key obtained by analyzing the target traffic, and does not need to modify the software, binary files or running logic of the upper-layer software.

Description

Technical Field

[0001] This application relates to the field of network security technology, and in particular to a relay attack verification method, apparatus, electronic device and storage medium. Background Technology

[0002] Privacy-preserving computation is one of the mainstream technical approaches for secure cross-domain collaborative computing, primarily encompassing three major approaches: federated learning, multi-party secure computation, and trusted execution environments (TEAs). Among these, the core idea of ​​TEA technology is to transmit data to an isolated environment, decrypt it there, and then perform plaintext computation. Therefore, TEA offers significant performance advantages compared to the other two approaches and requires less modification to existing software. Specifically, TEA technology typically requires transmitting plaintext (or transmitting ciphertext first and then transmitting the decryption key during use) from the outside to the TEA. This transmission process mainly relies on Transport Layer Security (TLS) encryption to ensure security.

[0003] During this transmission process, to enable clients to verify whether the confidential network they are accessing is truly connected to the trusted execution environment, existing technologies typically employ certificate extension, Layer 2 tunneling, and Secure Sockets Layer (SSL) component extensions for secure path verification. However, certificate extension and some SSL component extension solutions are unable to resist relay attacks under TLS key leakage. While Layer 2 tunneling and a limited number of SSL component extensions can effectively isolate confidential network paths and provide high security, their implementation usually involves low-level modifications to the network stack, resulting in high deployment complexity. Furthermore, they introduce additional protocol overhead during tunnel establishment and maintenance, reducing transmission efficiency. Summary of the Invention

[0004] This application provides a relay attack verification method, apparatus, electronic device, and storage medium that can effectively resist relay attacks under TLS key leakage and ensure session confidentiality in a low-overhead and highly compatible manner, while requiring no modification to the upper-layer application and being easy to deploy.

[0005] In a first aspect, one embodiment of this application provides a relay attack verification method, applied to a client, comprising: The client's first process listens to the target traffic and parses the target traffic to obtain the first public key; The client's first process sends the first request to the server based on the first public key; The client's first process receives the first remote authentication report sent by the server based on the first request, and verifies the server by determining whether the public key parsed from the first remote authentication report is the same as the first public key.

[0006] Secondly, one embodiment of this application provides a relay attack verification method, applied to a server, comprising: The second process on the server listens to the first handshake traffic and parses it to obtain the second public key; The second process on the server generates a first remote proof report based on the second public key; The second process on the server receives the first request from the client, parses the first request, and obtains the first public key. If the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, the first remote proof report is sent to the client so that the client can verify the server by judging whether the public key parsed from the challenge value in the first remote proof report is the same as the second public key.

[0007] In the above embodiments, the second process on the server listens to and parses the first handshake traffic to obtain the second public key, generates a remote proof report in advance, and then, upon receiving the first request from the client, returns the report only if the time interval between the generation of the first and second public keys is less than a set threshold. This embodiment utilizes time window verification to ensure that each proof report is only valid for the current session, thereby effectively resisting relay attacks under TLS key leakage. Simultaneously, the server and client employ peer-to-peer traffic parsing logic, eliminating the need to modify upper-layer applications or the TLS protocol stack, reducing real-time response overhead, and achieving low-cost, lightweight integrated deployment.

[0008] Thirdly, one embodiment of this application provides a relay attack verification device applied to a client, the device comprising: The first processing unit is used to: monitor the target traffic and parse the target traffic to obtain the first public key; The first transmission unit is used to: send a first request to the server based on the first public key; The first transmission unit is also configured to: receive a first remote certification report sent by the server in accordance with the first request; The first processing unit is further configured to: verify the server by determining whether the public key parsed from the first remote proof report is the same as the first public key.

[0009] Fourthly, one embodiment of this application provides a relay attack verification device applied to a server, the device comprising: The second processing unit is used to: listen to the first handshake traffic and parse the first handshake traffic to obtain the second public key; The second processing unit is also used to: generate a first remote proof report based on the second public key; The second transmission unit is used to: receive a first request from the client; The second processing unit is further configured to: parse the first request to obtain the first public key; The second transmission unit is further configured to: if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, send the first remote proof report to the client so that the client can verify the server by judging whether the public key parsed from the first remote proof report is the same as the second public key.

[0010] Fifthly, one embodiment of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of any of the above methods.

[0011] Sixthly, one embodiment of this application provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0012] In a seventh aspect, one embodiment of this application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of any of the above methods.

[0013] In this embodiment, the client's independent process listens to and parses the target traffic, extracts the first public key, and sends the corresponding first request to the server based on the first public key. The first public key is then compared with the public key in the remote verification report provided by the server to verify the server's identity. This not only effectively resists relay attacks under TLS key leakage and strongly protects session confidentiality, but also requires no modification to the code, binary files, or runtime logic of the upper-layer software. Attached Figure Description

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

[0015] Figure 1 This is a diagram illustrating a relay attack. Figure 2 This is a schematic diagram illustrating an application scenario of a relay attack verification method provided in an embodiment of this application; Figure 3 A schematic diagram illustrating a relay attack verification method provided in an embodiment of this application applied to a client. Figure 4A schematic diagram illustrating a relay attack verification method provided in an embodiment of this application applied to a server. Figure 5 A system architecture diagram for implementing a confidential network resistant to relay attacks is provided in one embodiment of this application; Figure 6 An interactive flowchart of a verification server in blocking mode is provided as an embodiment of this application; Figure 7 An interaction flowchart of a verification client in blocking mode is provided as an embodiment of this application; Figure 8 An interactive flowchart of bidirectional verification in blocking mode is provided as an embodiment of this application; Figure 9 This is a schematic diagram of the structure of a relay attack verification device provided in an embodiment of this application; Figure 10 A schematic diagram of a relay attack verification device provided in another embodiment of this application; Figure 11 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0016] 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.

[0017] For ease of understanding, the terms used in the embodiments of this application are explained below: (1) Trusted computing is a general approach and technical system that utilizes hardware and software technologies to enhance the security of computer systems. Its core objective is to ensure that all critical components during computer startup and operation can be verified and trusted, and will not be maliciously tampered with. Trusted computing typically relies on "roots of trust" (such as hardware security chips like TPM (Trusted Platform Module)) to measure and record the integrity of every critical component (such as firmware, operating system, etc.) loaded during system startup. When these components are tampered with or infected with malicious code, the system can detect the anomaly, refuse to continue running, or issue a warning. It is usually used to ensure the security of physical machine startup (i.e., it has not been tampered with), and can also be used to protect the security of virtual machine startup.

[0018] (2) Trusted Execution Environment (TEE): A TEE is a "secure execution zone" supported by processor hardware. Code running and data used within this zone are protected at the hardware level. Even if the operating system, system administrator, or malware gains high privileges, it is difficult to view or tamper with its contents. Typical implementations include Intel SGX, Intel TDX, ARM TrustZone, AMD SEV, and Hygon CSV. It is commonly used to protect the execution security of highly sensitive tasks such as payment, privacy computing, and key management. Compared to trusted computing, the trusted computing base upon which the TEE is based is smaller and has a higher security level (but it usually cannot protect the physical machine). This is an industry trend, and these can be considered two similar but independent technical routes. In recent years, the secure execution zone has typically manifested as a complete virtual machine. It can be assumed that after entering this TEE, its behavior is no different from that of a regular virtual machine.

[0019] (3) Confidential computing refers to a technology system that maintains the confidentiality and integrity of data while it is “in use” (i.e., loaded into memory and processed by the processor). Unlike traditional methods that only protect “data in storage” and “data in transmission”, confidential computing usually relies on hardware mechanisms such as trusted execution environments to ensure that plaintext data is only present inside the CPU during computation, while the physical machine memory or host machine memory dump remains encrypted. In scenarios such as cloud computing, multi-party collaborative analysis, finance and healthcare, it prevents cloud platform operators or attackers from stealing or tampering with sensitive data during the computation process.

[0020] (4) The DH (Diffie-Hellman) handshake, also known as Diffie-Hellman key exchange, is a secure communication protocol used to securely exchange keys over insecure channels. Both parties generate their own private and public keys, transmit the public key to the other party over the network, and negotiate a common session key using mathematical calculations. This enables encrypted communication and ensures the confidentiality and security of the data. In practice, the DH handshake is usually implemented based on elliptic curves, and is called ECDHE (Elliptic Curve Diffie-Hellman Ephemeral).

[0021] (5) TLS protocol. The TLS protocol is a standard protocol used to establish an encrypted secure channel between two ends of a network. Its predecessor is the SSL protocol. It is the security foundation of various mainstream communication protocols such as HTTPS. It negotiates the session key through the handshake process and encrypts and verifies the integrity of the transmitted data. At the same time, it uses digital certificates to verify the identity of the communication peer, thereby preventing security threats such as network eavesdropping, data tampering and "man-in-the-middle attacks".

[0022] Among them, the TLS 1.3 standard gradually became the mainstream solution starting in 2018. Its session key is no longer directly based on the TLS private key, but rather a randomly generated ephemeral ECDHE public key, which is discarded immediately after generation. This gives TLS 1.3 forward security (a leak of the TLS private key will not lead to the leakage of past sessions, because previous ECDHE keys cannot be deduced from the TLS private key). The ECDH public key in the TLS session is transmitted to the other end over the network. The session packet containing the server's public key is usually called the TLS Server Hello traffic, and the session packet containing the client's public key is usually called the TLS Client Hello traffic.

[0023] (6) SSL encryption components: SSL encryption components typically refer to encryption software libraries or modules that implement the TLS or SSL protocol, such as OpenSSL. They provide a unified programming interface for upper-layer applications to perform operations such as key negotiation, data encryption and decryption, and certificate verification. This allows developers to add secure communication capabilities to their applications without having to implement complex cryptographic algorithms and protocol details themselves. Mainstream SSL encryption components include openssl, boringssl, gnutls, and gotls.

[0024] (7) NFQueue: NFQueue is a queuing mechanism provided by the Linux Netfilter / iptables firewall framework. It can transfer network packets that meet specific rules (such as specifying that all or part of the source IP, source port, destination IP, and destination port meet a certain condition) from the Linux kernel to user-space programs. The user programs then perform deep inspection, modification, or policy decisions, and return the processing results to the kernel to decide whether to allow, drop, or rewrite and continue forwarding. Therefore, NFQueue is often used to build intrusion detection / prevention systems, application layer firewalls, and complex traffic processing components. It is easy to note that the user-space program of NFQueue can forcibly sleep during processing to temporarily delay the transmission of traffic until a certain decision point is determined.

[0025] (8) WinDivert: WinDivert is a network interception driver and user-space library on the Windows platform. It can capture, filter and modify network packets entering and leaving the local machine at different stages of the operating system network stack, and allow user programs to inject the processed packets back into the system. Therefore, it can be used to implement functions such as custom firewall, traffic redirection, protocol analysis and debugging. It is a common software-level packet interception tool under Windows.

[0026] (9) Remote Attestation (RA): Remote attestation is a technical mechanism that allows a remote system to "prove its trustworthiness" to a verifier. It typically involves code within a secure chip equipped with a trusted computing or trusted execution environment measuring its own execution environment and loader (e.g., calculating hash values) and generating a signed attestation report using an internal key. The remote verifier verifies the signature and compares it to a whitelist to confirm that the remote system has not been tampered with and is indeed running the expected trusted software, thus confidently sending sensitive data or entrusting critical computing tasks. The generation of the remote attestation report relies on a chip-level key, which cannot be forged without obtaining it. Furthermore, remote attestations are usually timely, meaning the generated report includes the report's creation time. If this creation time does not match the verifier's requirements, the verifier can consider the remote attestation report invalid.

[0027] The number of any elements in the accompanying drawings is for illustrative purposes only and not as a limitation, and any naming is for distinction only and has no limiting meaning.

[0028] In practice, relying solely on the security extension of the TLS private key is insufficient to ensure that a confidential network can verify that the communicating peer is in a confidential environment. Existing solutions commonly incorporate remote authentication technology, which allows the user to remotely verify whether the other party is running in a trusted execution environment at some stage of communication establishment; this is often referred to as confidential network technology.

[0029] Specifically, existing classified network technologies are generally divided into three categories: (1) Certificate extension: The remote proof report is embedded as an extension field into the X.509 certificate on which TLS is based. While performing traditional certificate verification, the client parses and verifies the proof information in the certificate, thereby confirming the confidential environment of the other end while establishing a TLS connection.

[0030] The above solution is simple and highly interpretable, and it directly extends static certificates without requiring any changes to upper-layer business logic. Therefore, it is currently the most prevalent solution in the industry. However, it is important to note the following issues: Certificate-based services typically cannot be updated frequently, meaning that the remote verification report embedded in the certificate is constantly being reused, and its verification lacks timeliness; remote verification reports generated in different confidential environments are different, which further leads to different certificates being relied upon by the same service running in multiple confidential environments. This can cause commonly used upper-layer load balancing components (such as nginx) to be unable to transparently proxy and forward traffic; and there may be issues with compliance authentication of changed certificates.

[0031] (2) Layer 2 tunnel: First, complete the TLS handshake and channel establishment according to the conventional process. Then, the upper layer application protocol initiates remote proof interaction. During the round trip of challenge and report, a new key is generated through negotiation of the reserved field (usually based on ECDHE). The business data is then additionally encrypted with this key and transmitted through TLS to realize "secret tunnel on TLS".

[0032] The above scheme also has strong interpretability; however, it has the following problems: double encryption will significantly increase computational overhead and reduce the overall operational efficiency of the business; it requires modification of the original software to embed the logic of double encryption and remote proof generation and verification into the software, which will bring additional software development costs.

[0033] (3) SSL component extension: By extending or modifying basic cryptographic libraries such as OpenSSL, the verification logic of remote authentication is directly integrated into the TLS handshake phase, so that the connection establishment itself is based on the trust measurement of the confidential environment, and "endpoint trust" is incorporated into the network security baseline from the bottom layer of the protocol stack. In essence, it writes information at the TLS session level, rather than embedding it in the X.509 certificate, which is more tightly bound to the session and the verification granularity is finer.

[0034] The above solutions are theoretically feasible; however, depending on the specific extension or modification method, they have the following problems: directly modifying mature OpenSSL components carries significant stability risks, and OpenSSL itself has many versions, making it difficult and costly to modify them one by one; based on OpenSSL's callback interface or encapsulating new binary libraries similar to libssl.so, they can only be applied to upper-layer business logic with custom coding, and cannot be directly compatible with existing software; mainstream SSL components are not limited to OpenSSL, and modifying and adapting them one by one is extremely costly; some closed-source application software integrates OpenSSL and other components to form larger static libraries, in which case it is impossible to modify the SSL components.

[0035] The effectiveness of the scheme in the case of a leaked TLS key was not discussed in the above process. This will be supplemented below.

[0036] First, it should be noted that in scenarios such as trusted data spaces, the leakage of TLS private keys is not an extremely rare event. The reasons include: When the TLS certificate is deployed in the trusted data space, it is usually not self-signed and an existing certificate needs to be reused. This means that the TLS private key is usually generated in advance outside the trusted execution environment and then imported into the service code of the trusted data space by some operations and maintenance personnel in a specific way. The entire chain involves too many operations and maintenance personnel, developers, etc., which can easily lead to leakage. On the other hand, the TLS private key is stored in other services of the organization, and the security level of the related services is usually not as good as that of the trusted execution environment. Attackers may obtain the private key on other service sides through memory scanning and other means, which indirectly leads to security degradation.

[0037] Furthermore, there is currently no practical method to directly generate TLS private keys endorsed by an authoritative CA within a trusted execution environment. Therefore, the above assumptions are consistent with reality.

[0038] Building upon this, the following section further introduces relay attacks under TLS key leakage. This attack was proposed in a paper titled "Separate but Together: Integrating Remote Attestation into TLS" presented at USENIX ATC (Computer Systems CCF-A top conference) in 2025. Figure 1 As shown, the client requests a service from a remote server (e.g., uploading data to a confidential environment), while the attacker impersonates the real server to establish a session with the client.

[0039] Specifically, the client sends the TLS handshake information and the challenge value (Nonce) from the remote verification report to the attacker. The attacker immediately establishes a session with the real server and sends the obtained challenge value (Nonce) to the real server. To prove its trustworthiness, the real server provides a remote verification report to the attacker. The attacker then provides this remote verification report to the actual client. The client can authenticate the data from both the TLS and remote verification perspectives, believes the attacker to be the real server provider, and then uploads the data, resulting in data leakage.

[0040] It should be noted that, when the TLS key is compromised, the attacker can launch the aforementioned attacks without needing any other information. Furthermore, all three existing technologies described above have significant flaws in the process of transmitting confidential data. (1) Certificate extension schemes are not effective because their remote proof reports remain unchanged and can be directly extracted and appended by attackers. This means that once the TLS key is leaked, its remote proof report does not actually enhance security; or in other words, the remote proof report does not bring any substantial security improvement. (2) Although layer 2 tunnel schemes can effectively isolate confidential network paths and resist relay attacks under TLS key leakage, their implementation usually involves low-level modifications to the network stack, resulting in high deployment complexity. In addition, additional protocol overhead is introduced during tunnel establishment and maintenance, reducing transmission efficiency. (3) Some SSL component extension solutions are also unable to resist the above attacks. For example, if the remote proof report generation and verification part is based only on a static private key, it cannot resist the attack. If the challenge value Nonce of the remote proof report part is the session key of this TLS handshake, it can resist the attack. However, such solutions face problems such as stability risks, difficulty in adapting to multiple versions, incompatibility with existing software, high cost of modifying multiple components, and inability to change SSL components in certain scenarios.

[0041] In summary, all existing solutions have obvious flaws: low-cost solutions cannot resist relay attacks under TLS key leakage, and their security is not substantially better than pure TLS encryption, which can be regarded as an invalid security extension in a sense; while solutions that can effectively resist the attacks have too high a cost to modify the upper-layer software, and are usually difficult to implement in practice.

[0042] Therefore, this application provides a relay attack verification method applied to the client side. It performs network interception and remote authentication verification through a separate process, enabling resistance to relay attacks in TLS key leakage scenarios without modifying existing application software and SSL components. Its core idea is: A separate process monitors the target traffic and parses it to obtain a unique temporary public key. Then, based on this public key, a request for remote proof report verification is sent to the server to be verified. Finally, the server is verified by comparing the public key parsed from the challenge value in the received remote proof report with the aforementioned unique temporary public key.

[0043] Therefore, even if an attacker obtains the unique temporary public key, they cannot deduce the corresponding private key, nor can they calculate the real session key. Thus, they cannot decrypt the communication content or impersonate a legitimate participant. This achieves effective resistance to relay attacks under TLS key leakage and strong protection of session confidentiality, without modifying or changing the code, binary files, or operating logic of the upper-layer software.

[0044] After introducing the design concept of the embodiments of this application, the following is a brief introduction to the application scenarios to which the technical solutions of the embodiments of this application can be applied. It should be noted that the application scenarios described below are only for illustrating the embodiments of this application and are not intended to limit the scope. In specific implementation, the technical solutions provided by the embodiments of this application can be flexibly applied according to actual needs.

[0045] refer to Figure 2This is a schematic diagram of the application scenario of the relay attack verification method provided in the embodiments of this application. The diagram shows application scenarios including the transmission of sensitive information from the connector client to the server, interconnection between confidential environments, and data products providing services to specific connectors, which involve transmitting information to a confidential network or obtaining data in a confidential network.

[0046] Optionally, in the above application scenarios, the end that provides services to the outside world is called the server, and the end that initiates service requests or receives services is called the client. Subsequent embodiments will use the server and client as examples for illustration. It should be noted that the operating systems of the server and client in this application embodiment support Windows 7 and above, as well as most mainstream distributions with Linux kernel 2.7 and above. Furthermore, upper-layer applications can be deployed and run on the server and client respectively. Upper-layer applications deployed on the server include mainstream server-side software, such as HTTPS services, database services, message queue services, etc.; upper-layer applications deployed on the client include mainstream client-side software, such as browsers, database clients, custom business code, etc.

[0047] Of course, the methods provided in the embodiments of this application are not limited to... Figure 2 The application scenarios shown can also be used in other possible scenarios, and this application does not impose any limitations. Figure 2 The functions that the various devices in the application scenarios shown, namely the client and the server, can achieve will be described in the subsequent method embodiments, and will not be elaborated on here.

[0048] To further illustrate the technical solutions provided in the embodiments of this application, a detailed description is provided below in conjunction with the accompanying drawings and specific implementation methods. Although the embodiments of this application provide method operation steps as shown in the following embodiments or drawings, the method may include more or fewer operation steps based on conventional or non-inventive methods. In steps where there is no logically necessary causal relationship, the execution order of these steps is not limited to the execution order provided in the embodiments of this application.

[0049] Before discussing specific solutions, it is necessary to explain some information used in this application.

[0050] ① The IP and PORT of the server providing TLS service are known in advance by both the client and the server (the IP and PORT known by both sides may be different due to factors such as NAT or gateway; however, they are fixed for each side).

[0051] ②The server can open an additional port for the client to initiate a request to obtain a remote proof report.

[0052] ③ The client knows its own IP address when making the request (if it cannot know, the network four-tuple restriction in the subsequent embodiments needs to be replaced with a three-tuple restriction of client PORT, server IP, and server PORT, which has the same effect).

[0053] Specifically: First, the IP address and port number used by the server to provide TLS services are known in advance by both the client and the server. Due to factors such as NAT or gateways, the IP address and port number known to both parties may differ, but they are fixed values ​​for each party. Second, the server can open an additional port to receive remote proof report retrieval requests initiated by the client and to send the corresponding remote proof report to the client based on that port.

[0054] The following is combined Figure 2 The application scenario shown illustrates how a client (e.g., a connector client) transmits sensitive information to a server, and provides a detailed explanation of the technical solution provided in the embodiments of this application.

[0055] This application embodiment mainly includes scenarios involving server-side authentication (in which reasonable traffic hijacking is performed on the client side), client-side authentication (in which reasonable traffic hijacking is performed on the server side), and two-way authentication (in which reasonable traffic hijacking is performed on both the client and server sides). In practical applications, server-side authentication is the more common scenario; therefore, the following section will mainly describe the server-side authentication process in detail, while the client-side authentication and two-way authentication processes will also be briefly described. Furthermore, this application embodiment uses a single TLS service as an example; in practical applications, this can be extended to multiple TLS services, which will not be elaborated here.

[0056] Based on the above assumptions, refer to Figure 3 This application provides a relay attack verification method, applied to a client, comprising the following steps: S301: The client's first process listens to the target traffic and parses the target traffic to obtain the first public key.

[0057] S302: The client's first process sends the first request to the server based on the first public key.

[0058] S303: The client's first process receives the first remote authentication report sent by the server according to the first request, and verifies the server by determining whether the public key parsed from the first remote authentication report is the same as the first public key.

[0059] In this embodiment, the client's first process listens to the target traffic and parses it to obtain the first public key. Then, based on this first public key, it sends a remote authentication request to the server. Finally, server authentication is completed by comparing the public key parsed from the first remote authentication report returned by the server with the first public key. The technical solution provided by this embodiment not only effectively resists relay attacks under TLS key leakage and strongly protects session confidentiality, but also requires no modification to the code, binary files, or runtime logic of the upper-layer software.

[0060] Optionally, the first process of the client in S301 used to monitor target traffic can be implemented using custom programming or mature tools such as Wireshark. By limiting the source IP and source port of the tool to the IP and port of the local TLS service, it can monitor all traffic related to the local TLS service.

[0061] In order to achieve refined and differentiated control of data traffic by the client in this embodiment, the first process of the client specifically includes two coexisting implementation scenarios: an audit mode for recording and source analysis, and a blocking mode for real-time risk interception.

[0062] Optionally, if the current mode is audit mode, the target traffic is the first handshake traffic; if the current mode is blocking, the target traffic is the traffic queue.

[0063] Specifically, the first handshake traffic and the traffic queue are both TLS Server Hello handshake traffic. This TLS Server Hello handshake traffic is a handshake message sent by the server after responding to the client's handshake request, used to negotiate the session key and related security parameters. The interaction process between the client and the server in making the handshake request (including but not limited to protocol version negotiation, random number exchange, cipher suite negotiation, etc.) is the same as the handshake process specified in the existing TLS protocol standard, and will not be described in detail here.

[0064] If the current mode is blocking, the traffic queue is determined as follows: Determine the first condition and the second condition; wherein, the first condition determines that the IP of the TLS service is the destination IP of the configuration tool, and determines that the port of the TLS service is the destination port of the configuration tool; the second condition determines that the IP of the TLS service is the source IP of the configuration tool, and determines that the port of the TLS service is the source port of the configuration tool. Monitor the first flow rate that meets the first condition, and the second flow rate that meets the second condition; wherein the first flow rate and the second flow rate constitute a flow queue.

[0065] Optionally, depending on the operating system, the configuration tool includes, but is not limited to, existing tools such as NFQueue or WinDivert. NFQueue is suitable for Linux systems and can intercept, temporarily store, and process user-space network traffic based on the kernel Netfilter framework. WinDivert is suitable for Windows systems and can capture, intercept, modify, and control the forwarding of IP layer and transport layer traffic through a kernel-level network filtering driver. Using these tools, precise monitoring and security verification of the target TLS Server Hello handshake traffic can be achieved without modifying the upper-layer application code, binary files, or runtime logic.

[0066] Optionally, if the current mode is blocking and the target traffic is a traffic queue, involving S301, the target traffic is parsed to obtain the first public key, which can be achieved through steps A1-A2: A1: Analyze the traffic queue to determine the local port, local IP, and session status; A2: Determine the first public key based on the traffic type of the traffic queue, as well as the local port, local IP, and session state.

[0067] The traffic types include SYN (synchronization sequence number) handshake, TLS server handshake, and part or all of the TCP (Transmission Control Protocol) session termination.

[0068] Optionally, the client's first process determines the first public key based on a constructed target table, which stores at least one corresponding local IP, local port, and session state obtained by parsing historical traffic queues. The session state includes some or all of the following: TLS key not obtained, TLS handshake information obtained, NIRA-TLS verification passed, and NIRA-TLS verification failed.

[0069] It should be noted that in this embodiment of the application, the ECDHE public key used by TLS 1.3 is used as the first public key, so the specific value of the first public key is not a fixed value, because its generation process is dynamic and changes dynamically with each TLS handshake and key exchange process.

[0070] Furthermore, regarding A2, based on the traffic type of the traffic queue, as well as the local port, local IP, and session state, the first public key is determined through steps A2-1 to A2-4: A2-1: If the traffic type is TLS handshake traffic, check whether the target table includes the local IP and local port parsed this time. If they exist and the corresponding session state is "TLS key not obtained", change the session state to "TLS key obtained" and extract the first public key; if they do not exist or the corresponding session state is not "TLS key not obtained", trigger an abnormal alarm. A2-2: If the traffic type is SYN handshake traffic, determine whether the target table includes the local IP and local port resolved this time. If not, store the local IP and local port resolved this time into the target table and mark the current status as TLS key not obtained. Otherwise, trigger an abnormal alarm. A2-3: If the traffic type is TCP session termination information, then determine whether the target table includes the local IP and local port resolved this time. If they exist, delete the local IP and local port resolved this time from the target table. A2-4: If the traffic is any of the following: TCP handshake phase traffic, TLS handshake phase traffic, or ACK return packet with no actual content, then allow the traffic queue to pass. Otherwise, if the current state is NIRA-TLS verification successful, then send the traffic; if the current state is that TLS handshake information has been obtained, then postpone the processing order of the traffic queue; if the current state is that NIRA-TLS verification failed, then discard the traffic queue and trigger the construction of an RST packet.

[0071] Optionally, steps A1-A2 can be implemented using corresponding algorithms. Specific implementation details are not described in detail here. Those skilled in the art can complete the implementation using conventional algorithm design and implementation methods based on the content disclosed in this application, without departing from the protection scope of this application.

[0072] refer to Figure 4 This application provides a relay attack verification method, applied to the server side, including: S401: The second process on the server listens to the first handshake traffic, parses the first handshake traffic, and obtains the second public key; S402: The second process on the server generates a first remote proof report based on the second public key; S403: The second process on the server receives the first request from the client, parses the first request, obtains the first public key, and if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, the first remote proof report is sent to the client so that the client can verify the server by judging whether the public key parsed from the first remote proof report is the same as the second public key.

[0073] In this embodiment, a second process listens to the first handshake traffic and parses it to obtain the second public key. Based on this, a first remote proof report is pre-generated. When a request carrying the first public key is received from a client, it is further determined whether the time interval between the generation of the first and second public keys is less than a set threshold. The remote proof report is only sent to the client if the timeliness condition is met. By using time window verification, it is ensured that each proof report is only valid for the current session, thereby effectively resisting relay attacks. At the same time, the server and client use peer-to-peer traffic parsing logic, which does not require modification of the upper-layer application or TLS protocol stack, reducing real-time response overhead and achieving low-cost, lightweight integrated deployment.

[0074] Optionally, the second process of the server in S401 used to listen to the first handshake traffic can be implemented by programming or by using mature tools such as Wireshark. Its implementation principle is the same as the aforementioned related content, and will not be repeated here.

[0075] Optionally, the first handshake traffic is TLS Server Hello handshake traffic. This TLS Server Hello handshake traffic is a handshake message sent by the server after responding to the client's handshake request, used to negotiate the session key and related security parameters. The interaction process between the client and the server in requesting the handshake (including but not limited to protocol version negotiation, random number exchange, cipher suite negotiation, etc.) is the same as the handshake process specified in the existing TLS protocol standard, and will not be described in detail here.

[0076] Specifically, regarding S402, the second process on the server side generates a first remote proof report based on the second public key, including: The first process on the server side uses the second public key as a random value and generates a first remote proof report based on the random value.

[0077] In this embodiment, the ECDHE public key used by TLS 1.3 is used as the random value Nonce in the remote proof report. The consistency and timeliness verification of the ECDHE public key are necessary conditions for the server to send the remote proof report. Both conditions must be met simultaneously and neither can be omitted. If either condition is not met, the server will refuse to respond to the request in order to ensure the security and validity of the remote proof.

[0078] Regarding the scope of the process in this application embodiment, it should be noted that the above steps only cover the server-side operations related to remote proof report generation, request reception, public key verification, and response. After the second process on the server side completes the response (or ignore) operation in step S403, this process terminates, and subsequent client verification operations are unrelated to the server.

[0079] refer to Figure 5This is a system architecture diagram of a secure network implementation system against relay attacks according to an embodiment of this application, including client 501 and server 502, wherein: The aforementioned client 501, through the first process, performs the following: listens to target traffic, parses the target traffic to obtain the first public key; sends a first request to the server based on the first public key; receives the first remote proof report sent by the server based on the first request, and verifies the server by determining whether the public key parsed from the first remote proof report is the same as the first public key; The aforementioned server 502, implemented through a second process, performs the following: listens to the first handshake traffic and parses it to obtain the second public key; generates a first remote proof report based on the second public key; receives a first request from the client, parses it to obtain the first public key, and if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, sends the first remote proof report to the client so that the client can verify the server by judging whether the public key parsed from the first remote proof report is the same as the second public key.

[0080] This application embodiment independently monitors TLS handshake traffic on both the client and server sides, dynamically extracts the unique ECDHE public key for each session as the random value (Nonce) for the remote proof report, and combines this with a time window verification mechanism to prevent attackers from replaying previously intercepted proof reports to pass verification, thus effectively resisting relay attacks. Furthermore, this solution does not rely on a third-party CA, requires no modification to any upper-layer application code or runtime logic, and achieves end-to-end session confidentiality assurance simply by capturing and processing traffic through an independent process. It is also compatible with Linux / Windows operating systems and various TLS software, achieving a harmonious balance between lightweight deployment, broad compatibility, and high security.

[0081] refer to Figure 6 This is a flowchart illustrating the interaction process of a verification server in blocking mode, as provided in an embodiment of this application. Figure 6 It should include at least the following steps: S601-1: The first process of the client determines the IP of the local TLS service as the source IP and the port of the local TLS service as the source port, and listens for the traffic queue received by the source IP through the source port; if the traffic includes TLS ServerHello handshake traffic, the handshake traffic is parsed and the first ECDHE public key is obtained. S601-2: The second process on the server side determines the IP of the local TLS service as the source IP and the port of the local TLS service as the source port, and listens for traffic sent by the source IP through the source port; S602-1: The first process of the client parses the obtained traffic queue and executes steps A2-1 to A2-4; wherein, it determines the IP, port and corresponding first ECDHE public key that need to be remotely verified, and sends a first request to the corresponding server to request a remote verification report based on the first ECDHE public key: S602-2: The second process on the server side parses the obtained TLS Server Hello traffic, obtains the corresponding second ECDHE public key, and generates the corresponding remote proof report based on the second ECDHE public key; wherein, the random value Nonce in the remote proof report is the second ECDHE public key; S603: If the second process on the server receives a first request sent by the first process on the client based on the first ECDHE public key, it parses the first request to obtain the corresponding first ECDHE public key. If the time interval between the generation time of the first ECDHE public key and the generation time of the second ECDHE public key is less than a set time threshold, it sends the remote proof report to the corresponding client. S604: The first process of the client receives a remote verification report from the server. It verifies the server by determining whether the random value Nonce in the remote verification report, i.e., the second ECDHE public key, is the same as the first ECDHE public key. If it is invalid, an alarm message is recorded.

[0082] The above embodiment describes the verification process on the server side. The verification process on the client side will be described next.

[0083] In audit mode, the server and client processes no longer listen to TLS Server Hello handshake traffic, but instead listen to TLS Client Hello handshake traffic. The client's first process generates a corresponding remote proof report based on the ECDHE public key obtained by parsing the TLS Client Hello handshake traffic. The random value Nonce of this remote proof report is the ECDHE public key, and the remote proof report is sent directly to the corresponding server. The server's second process verifies the random value Nonce of the remote proof report, i.e., the time interval between the generation time of the ECDHE public key and the generation time of the ECDHE public key obtained by the server locally parsing the TLS Client Hello handshake traffic is less than a set time threshold. If so, and the ECDHE public keys are the same, otherwise, a corresponding alarm message will be generated.

[0084] In blocking mode, the system also listens for TLS Client Hello handshake traffic. The steps performed by the first client process are the same as in auditing mode, and will not be repeated here. For the second server process, it listens for a traffic queue, and the processing of traffic in this queue is the same as the client processing steps mentioned above. For details, please refer to steps A1-A2 and steps A2-1 to A2-4 above, which will not be repeated here.

[0085] Figure 7 This application provides an example of an interaction flowchart for verifying a client in blocking mode. Figure 7 It should include at least the following steps: S701-1: The first process of the client determines the IP of the local TLS service as the source IP and the port of the local TLS service as the source port. When listening for TLS Client Hello handshake traffic received by the source IP through the source port, it parses the handshake traffic and obtains the first ECDHE public key. S701-2: The second process on the server side determines the IP of the local TLS service as the source IP and the port of the local TLS service as the source port, listens for the traffic queue sent by the source IP through the source port, and executes steps A2-1 to A2-4; wherein, the IP, port and corresponding second ECDHE public key that need to be remotely verified are determined. S702: The first process of the client generates a corresponding remote proof report based on the first ECDHE public key and sends the remote proof report to the corresponding server; wherein, the random value Nonce in the remote proof report is the first ECDHE public key; S703: The second process on the server receives the remote verification report sent by the first process on the client. It verifies the server by determining whether the time interval between the generation time of the first ECDHE public key and the generation time of the second ECDHE public key obtained by parsing the TLS Client Hello handshake traffic on the server is less than a set time threshold, and whether the first ECDHE public key and the second ECDHE public key are the same. If valid, the verification result is returned to the corresponding client; if invalid, an alarm message is recorded.

[0086] In this embodiment, corresponding to the client-server verification method, the method also uses a dynamically extracted ECDHE public key as the random value Nonce in the remote proof report. Combined with timeliness verification, this prevents attackers from intercepting the client's remote proof report for relay attacks. Furthermore, this scheme requires no modification to the client's upper-layer application code or runtime logic; verification can be completed simply by capturing TLS Client Hello traffic through an independent process. In blocking mode, the server reuses the same traffic queue processing framework as the client, achieving a high degree of code symmetry and reuse, thus reducing system implementation complexity.

[0087] Optionally, in this embodiment of the application, a two-way authentication between the client and the server is also included, wherein: In audit mode, both the client and server listen to both TLS Client Hello handshake traffic and TLS Server Hello handshake traffic. Specifically, the client's first process generates a corresponding remote proof report based on the ECDHE public key obtained from parsing the TLS Client Hello handshake traffic and sends it to the corresponding server, as well as sending a request to the server for the corresponding remote proof report based on the ECDHE public key obtained from parsing the TLS Server Hello handshake traffic. The server's second process generates a corresponding remote proof report based on the ECDHE public key obtained from parsing the TLS Server Hello handshake traffic. Furthermore, the method by which the client and server verify the other party's remote proof report is the same as the aforementioned verification method and will not be repeated here.

[0088] In blocking mode, both the client and server listen to the traffic queue, and the processing of traffic in the corresponding traffic queue is the same as the steps for client and server processing mentioned above. For details, please refer to steps A1-A2 and steps A2-1 to A2-4 above, which will not be repeated here.

[0089] Figure 8 This application provides an interactive flowchart of a two-way verification process in blocking mode, as shown in the embodiments of this application. Figure 8 It should include at least the following steps: S801-1: The first process of the client determines the IP of the local TLS service as the source IP and the port of the local TLS service as the source port, listens for the traffic queue received by the source IP through the source port, and executes steps A2-1 to A2-4; wherein, if the traffic includes TLS Server Hello handshake traffic, the handshake traffic is parsed and the first ECDHE public key is obtained. S801-2: The second process on the server side determines the IP of the local TLS service as the source IP and the port of the local TLS service as the source port, listens for the traffic queue sent by the source IP through the source port, and executes steps A2-1 to A2-4; wherein, the IP, port and corresponding second ECDHE public key that need to be remotely verified are determined. S802: The first process of the client sends a first request to the corresponding server to request a remote proof report based on the first ECDHE public key; wherein, the random value Nonce in the remote proof report is the first ECDHE public key, and a corresponding remote proof report is generated based on the first ECDHE public key, and the remote proof report is sent to the corresponding server. S803-1: If the second process on the server receives a first request sent by the first process on the client based on the first ECDHE public key, it parses the first request to obtain the corresponding first ECDHE public key. If the time interval between the generation time of the first ECDHE public key and the generation time of the second ECDHE public key is less than a set time threshold, it sends the remote proof report to the corresponding client. S803-2: The second process on the server receives the remote verification report sent by the first process on the client. It verifies the server by determining whether the time interval between the generation time of the first ECDHE public key and the generation time of the second ECDHE public key obtained by parsing the TLS Client Hello handshake traffic on the server is less than a set time threshold, and whether the first ECDHE public key and the second ECDHE public key are the same. If it is valid, the verification result is returned to the corresponding client. If it is invalid, an alarm message is recorded. S803-3: The first process of the client receives a remote authentication report from the server. It verifies the server by determining whether the random value Nonce in the remote authentication report, i.e., the second ECDHE public key, is the same as the first ECDHE public key. If it is invalid, an alarm message is recorded.

[0090] The technical solution of this application embodiment, without modifying the upper-layer application, simultaneously achieves resistance to relay attacks, protection of session confidentiality, and trusted verification of the server's identity, and has the following effects compared to the prior art: (1) It can effectively resist relay attacks. Since the first public key is temporary and unique, it is different for each session. Attackers cannot pass the verification by replaying the previously intercepted legitimate proof report, because the public key parsed from the replay report will inevitably be inconsistent with the first public key of the current session, thus making it naturally immune to relay attacks from the protocol level. (2) Strong protection of session confidentiality. The first public key comes from the real target traffic. The remote proof process essentially verifies the server’s ability to hold the corresponding private key. Only the real server can respond to the request correctly, thereby achieving end-to-end session encryption and confidentiality protection, and preventing man-in-the-middle eavesdropping. (3) No modifications are required to the upper-layer software. The entire verification process is completed independently by the first process of the client. The source code, binary files and running logic of the upper-layer application remain unchanged, which greatly reduces the deployment threshold and migration cost and has good compatibility and universality. (4) It achieves lightweight and proactive server-side authentication, without relying on third-party certificate authorities or complex certificate revocation list maintenance, and is especially suitable for resource-constrained or complex network environments such as the Internet of Things and edge computing.

[0091] like Figure 9 As shown, based on the same inventive concept as the relay attack verification method applied to the client described above, this application embodiment also provides a relay attack verification device applied to the client, the device including a first processing unit 91 and a first transmission unit 92: The first processing unit 91 is used to: monitor the target traffic and parse the target traffic to obtain the first public key; The first transmission unit 92 is used to: send a first request to the server based on the first public key; The first transmission unit 92 is further configured to: receive a first remote certification report sent by the server in accordance with the first request; The first processing unit 91 is further configured to: verify the server by determining whether the public key parsed from the first remote proof report is the same as the first public key.

[0092] In one alternative implementation, if the current mode is audit mode, the target traffic is the first handshake traffic; if the current mode is blocking, the target traffic is the traffic queue; both the first handshake traffic and the traffic queue are TLS Server Hello handshake traffic.

[0093] In one alternative implementation, the traffic queue is determined by the first processing unit 91 in the following manner: Determine the first condition and the second condition; wherein, the first condition determines that the IP of the TLS service is the destination IP of the configuration tool, and determines that the port of the TLS service is the destination port of the configuration tool; the second condition determines that the IP of the TLS service is the source IP of the configuration tool, and determines that the port of the TLS service is the source port of the configuration tool. Monitor the first flow rate that meets the first condition, and the second flow rate that meets the second condition; wherein the first flow rate and the second flow rate constitute a flow queue.

[0094] In one optional implementation, the first processing unit 91 is specifically used for: Analyze the traffic queue to determine the local port, local IP, and session status; The first public key is determined based on the traffic type of the traffic queue, as well as the local port, local IP, and session state.

[0095] In one alternative implementation, the traffic type includes SYN handshake, TLS server handshake, and part or all of the TCP session termination; The first processing unit 91 is specifically used for: If the traffic type is TLS handshake traffic, check whether the target table includes the local IP and local port parsed this time. If they exist and the corresponding session status is "TLS key not obtained", change the session status to "TLS key obtained" and extract the first public key. If they do not exist or the corresponding session status is not "TLS key not obtained", trigger an abnormal alarm. The target table stores at least one set of corresponding local IP, local port and session status obtained from parsing the historical traffic queue. The session status includes some or all of the following: TLS key not obtained, TLS handshake information obtained, NIRA-TLS verification passed, and NIRA-TLS verification failed.

[0096] In an optional implementation, the first processing unit 91 is specifically used to: if the traffic type is SYN handshake traffic, determine whether the target table includes the local IP and local port parsed this time; if not, store the local IP and local port parsed this time into the target table and mark the current status as TLS key not obtained; otherwise, trigger an abnormal alarm. If the traffic type is TCP session termination information, check whether the target table includes the local IP and local port resolved this time. If they exist, delete the local IP and local port resolved this time from the target table. If the traffic is any of the following: TCP handshake phase traffic, TLS handshake phase traffic, or ACK return packets without actual content, the traffic queue is allowed. Otherwise, if the current state is NIRA-TLS verification successful, the traffic is sent; if the current state is that TLS handshake information has been obtained, the processing order of the traffic queue is postponed; if the current state is that NIRA-TLS verification failed, the traffic queue is discarded and the construction of an RST packet is triggered.

[0097] The relay attack verification device proposed in this application adopts the same inventive concept as the relay attack verification method applied to the client described above, and can achieve the same beneficial effects, so it will not be described again here.

[0098] like Figure 10 As shown, based on the same inventive concept as the relay attack verification method applied to the server described above, this application also provides another relay attack verification device applied to the server. This device includes a second processing unit 101 and a second transmission unit 102. The second processing unit 101 is used to: listen to the first handshake traffic and parse the first handshake traffic to obtain the second public key; The second processing unit 101 is further configured to: generate a first remote proof report based on the second public key; The second transmission unit 102 is configured to: receive a first request from a client; The second processing unit 101 is further configured to: parse the first request to obtain the first public key; The second transmission unit 102 is further configured to: if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, send the first remote proof report to the client so that the client can verify the server by judging whether the public key parsed from the first remote proof report is the same as the second public key.

[0099] In one alternative implementation, the first handshake traffic is the TLS Server Hello handshake traffic.

[0100] In one optional implementation, the second processing unit 101 is specifically used for: The second process on the server side uses the second public key as a random value and generates a first remote proof report based on the random value.

[0101] The relay attack verification device proposed in this application adopts the same inventive concept as the relay attack verification method applied to the server described above, and can achieve the same beneficial effects, so it will not be described again here.

[0102] Based on the same inventive concept as the relay attack verification method described above, this application also provides an electronic device, which can specifically be a desktop computer, portable computer, smartphone, tablet computer, or personal digital assistant (PDA), wherein a client can be integrated, and the electronic device can also be a server, etc. Figure 11 As shown, the electronic device may include a processor 111 and a memory 112.

[0103] Processor 111 can be a general-purpose processor, such as a central processing unit (CPU), digital signal processor (DSP), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic device, or discrete hardware component, capable of implementing or executing the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or executed by a combination of hardware and software modules within the processor.

[0104] Memory 112, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules. Memory may include at least one type of storage medium, such as flash memory, hard disk, multimedia card, card-type memory, random access memory (RAM), static random access memory (SRAM), programmable read-only memory (PROM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), magnetic memory, magnetic disk, optical disk, etc. Memory is any other medium capable of carrying or storing desired program code in the form of instructions or data structures that can be accessed by a computer, but is not limited thereto. Memory 112 in this embodiment may also be a circuit or any other device capable of implementing storage functions for storing program instructions and / or data.

[0105] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned computer storage medium can be any available medium or data storage device that a computer can access, including but not limited to: mobile storage devices, random access memory (RAM), magnetic storage (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical storage (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor storage (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs)) and other media capable of storing program code.

[0106] Alternatively, if the integrated units described above in this application are implemented as software functional modules and sold or used as independent products, they can also be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods of the various embodiments of this application. The aforementioned storage medium includes: mobile storage devices, random access memory (RAM), magnetic memory (e.g., floppy disks, hard disks, magnetic tapes, magneto-optical disks (MO), etc.), optical memory (e.g., CDs, DVDs, BDs, HVDs, etc.), and semiconductor memory (e.g., ROMs, EPROMs, EEPROMs, non-volatile memory (NAND flash), solid-state drives (SSDs), etc.) and other media capable of storing program code.

[0107] Based on the same inventive concept, this application also provides a computer program product, which includes computer program code. When the computer program code is run on a computer, it causes the computer to execute any of the relay attack verification methods discussed above. Since the principle by which the above computer program product solves the problem is similar to that of the relay attack verification method, the implementation of the above computer program product can refer to the implementation of the method, and repeated details will not be described again.

[0108] The above embodiments are only used to provide a detailed description of the technical solutions of this application. However, the description of the above embodiments is only for the purpose of helping to understand the methods of the embodiments of this application and should not be construed as a limitation on the embodiments of this application. Any changes or substitutions that can be easily conceived by those skilled in the art should be covered within the protection scope of the embodiments of this application.

Claims

1. A relay attack verification method, characterized in that, Applied to the client side, including: The first process of the client listens to the target traffic and parses the target traffic to obtain the first public key; The first process of the client sends a first request to the server based on the first public key; The first process of the client receives the first remote proof report sent by the server according to the first request, and verifies the server by determining whether the public key parsed from the first remote proof report is the same as the first public key.

2. The method according to claim 1, characterized in that, If the current mode is audit mode, then the target traffic is the first handshake traffic; If the current mode is blocking, then the target traffic is a traffic queue; Both the first handshake traffic and the traffic queue are TLS Server Hello handshake traffic.

3. The method according to claim 2, characterized in that, The traffic queue is determined in the following way: Determine a first condition and a second condition; wherein, the first condition determines that the IP of the TLS service is the destination IP of the setting tool, and determines that the port of the TLS service is the destination port of the setting tool; the second condition determines that the IP of the TLS service is the source IP of the setting tool, and determines that the port of the TLS service is the source port of the setting tool. Monitor a first flow that meets the first condition, and a second flow that meets the second condition; wherein the first flow and the second flow constitute the flow queue.

4. The method according to claim 2, characterized in that, The target traffic is a traffic queue, and the process of parsing the target traffic to obtain the first public key includes: The traffic queue is parsed to determine the local port, local IP, and session status; The first public key is determined based on the traffic type of the traffic queue, the local port, the local IP, and the session state.

5. The method according to claim 4, characterized in that, The traffic types include SYN handshake, TLS server handshake, and part or all of the TCP session termination; The step of determining the first public key based on the traffic type of the traffic queue, the local port, the local IP, and the session state includes: If the traffic type is TLS handshake traffic, then determine whether the target table includes the local IP and local port parsed this time. If they exist and the corresponding session status is "TLS key not obtained", then change the session status to "TLS key obtained" and extract the first public key. If they do not exist or the corresponding session status is not "TLS key not obtained", then trigger an abnormal alarm. The target table stores at least one set of corresponding local IP, local port and session status obtained by parsing the historical traffic queue. The session status includes some or all of the following: TLS key not obtained, TLS handshake information obtained, NIRA-TLS verification passed, and NIRA-TLS verification failed.

6. The method according to claim 5, characterized in that, The step of determining the first public key based on the traffic type of the traffic queue, the local port, the local IP, and the session state includes: If the traffic type is SYN handshake traffic, then determine whether the target table includes the local IP and local port parsed this time. If not, store the local IP and local port parsed this time into the target table and mark the current status as TLS key not obtained. Otherwise, trigger an abnormal alarm. If the traffic type is TCP session termination information, then determine whether the target table includes the local IP and local port parsed this time. If it exists, delete the local IP and local port parsed this time from the target table. If the traffic is any one of the following: TCP handshake phase traffic, TLS handshake phase traffic, or ACK return packet with no actual content, then the traffic queue is allowed to pass. Otherwise, if the current state is NIRA-TLS verification successful, then the traffic is sent; if the current state is that TLS handshake information has been obtained, then the processing order of the traffic queue is postponed; if the current state is that NIRA-TLS verification failed, then the traffic queue is discarded and the construction of an RST packet is triggered.

7. A relay attack verification method, characterized in that, Applied to the server side, including: The second process on the server listens to the first handshake traffic and parses the first handshake traffic to obtain the second public key; The second process on the server generates a first remote proof report based on the second public key; The second process of the server receives a first request from the client, parses the first request to obtain a first public key, and if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, then the first remote proof report is sent to the client so that the client can verify the server by judging whether the public key parsed from the first remote proof report is the same as the second public key.

8. The method according to claim 7, characterized in that, The first handshake traffic is the TLS Server Hello handshake traffic.

9. The method according to claim 7, characterized in that, The second process on the server generates a first remote proof report based on the second public key, including: The second process on the server side uses the second public key as a random value and generates the first remote proof report based on the random value.

10. A relay attack verification device, characterized in that, For use on a client, the device includes: The first processing unit is configured to: monitor target traffic and parse the target traffic to obtain a first public key; The first transmission unit is configured to: send a first request to the server based on the first public key; The first transmission unit is further configured to: receive a first remote authentication report sent by the server in accordance with the first request; The first processing unit is further configured to: verify the server by determining whether the public key parsed from the first remote proof report is the same as the first public key.

11. A relay attack verification device, characterized in that, For use on the server side, the device includes: The second processing unit is configured to: monitor the first handshake traffic and parse the first handshake traffic to obtain the second public key; The second processing unit is further configured to: generate a first remote proof report based on the second public key; The second transmission unit is configured to: receive a first request from the client; The second processing unit is further configured to: parse the first request to obtain the first public key; The second transmission unit is further configured to: if the time interval between the generation time of the first public key and the generation time of the second public key is less than a set time threshold, send the first remote proof report to the client, so that the client can verify the server by judging whether the public key parsed from the first remote proof report is the same as the second public key.

12. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 9.

13. A computer-readable storage medium having computer program instructions stored thereon, characterized in that, When executed by a processor, the computer program instructions implement the steps of the method according to any one of claims 1 to 9.

Images