Intranet penetration end-to-end encryption method based on TLS protocol

Abstract

The invention relates to an intranet penetration end-to-end encryption method based on a TLS protocol. The method comprises the following steps: establishing a TCP tunnel between an intranet client and an edge node server of an extranet; after the intranet client receives the TLS handshake request from the edge node server through the TCP tunnel, the intranet client establishes the TCP tunnel with the intranet service and transmits the TLS handshake request to the intranet service in an unvarnished manner; the intranet client side forwards a Server Hello message, an encrypted message and a Certifiate message from an intranet service to the edge node server side; the intranet client transparently transmits the TLS encrypted message from the edge node server to an intranet service through a TCP tunnel; and the intranet client transparently transmits a response TLS encrypted message from the intranet service to the edge node server through the TCP tunnel. Compared with the prior art, the method has the advantages of realizing full coverage of an encryption process, ensuring safe and controllable access and the like.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and in particular to an end-to-end encryption method for intranet penetration based on the TLS protocol. Background Technology

[0002] Currently, traditional intranet penetration service providers mainly use the following two methods to handle users' TLS-encrypted traffic such as HTTPS and WSS: Method 1: TLS resources (such as certificates and private keys) are provided and managed by the intranet penetration service provider, and TLS terminates at the service provider's external network edge node, such as... Figure 1 As shown in the diagram. Using a penetration service provider's public network node and an internal network client, the penetration service provider's internal network client actively connects to the public network node. The public network node deploys the penetration service provider's TLS resources. When TLS traffic reaches the public network node, the penetration service provider decrypts it using the deployed TLS resources and simultaneously transmits the decrypted plaintext traffic to the internal network client. The internal network client then forwards the plaintext traffic to the user's internal network service. Throughout this process, the user does not provide any TLS resources (such as certificates / private keys), and the user always receives plaintext data traffic. In method 1, TLS terminates at the service provider's external network edge node. Communication is not end-to-end encrypted. The network security from the external network edge node to the customer's internal network depends on the penetration service provider's own technical capabilities, and there is a risk of traffic interception or man-in-the-middle attacks. Furthermore, if the service provider's certificate is used for data encryption and decryption, there is theoretically a risk of data leakage.

[0003] Method 2: The user provides TLS resources, which terminate at the intranet client of the intranet penetration service provider within the user's intranet environment, such as... Figure 2 As shown in the diagram. In Method 2, the public network node (i.e., the external network edge node) of the penetration service provider only performs TLS pass-through. Upon receiving TLS traffic, the public network node does not perform any decryption operations but instead transmits the encrypted TLS traffic to the user's internal network environment. The penetration service provider's client is deployed in the internal network environment. The client reads the user's TLS resources in the internal network environment, performs TLS decryption, and then transmits the decrypted traffic to the user's internal network service. Throughout this process, TLS only terminates in the user's internal network environment. The user needs to provide the corresponding TLS resources to the penetration service provider's internal network client for reading and loading. The public network stage always transmits TLS-encrypted traffic. In Method 2, the traffic in the public network stage is always TLS traffic, but the user still needs to provide the TLS resources to the penetration service provider's internal network client for reading. This means that the penetration service provider has the ability to decrypt user traffic and view private data in the internal network environment, and the data still faces security risks.

[0004] How to achieve end-to-end encryption in intranet penetration scenarios has become a technical problem that needs to be solved. Summary of the Invention

[0005] The purpose of this invention is to overcome the shortcomings of the existing technology and provide an end-to-end encryption method for intranet penetration based on the TLS protocol.

[0006] The objective of this invention can be achieved through the following technical solutions: According to a first aspect of the present invention, an end-to-end encryption method for intranet penetration based on the TLS protocol is provided. The method is applied to an intranet client and includes: the intranet client establishing a TCP tunnel with an edge node server of an external network. After receiving the TLS handshake request from the edge node server through the TCP tunnel, the intranet client establishes a TCP tunnel with the intranet service and forwards the TLS handshake request to the intranet service. The intranet client forwards the ServerHello, encrypted information, and Certificate messages from the intranet service to the edge node server. The intranet client transmits TLS-encrypted messages from the edge node server to the intranet service through a TCP tunnel; The intranet client transmits the TLS-encrypted response message from the intranet service to the edge node server via a TCP tunnel.

[0007] Preferably, the intranet client sends configured intranet service information to the edge node server through a TCP tunnel, wherein the intranet service information includes a domain name, intranet client ID, and intranet service address.

