TLS certificate caching method and device for VLESS + Reality, equipment and medium

Abstract

The invention provides a TLS certificate caching method, device and equipment for VLESS + Realities and a medium, and the method comprises the steps: initializing a cache data structure which comprises a main cache and a heavy load mark cache; receiving a TLS client handshake request sent by a client, and analyzing the client handshake request to obtain a TLS version number and a session identifier; querying a main cache according to the TLS version number; initiating connection to a preset simulation domain name server, storing the server handshake response data in a main cache by taking the TLS version number as a key, and setting a corresponding heavy load mark value to be false; reading server handshake response data corresponding to the TLS version number from a main cache, and dynamically modifying the server handshake response data; and the modified server handshake response data is sent to the client, so that the problems of slow proxy blocking and connection interruption caused by analog domain name access failure and high delay are radically relieved.

Description

Technical Field

[0001] This invention relates to the field of network communication technology, and in particular to a TLS certificate caching method, apparatus, device, and medium for VLESS+Reality. Background Technology

[0002] With the rapid development of network communication technology, the demand for security and smoothness in cross-network access and data transmission is increasing. Proxy technology, as an important means to ensure the flexibility of network access and the privacy of data transmission, is widely used in various network scenarios. Among them, the VLESS proxy protocol, with its simple and efficient architecture, has significant advantages in reducing protocol redundancy and improving transmission efficiency. The VLESS+Reality proxy protocol, derived from the VLESS protocol, further enhances the concealment of proxy transmission by introducing a traffic simulation and masquerading mechanism, effectively addressing the problem of traffic identification and interception in the network environment, and has become one of the mainstream proxy solutions.

[0003] Specifically, the core working principle of the VLESS+Reality proxy protocol is to achieve covert transmission of proxy data by simulating TLS (Transport Layer Security) traffic of a target domain name pre-configured by the user. TLS, as a widely adopted secure transmission standard on the current internet, possesses strong universality and legitimacy in its traffic. Based on this characteristic, the traffic simulation scheme enables proxy traffic to circumvent conventional traffic detection mechanisms during network transmission, reducing the probability of being identified and intercepted, thereby ensuring the stability of the proxy connection.

[0004] To ensure the authenticity and legitimacy of simulated TLS traffic, the current VLESS+Reality proxy protocol employs a dynamic certificate acquisition strategy. This means that when processing each user request, the proxy node actively accesses the network address corresponding to the pre-configured simulated domain name to obtain the domain's real TLS certificate, and then constructs simulated TLS traffic based on the obtained certificate. The core purpose of this strategy is to ensure that the simulated traffic maintains consistency with the target domain's real TLS traffic in key characteristics such as certificate information and encryption format, further enhancing the realism of the traffic masquerading and strengthening the proxy solution's resistance to detection.

[0005] However, the aforementioned certificate acquisition strategies have significant technical flaws, as they are highly dependent on the connectivity of the network address corresponding to the simulated domain name. In the actual global internet environment, network topologies are complex and variable. Factors such as network coverage quality in different regions, network operator routing policies, the stability of cross-border network links, and the service availability of the target domain name itself can all affect the connectivity between the proxy node and the simulated domain name's network address. Currently, no technical solution can guarantee smooth and stable access to a fixed domain name's network address globally: in some network environments, the simulated domain name may be blocked by local network operators; in cross-border access scenarios, congestion and high packet loss rates on cross-border links may cause a surge in access latency or even access failure; furthermore, if the server corresponding to the simulated domain name malfunctions, is under maintenance, or is overloaded, it will directly prevent the proxy node from obtaining the TLS certificate normally.