[0008] More preferably, after receiving the TLS handshake request, the intranet client resolves the intranet service address corresponding to the domain name according to the configuration and sends a TCP connection request to the corresponding intranet service.

[0009] More preferably, when the configuration changes, the intranet client sends the newly configured intranet service information to the edge node server via hot update.

[0010] According to a second aspect of the present invention, an end-to-end encryption method for intranet penetration based on the TLS protocol is provided. The method is applied to an edge node server on an external network, wherein the edge node server establishes a TCP tunnel with an intranet client. The edge node server receives and agrees to the TCP handshake request from the visitor; The edge node server transmits the TLS handshake request from the visitor to the internal network client; The edge node server forwards ServerHello, encrypted information, and Certificate messages to the visitor. The edge node server transmits TLS-encrypted messages from visitors to intranet clients via a TCP tunnel. The edge node server transmits the TLS-encrypted response message from the internal network client to the visitor via a TCP tunnel.

[0011] Preferably, the edge node server stores intranet service information from intranet clients, and the intranet service information includes intranet client ID, domain name, and intranet service address; The edge node server maintains a unique mapping relationship for each domain name, forming a local mapping table.

[0012] More preferably, after receiving the TLS handshake request from the visitor, the edge node server extracts the SNI and domain name information from the plaintext portion of TLSClientHello and checks whether there is corresponding domain name information in the local mapping table; if there is no matching information, a new domain name is added; if the domain name matches successfully, the configuration information is read from the local mapping table, and the established TCP tunnel to the intranet client is found.

[0013] When the configuration changes, the edge node server receives the newly configured intranet service information from the intranet client via hot update.

[0014] According to a third aspect of the present invention, an end-to-end encryption method for intranet penetration based on the TLS protocol is provided. The method is applied to an intranet service, wherein the intranet service agrees to a TLS handshake request from an intranet client through a TCP tunnel and then returns a ServerHello and determined encryption information to the intranet client. The intranet service decrypts the received encrypted TLS message according to the agreed encryption and decryption method, and after decrypting the data, sends the corresponding TLS encrypted message to the intranet client.

[0015] Preferably, the intranet server also sends a Certificate message to the intranet client.

[0016] Compared with the prior art, the present invention has the following beneficial effects: 1) In the intranet penetration scenario, the intranet client and edge node server of the present invention only serve as a transparent transmission channel for encrypted data. At any stage, there is no need to collect, store or parse the client's TLS private key. The TLS private key is managed by the client and deployed at the upstream service of the intranet, realizing end-to-end encryption. This fundamentally avoids the risk of data decryption caused by private key leakage, solves the risks of leakage and decryption caused by the collection of TLS by the service provider in the traditional mode, and ensures secure and controllable access.

[0017] 2) In the field of intranet penetration, this invention enables TLS termination at the user's intranet service side. Users can use their own certificates and control their private keys, ensuring full coverage of the encryption process. Decryption occurs at the user's intranet service, avoiding the risk of man-in-the-middle attacks.

[0018] 3) In this invention, all TLS handshake data is forwarded from the intranet client to the user's intranet as raw TCP data streams. The user's upstream services are compatible with any TLS protocol, which is highly flexible.

[0019] 4) The intranet client of this invention supports hot updates of configuration, allowing users to dynamically modify mapping relationships and interaction configurations in real time without restarting the client. Attached Figure Description

[0020] Figure 1 This is a schematic diagram illustrating the interaction process of existing TLS termination at the external network edge node; Figure 2 This is a schematic diagram illustrating the interaction process of existing TLS termination at the intranet client. Figure 3 This is a schematic diagram of the interaction process for end-to-end encryption through intranet penetration in this invention; Figure 4 This is a schematic diagram of the ZeroNews penetration platform in this invention. Detailed Implementation

[0021] The technical solutions of the embodiments of the present invention 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 the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0022] In existing intranet penetration scenarios, if TLS is used to achieve secure data transmission, either the service provider's private key certificate is used for termination at the edge node, or the private key is submitted to the service provider for hosting and loading into their client for termination. This invention addresses the problems of the existing technologies mentioned above, aiming to solve the security issues related to private key termination or encrypted data encryption that users are concerned about.

[0023] The definitions of abbreviations and key terms involved in this invention are as follows: Intranet penetration service provider refers to a company or entity that provides intranet penetration services; Edge node server: refers to a server deployed on the external network with a public IP address; Edge node server: refers to the intranet penetration server program deployed on the edge server; Intranet Client (Agent): This is a client program deployed within the user's or customer's internal network, providing intranet penetration service and communicating with the edge server on the external network; Intranet services refer to services deployed within the customer's or user's internal network, such as web services and remote connection services. Upstream services: In relation to the user's location, these refer to services deployed on the intranet; TLS resources: These are simply the public and private key information of the domain certificates related to TLS. ZeroNews: A high-performance enterprise-grade intranet penetration platform.

[0024] Example 1 This embodiment relates to an end-to-end encryption method for intranet penetration based on the TLS protocol, where intermediate nodes only transmit encrypted data and cannot participate in any decryption operations. The edge node server deployed on the external network receives access requests from the external network. Simultaneously, the internal network client and the external edge node server actively establish a TCP connection channel. After receiving the TLS handshake request, the external edge node server forwards the TLS handshake to the internal network client via the TCP connection. The internal network client establishes a TCP transport layer channel with the internal network service and forwards the corresponding TLS handshake request to the internal network service. The internal network service returns the corresponding cipher suite and certificate chain. The internal network client and the edge node server forward this to the external network visitor (such as a browser). The visitor encrypts the message body using the certificate's public key. Since the edge node server and the internal network client lack the private key, they cannot decrypt the data and can only pass the TLS encrypted packet through to the internal network service. This achieves TLS termination at the user's internal network service side in the intranet penetration field. Users can use their own certificates and control their private keys. The edge node server and the internal network client (Agent) in intranet penetration only act as relays and do not decrypt the traffic, thus achieving end-to-end encryption and ensuring secure and controllable access.

[0025] This embodiment uses the ZeroNews intranet penetration system as an example. The process of accessing an upstream HTTPS site from the external network based on TLS 1.3 is as follows: The ZeroNews intranet penetration system assigns a public domain name (e.g., a.example.com) to the user. The system then resolves this public domain name (a.example.com) to the corresponding edge node server via an A record (mapping the domain name to an IP address). The edge node server listens on port 443 (the default port for HTTPS).

[0026] like Figure 3 The access direction is from right to left, and the method includes the following steps: Step 01: The user's intranet client (Agent) actively sends a TCP handshake request to the edge node server on the external network. Step 02: After receiving the TCP request from the internal network client (Agent), the edge node server agrees to the internal network client's connection request and establishes a transport layer channel.

[0027] Step 03: The intranet client (Agent) reports the configured intranet service information (which includes the domain name, intranet client ID (Agent ID), network service address, etc.) to the edge node server. This channel is the control plane channel and is used for service registration and heartbeat maintenance.

[0028] Step 04: The edge node server stores the proxy service configuration information (i.e., intranet service information) reported by the client (Agent) in memory (especially the domain name information). The proxy service configuration information includes the intranet client ID (Agentid), the mapping information on that client (including the intranet service address corresponding to the intranet client ID, and the domain name information mapped to the intranet service address), and resolves the corresponding domain name to the corresponding edge node server. The edge node server maintains a unique mapping relationship for each domain name; if there is a conflict, it will reject the new domain name configuration.

[0029] Step 05, Visitor accesses domain name: The visitor sends an access request to the specified domain name, obtains the system's edge node server through DNS resolution, and sends an intranet access TCP connection based on the domain name to the edge node server, such as sending https: / / test.abc.com.

[0030] Step 06: After receiving the TCP request, the edge node server agrees to the TCP handshake information and establishes the transport layer protocol.

[0031] Step 07: After receiving the TCP handshake message indicating agreement, the visitor (i.e., the browser) initiates another TLS handshake request to the edge node server.

[0032] Steps 8-12: The edge node server parses the SNI (Server Name Indication) extension information in the plaintext portion of the TLS ClientHello (this process does not require decrypting the TLS content). Simultaneously, it matches the domain name information to identify the specified internal network client (Agent) to which the TLS byte packet should be transmitted. In this example, at this stage, the edge node server cannot decrypt the specific content of the TLS handshake because it lacks the TLS private key. Specifically, this includes: Step 08: After receiving the TLS handshake request, the edge node server extracts the SNI and domain name information from the plaintext portion of the TLS ClientHello. Step 09: The edge node server will check the local mapping table to see if there is corresponding domain name information; Step 10: If no matching information is found, a 404 error message will be returned. You can then return to step 04 and add the new domain name again. Step 11: If the domain name matches successfully, read the configuration information from the local mapping table and find the TCP tunnel that has been established with the internal network client (Agent); Step 12: The edge node server forwards the TLS handshake request to the internal network client (Agent).