[0006] The aforementioned connectivity issues directly lead to a series of problems in the practical application of the VLESS+Reality proxy protocol: when the proxy node cannot access the simulated domain name to obtain a certificate, the construction process of proxy traffic is interrupted, resulting in proxy connection failure; even if a certificate can be obtained, high latency or packet loss during access will cause a significant decrease in proxy response speed, leading to slowdowns, loading delays, and other problems, severely impacting the user's network access experience. Practice shows that more than half of the various anomalies encountered in the actual deployment and use of the VLESS+Reality proxy protocol are caused by unsuccessful or interrupted access to the simulated domain name. This technical deficiency greatly limits the applicability and stability of the VLESS+Reality proxy protocol, reduces its deployment value and user experience in complex global network environments, and has become a key technical problem that urgently needs to be solved in this field. Summary of the Invention

[0007] The technical problem to be solved by the present invention is to provide a TLS certificate caching method, apparatus, device and medium for VLESS+Reality. By caching the acquired TLS certificate data, the simulated domain name is only accessed when the cache misses or needs to be reloaded, which greatly reduces the dependence on the connectivity of the simulated domain name and fundamentally alleviates the problems of proxy slowdown and connection interruption caused by simulated domain name access failure and high latency.

[0008] In a first aspect, the present invention provides a TLS certificate caching method for VLESS+Reality, comprising the following steps: S1. Initialize the cache data structure, including: a main cache and an overload flag cache; the main cache is used to store key-value pairs with the TLS version number as the key and the server handshake response data as the value; the overload flag cache is used to store key-value pairs with the TLS version number as the key and the overload flag value as the value; S2. Receive the TLS client handshake request sent by the client, and parse the TLS version number and session identifier from the client handshake request; S3. Query the main cache based on the TLS version number: If the main cache is hit and the corresponding overload flag is false, then execute S5; If the main cache misses or the corresponding overload flag is true, then execute S4; S4. Initiate a connection to the preset simulated domain name server, send the client handshake request, receive the server handshake response data, store the server handshake response data in the main cache with the TLS version number as the key, and set the corresponding reload flag value to false. S5. Read the server handshake response data corresponding to the TLS version number from the main cache, and dynamically modify the server handshake response data, including: replacing the server random number field with a newly generated random number; and replacing the session identifier field according to the session identifier. S6. Send the modified server handshake response data to the client.

[0009] Secondly, the present invention provides a TLS certificate caching device for VLESS+Reality, comprising: The cache initialization module initializes the cache data structure, including: a main cache and an overload flag cache; the main cache is used to store key-value pairs with the TLS version number as the key and the server handshake response data as the value; the overload flag cache is used to store key-value pairs with the TLS version number as the key and the overload flag value as the value; The request parsing module receives the TLS client handshake request sent by the client and parses the TLS version number and session identifier from the client handshake request; The cache query module queries the main cache based on the TLS version number: If the main cache is hit and the corresponding overload flag is false, then the dynamic build module is executed; If the main cache misses or the corresponding overload flag is true, the cache filling module is executed. The cache filling module initiates a connection to a preset simulated domain name server, sends the client handshake request, receives server handshake response data, stores the server handshake response data in the main cache with the TLS version number as the key, and sets the corresponding reload flag value to false. The dynamic construction module reads server handshake response data corresponding to the TLS version number from the main cache and dynamically modifies the server handshake response data, including: replacing the server random number field with a newly generated random number; and replacing the session identifier field according to the session identifier. The response sending module sends the modified server handshake response data to the client.

[0010] Thirdly, the present invention 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 program to implement the method described in the first aspect.

[0011] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0012] One or more technical solutions provided by this invention have at least the following technical effects or advantages: 1. Reduce reliance on simulated domain names and improve proxy stability: By caching the obtained TLS certificate data (ServerHello related data), simulated domain names are only accessed when the cache is missed or needs to be reloaded, which greatly reduces the reliance on the connectivity of simulated domain names and fundamentally alleviates the problems of proxy slowdown and connection interruption caused by simulated domain name access failure and high latency.