[0033] Steps 13-16: The internal network client (Agent) receives the TLS handshake byte packet and resolves the internal network service address corresponding to the domain name based on its local configuration. Simultaneously, it attempts to establish a TCP connection with the internal network service. In this instance, during this stage, the internal network client (Agent) cannot decrypt the TLS handshake content because it lacks the TLS private key. Specifically, this includes: Step 13: Based on the local configuration of the client (Agent), read the internal network service address corresponding to the domain name; Step 14: The intranet client sends a TCP connection request to the intranet service corresponding to the intranet service address; Step 15: After receiving the TCP connection request, the intranet service agrees to send TCP handshake information to the intranet client. Step 16: After receiving the confirmation information, the intranet client forwards the TLS handshake request to the intranet service. Once the TCP connection between the intranet client (Agent) and the intranet service is established, the intranet client (Agent) will forward the corresponding TLS handshake information to the intranet service through this TCP tunnel. In this instance, this TCP tunnel serves as the data plane channel between the intranet client (Agent) and the intranet service for the transmission of raw TCP packets. The intranet client (Agent) will transmit all received encrypted data to the intranet service through this data plane channel.

[0034] Step 17: After receiving the request, the intranet service agrees to the TLS handshake request and returns ServerHello and confirmed encrypted information to the intranet client. Step 17.1: After receiving the information, the intranet client forwards the ServerHello and encrypted information to the edge node server on the external network; Step 17.2: After receiving the information, the edge node server forwards ServerHello to the visitor.

[0035] Step 18: The visitor receives information such as the key suite.

[0036] In step 19, the intranet service will also send a Certificate message to the intranet client. Step 19.1: The intranet client forwards the Certificate message to the edge node server on the external network; Step 19.2: The edge node server forwards the Certificate message to visitors on the external network.

[0037] In step 20, the visitor obtains relevant information such as the certificate chain.

[0038] Step 21: The visitor uses the key suite and TLS version information agreed upon in the ServerHello and Certificate messages to encrypt the subsequent message body using TLS (e.g., TLS 1.3) according to the encryption method agreed upon by both parties. It then uses the negotiated key to encrypt the transmitted data and sends the encrypted TLS data to the edge node server on the external network. Note: The TLS version and key suite information are the final negotiation results between the two ends that established the connection. The edge node and the internal network client (Agent) are only responsible for forwarding these negotiation results and are not responsible for decrypting or modifying these contents.

[0039] Step 21.1: The edge node server transmits TLS encrypted messages to the internal network client. Step 21.2: The intranet client transmits TLS encrypted messages to the intranet service; Step 22: After receiving the encrypted TLS message, the intranet service will decrypt the data packet according to the encryption and decryption method agreed upon by both parties. For example, TLS 1.3 will use the negotiated key for decryption.

[0040] Step 23: After decrypting the data, the intranet service sends a TLS encrypted response message to the intranet client; Step 23.1: After receiving the response data, the intranet client sends a TLS-encrypted response message to the edge node server on the external network. Step 23.2: The edge node server sends a TLS-encrypted response message to the external network visitor.

[0041] Step 24: After receiving the TLS encrypted response message, the visitor decrypts it according to the encryption / decryption method agreed upon by both parties. This completes the entire process of a request and response message.

[0042] In steps 22-23, after the intranet service receives the TLS handshake request, the intranet service, as a user-owned program service, will act as the holder of the TLS private key, decrypt the corresponding TLS handshake request, and complete the final handshake.

[0043] At this point, the user's intranet HTTPS service has successfully established a TLS tunnel with the browser and is communicating normally. The edge node server and the intranet client (Agent) of the intranet penetration only act as relays and do not decrypt the traffic.

[0044] Unlike existing technologies, this method allows TLS traffic to penetrate to the user's intranet service without the intranet client and cloud service provider (internet edge node) participating in the collection, storage, or parsing of the user's TLS private key. Throughout the penetration process, the TLS private key is freely managed by the user's intranet service. Neither the intranet penetration service provider nor the cloud service provider needs to collect, store, or parse the user's private key at any stage of the penetration. The edge node and intranet client (Agent) merely act as a pass-through channel for encrypted data and do not participate in any decryption operations, achieving end-to-end encryption. Because the edge node and intranet client (Agent) cannot decrypt the TLS handshake or message body (except for SNI domain information), the risk of private key leakage due to service provider involvement is fundamentally avoided, as well as the risks of leakage and decryption caused by the service provider's collection of TLS in traditional models.