[0013] 2. Improve proxy response performance and reduce latency: Avoid repeating the time-consuming operation of "connecting to a simulated domain name - obtaining a certificate" for each proxy request. Subsequent requests can directly and quickly obtain certificate data from the cache, significantly reducing proxy response latency and improving the user's network access experience.

[0014] 3. Concurrency safety, adaptable to high-concurrency scenarios: It adopts a thread-safe sync.Map as the cache data structure, supports concurrent read and write by multiple coroutines, and can stably adapt to high-concurrency proxy request scenarios, avoiding cache disorder or program abnormalities caused by concurrent access.

[0015] 4. Flexible adaptation to multiple TLS versions and strong compatibility: Adaptive caching logic is designed for TLS 1.3 and above and TLS 1.2 and below. It also supports dual lookup strategies by TLS version and SNI, ensuring that it can work normally in network environments with different TLS versions and has wide compatibility.

[0016] 5. Balancing data security and authenticity: Through dynamic function replacement, the cached certificate data is guaranteed to accurately match the client information of the current request during the reuse process. This reuses cached data without compromising the authenticity of TLS interactions and maintains the concealment of traffic spoofing.

[0017] 6. Strong fault tolerance, without affecting the overall service: When a network request fails (such as a failure to connect to a simulated domain name), only logs are recorded, without interrupting the processing of subsequent requests; cache lookup supports alternative strategies (searching by SNI when the TLS version is not matched), further improving the fault tolerance and reliability of the solution.

[0018] 7. Resource utilization optimization and on-demand dynamic caching: Adopting a two-layer caching design of "preloading default certificate + on-demand dynamic caching" to avoid resource waste caused by indiscriminate caching; network requests are only initiated when necessary (cache miss / reload required) to reduce network bandwidth and server resource consumption.

[0019] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0020] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0021] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the device in Embodiment 2 of the present invention. Detailed Implementation

[0022] The overall concept of the technical solution in this application is as follows: S1. Configure two thread-safe concurrent mappings as a cache structure: the first concurrent mapping uses the TLS version number as the key to store the complete Server Hello data byte stream obtained from the preset simulated domain name; the second concurrent mapping uses the TLS version number as the key to store an overloaded boolean value used to mark whether the Server Hello data of the corresponding TLS version needs to be re-obtained. S2. When a TLS proxy request is received from a client, the Client Hello message sent by the client is parsed, and the TLS version number, SNI (Server Name Indicator), and Session ID (Session Identifier) ​​information are extracted. S3. Execute cache retrieval and filling logic based on the extracted TLS version number: S31. If Server Hello data corresponding to the TLS version number exists in the first concurrent mapping, then query the overload boolean value corresponding to the TLS version number in the second concurrent mapping; if the overload boolean value is false, then directly use the Server Hello data as valid cache data. S32. If there is no Server Hello data corresponding to the TLS version number in the first concurrent mapping, or the overload boolean value corresponding to the TLS version number is true, then establish a TCP connection with the preset simulated domain name, send the Client Hello message to the preset simulated domain name, receive and parse the Server Hello related data returned by the preset simulated domain name, store it in the first concurrent mapping according to the TLS version, and set the overload boolean value corresponding to the TLS version number in the second concurrent mapping to false; if a connection failure, message sending failure, or parsing failure occurs, then record an error log and terminate this cache filling operation; S4. Dynamically modify the obtained valid cached data to generate the target Server Hello response: S41. Copy the valid cached data to generate a data copy, avoiding modification of the original cached data; S42. Replace the 32-byte segment of the Random field corresponding to the Server Hello message in the data copy with a cryptographically secure random number; S43. Replace the content of the Session ID field of the corresponding Server Hello message in the data copy with the extracted Session ID; S5. Send the target Server Hello response to the client to complete the TLS handshake response phase.

[0023] Specifically as follows: The implementation details of the TLS certificate caching strategy are as follows: I. Cache Data Structure Use two global sync.Maps (thread-safe concurrent maps): go / / Cache-2: Store Server Hello data by TLS version var simSniServerHelloData sync.Map / / key: tlsVer(uint16), value: []byte / / Overload flag: indicates whether a new certificate needs to be obtained. var reloadSimSniServerHelloData sync.Map / / key: tlsVer(uint16), value: bool II. Function Implementation 1. getSimServerHello - Obtain and cache the certificate; tls certificate caching scheme.go func (t *Tls) getSimServerHello(data []byte, tlsVer uint16) { if _, ok := simSniServerHelloData.Load(tlsVer); ok { if reload, okk := reloadSimSniServerHelloData.Load(tlsVer); okk { if!reload.(bool) { return } } else { logger.Printf("tls: internal error: not foundreloadSimSniServerHelloData %s: %v\n", t.sni, reload) return } } conn, err := t.netTcpDial(net.JoinHostPort(t.sni, "443")) if err != nil { logger.Printf("tls: internal error: failed to dial %s: %v\n",t.sni, err) return } defer conn.Close() _, err = conn.Write(data) if err != nil { logger.Printf("tls: internal error: failed to write to %s: %v\n",t.sni, err) return } buff := buf.New() defer func() { buff.DecRef() buff.Release() }() err = readServerHelloRecordHeader(conn, buff) if err != nil { logger.Printf("tls: internal error: failed to readServerHelloRecordHeader %s: %v\n", t.sni, err) return } shMsg, _, _, _, err := parserSh(buff.Bytes()) if err != nil { logger.Printf("tls: internal error: failed to parserSh %s: %v\n", t.sni, err) return } if tlsVersionMoreTLS13(shMsg.SupportedVersion()) { / / TODO Need to perform integrity check on tls3 package (to be considered later) logger.Printf("reloadSimSniServerHelloData >= tls1.3 %s %v\n", t.sni, tlsVer) reloadSimSniServerHelloData.Store(tlsVer, false) [[ID=URL=36]]simSniServerHelloData.Store(tlsVer, CopyDataFromBuffer(buff)) [ return } isDirectCopy, err := readServerHelloHandshake(conn, buff, false) if err != nil { logger.Printf("tls: internal error: failed toreadServerHelloHandshake %s: %v", t.sni, err) return } if !isDirectCopy { logger.Printf("reloadSimSniServerHelloData %s %v\n", t.sni, tlsVer) reloadSimSniServerHelloData.Store(tlsVer, false) simSniServerHelloData.Store(tlsVer, CopyDataFromBuffer(buff)) } else { logger.Printf("isDirectCopy, skip simSniServerHelloData %s %v\n",t.sni, tlsVer) } } Implementation process: - Step 1: Check the cache - 2 - Use tlsVer to query simSniServerHelloData; - If it exists, check the reloadSimSniServerHelloData flag; - If reload == false, return directly (no need to fetch again); Step 2: Connect to the mock domain - Connect to t.sni:443; - If it fails, log the error and return. Step 3: Send Client Hello - Write the incoming data (Client Hello) to the connection; Step 4: Read Server Hello - Read the record header; - Parse the Server Hello message; Step 5: Process TLS 1.3 - If it is TLS 1.3+, cache the complete data directly; - Set reload = false to store data in simSniServerHelloData; - Step 6: Handling TLS 1.2 and below - Read the complete handshake message; - If !isDirectCopy is present, cache the data and set reload = false; - If isDirectCopy, skip the cache (it may already be complete).

[0024] 2. getSimSniServerHelloTimeout - Retrieve certificate from cache 90:103: TLS certificate caching solution.go func getSimSniServerHelloTimeout(tlsVer uint16, sni string) ([]byte,error) { sh, ok := simSniServerHelloData.Load(tlsVer) if ok { smiServerHelloData := sh.([]byte) return smiServerHelloData, nil } else { sh, ok := simSniServerHelloData.Load(sni) if ok { smiServerHelloData := sh.([]byte) return smiServerHelloData, nil } return nil, errors.New("tls: internal error: not foundsimSniServerHelloData") } } Search logic: - Prioritize searching by tlsVer (cache -2); - If no match is found, search by SNI (as a backup); - Return an error if none of the above are hits. 3. buildSimServerHelloData - Builds and replaces the Random and Session IDs; 105:144: TLS certificate caching solution.go func buildSimServerHelloData(simServerHelloData []byte, sessionId []byte) ([]byte, error) { bytes := make([]byte, len(simServerHelloData)) copy(bytes, simServerHelloData) _, err := io.ReadFull(rand.Reader, bytes[11:11+32]) if err != nil { return nil, err } originalSessionLen := int(bytes

[43] ) sessionIdLen := len(sessionId) if sessionIdLen == 0 { _, err = io.ReadFull(rand.Reader, bytes[43+1:43+1+originalSessionLen]) if err != nil { return nil, err } return bytes, nil } if originalSessionLen == sessionIdLen { copy(bytes[43+1:], sessionId) return bytes, nil } msg, start, end, _, err := parserSh(bytes) if err != nil { return nil, err } msg.SetSessionId(sessionId) chData, err := msg.MarshalOrderMsg() if err != nil { return nil, err } chLength := changeReqLength((int(bytes[3])<<8 | int(bytes[4])) +sessionIdLen - originalSessionLen) bytes[3] = chLength[0] bytes[4] = chLength[1] data := append(bytes[:start], chData...) data = append(data, bytes[end:]...) return data, nil } Implementation details: - Step 1: Copy cached data; - Create a copy to avoid modifying the original data; - Step 2: Replace Random; - Location: bytes[11:43] (32 bytes); - Use crypto / rand to generate random numbers; - Step 3: Process the Session ID; - Read the original Session ID length (bytes

[43] ); - Case 1: sessionIdLen == 0, generate a random Session ID; - Case 2: If the lengths are equal, replace directly; - Step 4: Handle changes in Session ID length; - When the lengths are different, parse the message, set a new Session ID, and reserialize it; - Adjust the length field (bytes[3:5]); - Reassemble the data packets.

[0025] III. Design Points 1. Dual-level caching Cache-1: The default certificate preloaded at startup; Cache-2: Dynamic caching by TLS version; 2. Obtain on demand Only request a mock domain name if cache-2 does not exist or needs to be reloaded; 3. Data replacement Replace the Random and Session IDs to make the response match the request; 4. Concurrency safety Use sync.Map to support concurrent read and write operations; 5. Error Handling Log out network failures without affecting subsequent requests; This solution reduces reliance on mock domains through caching, thereby improving the stability and performance of the proxy. Example

[0026] like Figure 1 As shown, this embodiment provides a TLS certificate caching method for VLESS+Reality, including the following steps: S1. Initialize the cache data structure, including: a main cache and an overload flag cache; the main cache is used to store key-value pairs with the TLS version number as the key and the server handshake response data as the value; the overload flag cache is used to store key-value pairs with the TLS version number as the key and the overload flag value as the value; S2. Receive the TLS client handshake request sent by the client, and parse the TLS version number and session identifier from the client handshake request; S3. Query the main cache based on the TLS version number: If the main cache is hit and the corresponding overload flag is false, then execute S5; If the main cache misses or the corresponding overload flag is true, then execute S4; S4. Initiate a connection to the preset simulated domain name server, send the client handshake request, receive the server handshake response data, store the server handshake response data in the main cache with the TLS version number as the key, and set the corresponding reload flag value to false. S5. Read the server handshake response data corresponding to the TLS version number from the main cache, and dynamically modify the server handshake response data, including: replacing the server random number field with a newly generated random number; and replacing the session identifier field according to the session identifier. S6. Send the modified server handshake response data to the client.

[0027] In this embodiment, preferably, S1 specifically comprises: The initialization cache data structure includes: a main cache and an overload flag cache; the main cache is used to store key-value pairs with the TLS version number as the key and the server handshake response data as the value; the overload flag cache is used to store key-value pairs with the TLS version number as the key and the overload flag value as the value; both the main cache and the overload flag cache are implemented using a thread-safe concurrent mapping data structure; When the proxy service starts, it uses the preset default TLS version number to initiate a connection to the preset simulated domain name server, obtains the server handshake response data, and stores the server handshake response data in the main cache.

[0028] In this embodiment, preferably, the step S4 of receiving the server handshake response data specifically includes: Read the TLS record layer header to obtain the handshake message type and protocol version information; Parse the server handshake message and extract the TLS version number supported by the server; Determine whether the TLS version number supported by the server is greater than or equal to TLS 1.3: if yes, read the complete TLS record layer data as the server handshake response data; if no, continue reading subsequent handshake messages and determine whether direct copying is required. If direct copying is not required, use the read data as the server handshake response data.

[0029] In this embodiment, preferably, in step S5, replacing the session identifier field specifically includes: Read the length of the original session identifier from the server's handshake response data; Determine the length of the client session identifier: If the length of the client session identifier is zero, generate a random session identifier and replace the original session identifier; If the length of the client session identifier is equal to the length of the original session identifier, then the client session identifier is used to overwrite the original session identifier. If the client session identifier length is not equal to the original session identifier length, the server handshake message structure is parsed, a new session identifier is set, the handshake message is reserialized, the TLS record layer length field is adjusted, and the server handshake response data is reassembled.

[0030] In this embodiment, preferably, in step S5, replacing the server random number segment specifically includes: locating the position of the server random number segment in the server handshake response data, generating 32 bytes of random data using a cryptographically secure random number generator, and writing the random data into the position of the server random number segment.

[0031] In this embodiment, preferably, the query for the main cache based on the TLS version number in S3 specifically involves: querying the main cache using the TLS version number as the key; if no match is found, querying the main cache using the server name indication parsed from the client handshake request as the key; if no match is found in either case, it is determined that the main cache has not been hit.

[0032] In this embodiment, preferably, in step S4, if the connection to the preset simulated domain name server fails, an error log is recorded and the current request processing flow is terminated.

[0033] Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2.

[0034] Example 2 like Figure 2 As shown, this embodiment provides a TLS certificate caching device for VLESS+Reality, including: The cache initialization module initializes the cache data structure, including: a main cache and an overload flag cache; the main cache is used to store key-value pairs with the TLS version number as the key and the server handshake response data as the value; the overload flag cache is used to store key-value pairs with the TLS version number as the key and the overload flag value as the value; The request parsing module receives the TLS client handshake request sent by the client and parses the TLS version number and session identifier from the client handshake request; The cache query module queries the main cache based on the TLS version number: If the main cache is hit and the corresponding overload flag is false, then the dynamic build module is executed; If the main cache misses or the corresponding overload flag is true, the cache filling module is executed. The cache filling module initiates a connection to a preset simulated domain name server, sends the client handshake request, receives server handshake response data, stores the server handshake response data in the main cache with the TLS version number as the key, and sets the corresponding reload flag value to false. The dynamic construction module reads server handshake response data corresponding to the TLS version number from the main cache and dynamically modifies the server handshake response data, including: replacing the server random number field with a newly generated random number; and replacing the session identifier field according to the session identifier. The response sending module sends the modified server handshake response data to the client.

[0035] In this embodiment, preferably, the cache initialization module specifically comprises: The initialization cache data structure includes: a main cache and an overload flag cache; the main cache is used to store key-value pairs with the TLS version number as the key and the server handshake response data as the value; the overload flag cache is used to store key-value pairs with the TLS version number as the key and the overload flag value as the value; both the main cache and the overload flag cache are implemented using a thread-safe concurrent mapping data structure; When the proxy service starts, it uses the preset default TLS version number to initiate a connection to the preset simulated domain name server, obtains the server handshake response data, and stores the server handshake response data in the main cache.

[0036] In this embodiment, preferably, the specific steps of receiving server handshake response data in the cache filling module include: Read the TLS record layer header to obtain the handshake message type and protocol version information; Parse the server handshake message and extract the TLS version number supported by the server; Determine whether the TLS version number supported by the server is greater than or equal to TLS 1.3: if yes, read the complete TLS record layer data as the server handshake response data; if no, continue reading subsequent handshake messages and determine whether direct copying is required. If direct copying is not required, use the read data as the server handshake response data.

[0037] In this embodiment, preferably, the replacement of the session identifier field in the dynamic construction module specifically includes: Read the length of the original session identifier from the server's handshake response data; Determine the length of the client session identifier: If the length of the client session identifier is zero, generate a random session identifier and replace the original session identifier; If the length of the client session identifier is equal to the length of the original session identifier, then the client session identifier is used to overwrite the original session identifier. If the client session identifier length is not equal to the original session identifier length, the server handshake message structure is parsed, a new session identifier is set, the handshake message is reserialized, the TLS record layer length field is adjusted, and the server handshake response data is reassembled.

[0038] In this embodiment, preferably, the replacement of the server random number segment in the dynamic construction module specifically includes: locating the position of the server random number segment in the server handshake response data, generating 32 bytes of random data using a cryptographically secure random number generator, and writing the random data into the position of the server random number segment.

[0039] In this embodiment, preferably, the cache query module queries the main cache based on the TLS version number as follows: query the main cache using the TLS version number as the key; if no match is found, query the main cache using the server name indication parsed from the client handshake request as the key; if no match is found in either case, it is determined that the main cache has not been hit.

[0040] In this embodiment, preferably, if the cache filling module fails to initiate a connection to the preset simulated domain name server, an error log is recorded and the current request processing flow is terminated.

[0041] Since the apparatus described in Embodiment 2 of the present invention is an apparatus used to implement the method of Embodiment 1 of the present invention, those skilled in the art can understand the specific structure and variations of the apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be described again here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of the present invention.

[0042] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to Embodiment 1, as detailed in Embodiment 3.

[0043] Example 3 This embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement any of the implementation methods in Embodiment 1.

[0044] Since the electronic device described in this embodiment is the device used to implement the method in Embodiment 1 of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in Embodiment 1 of this application. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiment of this application falls within the scope of protection of this application.

[0045] Based on the same inventive concept, this application provides a storage medium corresponding to Embodiment 1, as detailed in Embodiment 4.

[0046] Example 4 This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it can implement any of the implementation methods in Embodiment 1.

[0047] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0048] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0049] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0050] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0051] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the present invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A TLS certificate caching method for VLESS+Reality, characterized in that: The method comprises the following steps: S1, initializing a cache data structure, comprising: a main cache and a reload mark cache; the main cache is used to store key-value pairs with TLS version numbers as keys and server handshake response data as values; the reload mark cache is used to store key-value pairs with TLS version numbers as keys and reload mark values as values; S2, receiving a TLS client handshake request sent by a client, and obtaining a TLS version number and a session identifier from the client handshake request; S3, querying the main cache according to the TLS version number: if the main cache hits and the corresponding reload mark value is false, S5 is executed; if the main cache misses or the corresponding reload mark value is true, S4 is executed; S4, initiating a connection to a preset simulated domain name server, sending the client handshake request, receiving server handshake response data, storing the server handshake response data in the main cache with the TLS version number as the key, and setting the corresponding reload mark value to false; S5, reading the server handshake response data corresponding to the TLS version number from the main cache, and dynamically modifying the server handshake response data, including: replacing the server random number field with a newly generated random number; and replacing the session identifier field according to the session identifier; S6, sending the modified server handshake response data to the client.