[0045] The TLS handshake, encryption, and decryption occur only between the visitor and the user's upstream service. The upstream service, relative to the user's location, refers to the service deployed on the intranet, i.e., the intranet service.

[0046] All TLS handshake data is forwarded from the intranet client (Agent) to the user's intranet as raw TCP data streams. The user's upstream services are compatible with any TLS protocol (such as TLS 1.3, 1.2, etc.), offering high flexibility. Users can freely manage certificates (such as self-signed certificates or commercial CA certificates), eliminating the need for certificate hosting for the intranet penetration service provider.

[0047] The intranet client (Agent) supports hot updates and flexible management of configurations, allowing users to dynamically modify mapping relationships and interaction configurations without restarting the client. Users can perform the following operations through RESTful API, CLI commands, or a graphical user interface (UI): 1) Adding, deleting, modifying, and querying mapping relationships; 2) Adjustment of parameters such as intranet service address and bandwidth limits; 3) Dynamic switching of TLS termination location: In TLS termination application scenarios, users can switch the termination location from the Agent client to the upstream service.

[0048] Upon detecting a configuration change, the Agent automatically closes the existing TLS session and releases connection resources. When a new request arrives, it will re-establish a connection with the internal network service through a new TCP channel, thus achieving TLS handover. The entire process does not require restarting the internal network client (Agent), and the configuration takes effect immediately.

[0049] A single intranet client (Agent) supports multi-domain, multi-mapping configuration capabilities, allowing for the configuration of multiple domain names or port mappings to meet the needs of complex intranet service scenarios (such as microservice architectures). Users can aggregate traffic from multiple different domains to the same edge node and reuse the same client connection. Each mapping has independent configuration, isolating and unaffected by others. Mapping relationships can point to the same intranet service or be associated with different intranet services. The Agent provides independent TLS termination capabilities for each mapping, allowing for the configuration of different certificates and encryption policies for different domains. Each mapping establishes an independent TCP channel for transmitting the corresponding TLS packets, ensuring isolation and security. This meets the needs of users in intranet microservice scenarios.

[0050] Below is a brief introduction to the ZeroNews penetration platform, such as... Figure 4As shown, the ZeroNews penetration platform includes a data plane and a management plane. The data plane includes users, edge servers, agents, and user intranet services. The management plane includes a user control platform and a control center.

[0051] The user control platform provides a visual interface, where users can apply for or add domain names, IP addresses and ports of intranet services, and create mappings corresponding to intranet services. The control center, the central processing unit in the management plane, is responsible for configuration management, user authentication, agent authentication, configuration distribution, etc. Edge nodes, with public IP addresses, connect to internal network clients via encrypted tunnels and are responsible for forwarding user traffic. The intranet client is installed on a host within the intranet and connects to edge nodes through an encrypted tunnel. It also forwards traffic for intranet services and supports Windows, mocOS, Linux and its derivatives, OpenWrt, Raspberry Pi, and other systems.

[0052] The intranet client establishes connections between the data plane and edge nodes. Simultaneously, the intranet client connects to the control center via SSE in the management plane. When a user changes their intranet address or mapping relationship (collectively referred to as metadata change), the control center distributes the new configuration to the intranet client (agent), and the intranet client (agent) then re-push the corresponding configuration to the edge node server via hot update.

[0053] When an intranet client (Agent) connects to an edge node server, it carries an agent sign issued by the control center. This agent sign is signed by the control center using hmac-sh256 to verify the device information. This signature is tamper-proof and cannot be forged. The intranet client (Agent) must carry a valid agent sign when establishing a connection with the edge node server. The edge node server will verify the agent sign to determine the validity of the intranet client (Agent).

[0054] This embodiment also performs end-to-end testing on the method. The test results and data show that TLS encryption is transparent throughout the entire process without significantly increasing transmission latency.

[0055] Example 2 The electronic device of this invention includes a central processing unit (CPU), which can perform various appropriate actions and processes according to computer program instructions stored in read-only memory (ROM) or loaded from a storage unit into random access memory (RAM). The RAM may also store various programs and data required for device operation. The CPU, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0056] Multiple components in the device are connected to the I / O interface, including: input units such as keyboards and mice; output units such as various types of displays and speakers; storage units such as disks and optical discs; and communication units such as network interface cards (NICs), modems, and wireless transceivers. The communication unit allows the device to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0057] The processing unit performs the various methods and processes described above. For example, in some embodiments, the methods may be implemented as computer software programs tangibly contained in a machine-readable medium, such as a storage unit. In some embodiments, part or all of the computer program may be loaded and / or installed on the device via ROM and / or a communication unit. When the computer program is loaded into RAM and executed by the CPU, one or more steps of the methods described above may be performed. Alternatively, in other embodiments, the CPU may be configured to execute the methods by any other suitable means (e.g., by means of firmware).