2. The TLS certificate caching method for VLESS+Reality according to claim 1, characterized in that: The S1 is specifically: initializing a cache data structure, comprising: a main cache and a reload mark cache; the main cache is used to store key-value pairs with TLS version numbers as keys and server handshake response data as values; the reload mark cache is used to store key-value pairs with TLS version numbers as keys and reload mark values as values; the main cache and the reload mark cache are both implemented by using a thread-safe concurrent mapping data structure; when the proxy service starts, a preset default TLS version number is used to initiate a connection to a preset simulated domain name server, obtain server handshake response data, and store the server handshake response data in the main cache.

3. The TLS certificate caching method for VLESS+Reality of claim 1, wherein: In the S4, the server handshake response data is specifically received as follows: reading a TLS record layer header to obtain handshake message type and protocol version information; parsing a server handshake message to extract a server-supported TLS version number; determining whether the server-supported TLS version number is greater than or equal to TLS1.3: if yes, reading complete TLS record layer data as server handshake response data; if no, continuing to read subsequent handshake messages to determine whether direct copying is needed, and if direct copying is not needed, reading the data as server handshake response data.

4. The TLS certificate caching method for VLESS+Reality of claim 1, wherein: In the S5, replacing the session identifier field specifically comprises: reading the length of an original session identifier in the server handshake response data; determining the length of the client session identifier: if the length of the client session identifier is zero, a random session identifier is generated and the original session identifier is replaced; if the length of the client session identifier is equal to the length of the original session identifier, the original session identifier is directly overwritten with the client session identifier; If the client session identifier length is not equal to the original session identifier length, the server handshake message structure is parsed, a new session identifier is set, the handshake message is re-serialized, the TLS record layer length field is adjusted, and the server handshake response data is re-assembled.