[0058] The functions described above in this document can be performed, at least in part, by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: Field Programmable Gate Arrays (FPGAs), Application-Specific Integrated Circuits (ASICs), Application Standard Products (ASSPs), System-on-Chip (SoCs), Complex Programmable Logic Devices (CPLDs), and so on.

[0059] The program code used to implement the methods of the present invention can be written in any combination of one or more programming languages. This program code can be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing device, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code can be executed entirely on the machine, partially on the machine, as a standalone software package partially on the machine and partially on a remote machine, or entirely on a remote machine or server.

[0060] In the context of this invention, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory, optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0061] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in the present invention, and these modifications or substitutions should all be covered within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.

Claims

1. An end-to-end encryption method for intranet penetration based on the TLS protocol, characterized in that, This method is applied to intranet clients, including: establishing a TCP tunnel between the intranet client and the edge node server on the external network; After receiving the TLS handshake request from the edge node server through the TCP tunnel, the intranet client establishes a TCP tunnel with the intranet service and forwards the TLS handshake request to the intranet service. The intranet client forwards the ServerHello, encrypted information, and Certificate messages from the intranet service to the edge node server. The intranet client transmits TLS-encrypted messages from the edge node server to the intranet service through a TCP tunnel; The intranet client transmits the TLS-encrypted response message from the intranet service to the edge node server via a TCP tunnel.

2. The end-to-end encryption method for intranet penetration based on the TLS protocol according to claim 1, characterized in that, The intranet client sends configured intranet service information to the edge node server through a TCP tunnel. The intranet service information includes the domain name, intranet client ID, and intranet service address.

3. The intranet penetration end-to-end encryption method based on the TLS protocol according to claim 2, characterized in that, After receiving the TLS handshake request, the intranet client resolves the intranet service address corresponding to the domain name according to the configuration and sends a TCP connection request to the corresponding intranet service.

4. The intranet penetration end-to-end encryption method based on the TLS protocol according to claim 2, characterized in that, When the configuration changes, the intranet client sends the newly configured intranet service information to the edge node server via hot update.

5. An end-to-end encryption method for intranet penetration based on the TLS protocol, characterized in that, This method is applied to the edge node server on the external network, whereby the edge node server establishes a TCP tunnel with the client on the internal network. The edge node server receives and agrees to the TCP handshake request from the visitor; The edge node server transmits the TLS handshake request from the visitor to the internal network client; The edge node server forwards ServerHello, encrypted information, and Certificate messages to the visitor. The edge node server transmits TLS-encrypted messages from visitors to intranet clients via a TCP tunnel. The edge node server transmits the TLS-encrypted response message from the internal network client to the visitor via a TCP tunnel.

6. The intranet penetration end-to-end encryption method based on the TLS protocol according to claim 5, characterized in that, The edge node server stores intranet service information configured from intranet clients, including intranet client ID, domain name, and intranet service address; The edge node server maintains a unique mapping relationship for each domain name, forming a local mapping table.

7. The intranet penetration end-to-end encryption method based on the TLS protocol according to claim 6, characterized in that, After receiving the TLS handshake request from the visitor, the edge node server extracts the SNI and domain name information from the plaintext part of the TLS ClientHello and checks whether there is corresponding domain name information in the local mapping table. If no matching information is found, a new domain name is added; if the domain name matches successfully, the configuration information is read from the local mapping table, and the established TCP tunnel to the intranet client is found.

8. The intranet penetration end-to-end encryption method based on the TLS protocol according to claim 7, characterized in that, When the configuration changes, the edge node server receives the newly configured intranet service information from the intranet client via hot update.

9. An end-to-end encryption method for intranet penetration based on the TLS protocol, characterized in that, This method is applied to intranet services, which, after agreeing to a TLS handshake request from an intranet client via a TCP tunnel, return a ServerHello message and specific encrypted information to the intranet client. The intranet service decrypts the received encrypted TLS message according to the agreed encryption and decryption method, and after decrypting the data, sends the corresponding TLS encrypted message to the intranet client.

10. The intranet penetration end-to-end encryption method based on the TLS protocol according to claim 9, characterized in that, The intranet server also sends Certificate messages to the intranet client.

Images