5. The TLS certificate caching method for VLESS+Reality of claim 1, wherein: In the S5, the replacing the server random number field specifically includes: locating the position of the server random number field in the server handshake response data, generating 32 bytes of random data using a cryptographically secure random number generator, and writing the random data into the position of the server random number field.

6. The TLS certificate caching method for VLESS+Reality of claim 1, wherein: In the S3, the querying the primary cache according to the TLS version number specifically includes: querying the primary cache using the TLS version number as a key; if no hit is found, querying the primary cache using the server name indication parsed from the client handshake request as a key; if no hit is found in either case, determining that the primary cache is not hit.

7. The TLS certificate caching method for VLESS+Reality of claim 1, wherein: In the S4, if the connection to the preset simulated domain name server fails, an error log is recorded and the current request processing flow is terminated.

8. A TLS certificate caching apparatus for VLESS+Reality, characterized in that: The application comprises: a cache initialization module that initializes cache data structures, including: a primary cache and a reload flag cache; the primary cache is used to store key-value pairs with a TLS version number as a key and server handshake response data as a value; the reload flag cache is used to store key-value pairs with a TLS version number as a key and a reload flag value as a value; a request parsing module that receives a TLS client handshake request sent by a client and parses a TLS version number and a session identifier from the client handshake request; a cache querying module that queries the primary cache according to the TLS version number: if the primary cache is hit and the corresponding reload flag value is false, a dynamic construction module is executed; if the primary cache is not hit or the corresponding reload flag value is true, a cache filling module is executed; the cache filling module initiates a connection to a preset simulated domain name server, sends the client handshake request, receives server handshake response data, stores the server handshake response data in the primary cache using the TLS version number as a key, and sets the corresponding reload flag value to false; the dynamic construction module reads server handshake response data corresponding to the TLS version number from the primary cache, dynamically modifies the server handshake response data, including: replacing the server random number field with a newly generated random number; and replacing the session identifier field according to the session identifier; a response sending module that sends the modified server handshake response data to the client.

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor executes the program to implement the method of any one of claims 1 to 7.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The program is executed by the processor to implement the method of any one of claims 1 to 7. The program is executed by the processor to implement the method of any one of claims 1 to 7.

Images