WO2021169266A1

WO2021169266A1 - Method and apparatus for secure handshaking between client and service end, and storage medium

Info

Publication number: WO2021169266A1
Application number: PCT/CN2020/117430
Authority: WO
Inventors: 魏海通
Original assignee: 平安科技（深圳）有限公司
Priority date: 2020-02-26
Filing date: 2020-09-24
Publication date: 2021-09-02
Also published as: CN111385289A

Abstract

The present application relates to the technical field of information security. Provided is a method for secure handshaking between a client and a service end. Secure handshaking is realized by means of reusing a session record at a handshaking stage of a client and a service end. The method comprises: S110: a service end generating a session record key every first set period of time and storing same in a memory of the service end; S120: the service end using the latest generated session record key to encrypt a session record generated by means of initial handshaking between a client and the service end, and sending the encrypted session record to the client; and S130: when the client carries the encrypted session record to perform subsequent handshaking with the service end, the service end sequentially calling session record keys in the memory of the service end to decrypt the encrypted session record, if the decryption is successful, the client and the service end reusing a negotiation key in the session record, such that handshaking is completed, and if the decryption fails, proceeding to S120. The present application increases the difficulty in the decryption of a session record key and enhances data transmission security.

Description

Method, device and storage medium for secure handshake between client and server

This application claims the priority of a Chinese patent application filed with the Chinese Patent Office on February 26, 2020, the application number is 202010119427.9, and the invention title is "Method, device and storage medium for secure handshake between client and server", and its entire contents Incorporated in this application by reference.

Technical field

This application relates to the field of information security technology, and more specifically, to a method, device and storage medium for secure handshake between a client and a server.

Background technique

As everyone pays more attention to network security, more and more websites are rectified to HTTPS (Secure Hypertext Transfer Protocol, secure hypertext transfer protocol). It is a secure communication channel, which is developed based on HTTP and used to exchange information between the client computer and the server. It uses Secure Socket Layer (SSL) for information exchange, and it uses TLS/SSL (Transport Layer Security, the full name of the secure transport layer protocol) encrypted HTTP protocol. The HTTP protocol uses plain text to transmit information, and there are risks of information eavesdropping, information tampering, and information hijacking. The protocol TLS/SSL has the functions of identity verification, information encryption and integrity verification to encrypt the transmitted data to ensure that the data is in transmission Unchanged, it is a layer of security protocol between TCP and HTTP.

HTTPS is roughly divided into two phases, namely the handshake phase and the data transmission phase. Handshake phase: During the handshake phase, the client and server of the TLS/SSL protocol negotiate a set of encryption algorithms and integrity verification algorithms used to protect data transmission, as well as the keys used by each algorithm. Data transmission phase: Once the TLS/SSL handshake is completed, the data is divided into a series of records protected by key encryption negotiated in the handshake phase for transmission.

However, the client and the server need multiple round-trip negotiation interactions during the handshake phase, and a large amount of calculations are required to obtain information related to secure communication such as keys, and the round-trip time (RTT) is relatively large; and the client Complicated and cumbersome key calculations are required inside the server, and the performance (such as power, storage, and computing resources) of the client device and the server device consumes a lot, which is the main reason for the slow HTTPS link.

In the prior art, in order to avoid multiple interactions and a large number of calculations in the subsequent handshake process, Session is generally used. Resumption (session reuse), Session Resumption includes Session Ticket (session record) reuse and Session ID (session identification) reuse. Among them, Session Ticket reuse is that the server generates a session record to record information related to secure communication such as the key negotiated successfully with the client in the handshake process, and sends the encrypted session record to the client for subsequent follow-up The client carries the encrypted session record in the handshake request, and the server uses the key to decrypt the session record, reuses information related to secure communication such as the successfully negotiated key in the previous handshake process, reduces the RTT to one, and completes the handshake quickly Process.

The inventor realized that although this saves time for the handshake and reduces the consumption for the client and server, the encryption key of the session record is only saved by the server and never changes, which also brings the security of data transmission. Hidden dangers. In particular, the CDN edge servers all use the same key to encrypt the session records. Once cracked, all HTTPS will be invalid.

technical problem

In view of the above-mentioned problems, the purpose of this application is to provide a method, device and storage medium for the secure handshake between the client and the server. The method changes the situation that the session recording key is always unchanged, increases the difficulty of deciphering the session recording key, and enhances the security of data transmission.

Technical solutions

According to one aspect of the present application, a method for secure handshake between a client and a server is provided. The secure handshake between the client and the server is realized by using session record reuse in the handshake phase of the client and the server, including the following steps.

S110: The server generates a session recording key every first set period of time and saves it in its memory, and the session recording key is deleted when the storage time of the memory exceeds a preset validity period.

S120: The server uses the newly generated session record key to encrypt the session record generated by the initial handshake between the client and the server, and sends the encrypted session record to the client; where , The session record includes a negotiation key used to encrypt the interactive content between the client and the server.

S130: When the client carries the encrypted session record and performs a subsequent handshake with the server, the server sequentially calls the session record key in its memory to decrypt the encrypted session record, if If the decryption is successful, the client and the server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, proceed to S120.

According to another aspect of the present application, there is provided a secure handshake method between a client and a server. The secure handshake between the client and the server is realized by using session record reuse during the handshake phase of the client and the server, and the server It is the CDN edge server in CDN, including the following steps.

S210: Set a server as a central server, and the central server generates a session record key every first set period, saves it in its memory, and synchronously saves the session record key to each CDN node In the memory of the CDN edge server, the session recording key is deleted when the storage time in the memory of the central server and the CDN edge server exceeds a preset validity period.

S220: The CDN edge server invokes the session record key newly stored in its memory to encrypt the session record generated by the initial handshake between the client and the CDN edge server, and sends the encrypted session record to all The client; wherein the session record contains a negotiation key used to encrypt the interactive content between the client and the server.

S230: When the client carries the encrypted session record and performs a subsequent handshake with the CDN edge server, the CDN edge server sequentially calls its memory in the order of the storage time of the session record key from near to far. The session record key in the session record decrypts the encrypted session record. If the decryption is successful, the client and the CDN edge server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful , Then proceed to S220.

According to another aspect of the present application, there is provided an electronic device, including: a memory and a processor, the memory is stored with a computer program, and the computer program is executed by the processor to realize the following client and server security Steps of the handshake method.

S120: The server uses the newly generated session record key to encrypt the session record generated by the initial handshake between the client and the server, and sends the encrypted session record to the client; where The session record includes a negotiation key used to encrypt the interactive content between the client and the server.

According to another aspect of the present application, a computer-readable storage medium is provided. The computer-readable storage medium stores a client and server secure handshake program, and the client and server secure handshake program is processed by a processor. When executed, the steps of the following method of secure handshake between the client and the server are implemented.

Beneficial effect

Using the above-mentioned method of secure handshake between the client and the server according to the present application, the session recording key is periodically reset, and the reset key can be synchronized to all CDN nodes. Ensure that the session recording key generated in each cycle is different. The session records of the HTTPS connection handshake phase in the latest cycle are encrypted and decrypted with the latest key, and the session records generated by the HTTPS connection in the previous cycle are decrypted one by one with the decryption key generated in the previous cycle. Only the session record key within the validity period is saved. After the validity period, the client carries the encrypted session record and sends a request to the server again, and the session record cannot be decrypted. The client must renegotiate the key with the server to generate the session record and use the latest session record. Key encryption. The situation that the session recording key is always the same is changed, the difficulty of deciphering the session recording key is increased, and the security of data transmission is enhanced.

Description of the drawings

Fig. 1 is a flowchart of a method for secure handshake between a client and a server according to Embodiment 1 of the present application.

Fig. 2 is a flowchart of a method for secure handshake between a client and a server according to Embodiment 2 of the present application.

3 is a schematic diagram of the logical structure of a system for secure handshake between a client and a server according to Embodiment 4 of the present application.

Embodiments of the present invention

In the following description, for illustrative purposes, in order to provide a comprehensive understanding of one or more embodiments, many specific details are set forth. However, it is obvious that these embodiments can also be implemented without these specific details. In other examples, for the convenience of describing one or more embodiments, well-known structures and devices are shown in the form of block diagrams. For ease of understanding, the following will explain the terms appearing in this application.

CDN: Content delivery network, simply means to cache content in different locations, through load balancing and other technologies to direct user requests to the nearest cache server to obtain content, so as to improve the corresponding speed of users' access to the website.

CDN edge server: The nearest cache server mentioned above. The main purpose is to store the content as close to the user as possible, thereby reducing delay and improving page loading time.

Asymmetric key: Unlike symmetric encryption algorithm, asymmetric encryption algorithm requires two keys, a public key and a private key. The public key and the private key are a pair. If the public key is used to encrypt data, only the corresponding private key can be used to decrypt it.

The specific embodiments of the present application will be described in detail below with reference to the accompanying drawings.

Embodiment 1: FIG. 1 is a flowchart of a method for a secure handshake between a client and a server according to Embodiment 1 of the present application.

As shown in FIG. 1, in the method of the client and the server secure handshake in this embodiment, the application scenario is that when the client is connected to a single server, the session record reuse is used in the handshake phase. For the secure transmission of data between the client and the server, the HTTPS protocol is used when establishing a connection. The TLS/SSL protocol in the HTTPS protocol uses a session record reuse session cache mechanism during the handshake phase. The client initiates the first request to the server. The server and the client start the first handshake process to negotiate a key. After the negotiation is successful, a session record is generated. The server encrypts the session record and sends the session record to the client. When the client initiates a request to the server again, it does not need to perform key negotiation again, and only needs to carry the encrypted session record. As long as the server can decrypt the session record, the handshake process is completed. The client and the server start data transmission, and the transmitted data is encrypted and transmitted using the negotiated key in the session record.

The method for the secure handshake between the client and the server in this embodiment includes the following steps.

S110: The server generates a session record key every first set period of time and saves it in its memory, and the session record key is deleted when the storage time of the session record key in the memory exceeds the preset validity period.

The session recording key can be a symmetric key or an asymmetric key. The preset validity period should be greater than the first set cycle time, and the preset validity period is preferably set to be greater than or equal to three times the first set cycle time.

In this embodiment, the first set cycle time may be 1 hour, and the preset validity period may be 24 hours. The server saves the session record key generated within 24 hours in its memory in the order of the generated time, and clears the session record key generated 24 hours ago from the memory.

S120: The server uses the newly generated session record key to encrypt the session record generated by the initial handshake between the client and the server, and sends the encrypted session record to the client; the session record contains the session record used to encrypt the client and The negotiated key of the server's interactive content.

The client and the server perform an initial handshake to generate a session record, and the server uses the newly generated session record key to encrypt the session record, and sends the encrypted session record to the client.

Each time the client establishes an HTTPS connection with the server, the encryption key of the session record generated during the handshake phase is not exactly the same. Only when the client and the server establish an HTTPS connection within the same first set period of time (1 hour), The encryption keys of the session records generated in the handshake phase are the same. Compared with the session records generated at any time in the prior art, the session records are encrypted using a unified key, which increases the security.

When the client establishes an HTTPS connection with the server for the first time, if the server is in the initialized state, the client and the server in the initialized state use a randomly generated key for encryption when the session record is generated by the initial handshake. If the server is not in the initial state, the client and the server use the newly generated encryption key for encryption when the session record is generated by the initial handshake.

S130: When the client carries the encrypted session record and performs subsequent handshake with the server, the server sequentially calls the session record key in its memory to decrypt the encrypted session record. If the decryption is successful, the client and the server reuse For the negotiated key in the session record, the handshake is completed; if the decryption is unsuccessful, proceed to S120.

During the subsequent handshake between the client and the server, the encrypted session record is carried, and the server sequentially calls the session record key in its memory to decrypt the encrypted session record.

When decrypting the session record, the server sequentially calls the session record decryption key in its memory to decrypt the encrypted session record in the order of the generation time of the session record key from near to far.

For example, when the client initiates a request to the server again within the same first set period of time (1 hour), the encrypted session record is carried in the handshake process, and the server uses the newly generated session record decryption key to give the session record Decrypt, the decryption is successful and the handshake is completed; if the client initiates a request to the server after the same first set period of time (1 hour), the encrypted session record is carried in the handshake process, and the server uses the newly generated session Record the decryption key to decrypt the session record, and the decryption fails. The server then calls the session record decryption keys stored in the memory in sequence according to the generation time of the session record key from near to far, and decrypts the session record until the decryption is successful. , The handshake is completed; if the server decryption is unsuccessful, it means that the session record has expired, or the key of this session record has been cleared in the memory (more than 24 hours), then restart S120, as the client and server are established for the first time HTTPS connection, the client and the server handshake for the first time, renegotiate the key to generate the session record, and use the latest session record key stored in the memory for encryption, send the client to save, and complete the handshake.

Embodiment 2: FIG. 2 is a flowchart of a method for secure handshake between a client and a server according to Embodiment 2 of the present application.

As shown in Figure 2, in this embodiment, the client and server secure handshake method, the application scenario is that the client connects to multiple servers, the handshake phase adopts session record reuse, and the server can be each CDN in the CDN The CDN edge server of the node. Including the following steps.

S210: Set a server as a central server, and the central server generates a session record key every first set period, saves it in its memory, and synchronously saves the session record key to the CDN edge server of each CDN node In the memory of, the session record key is deleted when the storage time in the memory of the central server and the CDN edge server exceeds the preset validity period.

In this embodiment, the first set cycle time may be 1 hour, and the preset validity period may be 24 hours. The central server saves the session record keys generated within 24 hours in its memory in accordance with the generated time sequence, and the central server clears the session record keys generated 24 hours ago from its memory. The CDN edge server of each CND node synchronizes and saves the session record key generated by the central server within 24 hours in its memory according to the generated time sequence. The CDN edge server of each CND node encrypts the session record stored 24 hours ago. The key is cleared from its memory.

S220: The CDN edge server calls the latest session record key stored in its memory to encrypt the session record generated by the initial handshake between the client and the CDN edge server, and sends the encrypted session record to the client; among them, the session record contains the It is used to encrypt the negotiated key of the interactive content between the client and the server.

The client and the CDN edge server first shake hands to generate a session record. The CDN edge server uses the latest session record key stored in its memory to encrypt the session record, and sends the encrypted session record to the client.

Every time the client establishes an HTTPS connection with the CDN edge server, the encryption key of the session record generated during the handshake phase is not exactly the same, only the client and the CDN edge server are established within the same first set period of time (1 hour) During the HTTPS connection, the session record encryption key generated in the handshake phase is the same. Compared with the prior art, all CDN edge servers use the same key to encrypt the session record at any time, which increases security.

Furthermore, when the client establishes an HTTPS connection with the CDN edge server for the first time, if the CDN edge server is in the initial state, the client and the CDN edge server in the initial state shake hands to generate the session record for the first time, and then call the newly generated session record encryption key in the memory of the central server Encrypted session recording. After that, the CDN edge server began to synchronize and save the session record key in the memory of the central server.

S230: When the client carries the encrypted session record and performs the subsequent handshake with the CDN edge server, the CDN edge server sequentially calls the session record key in its memory to encrypt the encrypted session record key in the order of the preservation time of the session record key. The session record is decrypted. If the decryption is successful, the client and the CDN edge server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, proceed to S220.

In the subsequent handshake between the client and the CDN edge server, the encrypted session record is carried. The CDN edge server sequentially calls the session record key in its memory to encrypt the session in the order of the preservation time of the session record key. The record is decrypted.

For example, when the client initiates a request to the CDN edge server again within the same first set period of time (1 hour), the encrypted session record is carried in the handshake process, and the CDN edge server uses the latest synchronously saved session record decryption key Decrypt the session record, the decryption is successful and the handshake is completed; if the client initiates a request to the CDN edge server after the same first set period of time (1 hour), the encrypted session record is carried in the handshake process, and the CDN edge The server decrypts the session record using the latest synchronously saved session record decryption key. If the decryption fails, the CDN edge server then calls the session record decryption key stored in its memory in order of the session record key storage time from near to farthest. Decrypt the session record until the decryption is successful and the handshake is completed. If the decryption is unsuccessful, it means that the session record has expired, or the key of the session record has been cleared in the CDN edge server memory (more than 24 hours), then perform S220 again, and the client and the CDN edge server re-establish the HTTPS connection. As the first handshake between the client and the CDN edge server, the key is renegotiated to generate a session record, and the session record is encrypted using the latest session record encryption key stored in the CDN edge server's memory.

In this embodiment, when the client establishes an HTTPS connection with the CDN edge server again, the key used to decrypt the session record during the handshake phase is not exactly the same, only the client and the CDN edge within the same first set period of time (1 hour) The decryption key of the session record generated when the server establishes the HTTPS connection for the first time is the same. Compared with the prior art, all CDN edge servers use a unified key to decrypt the session record at any time, which increases the security.

The session recording key can be a symmetric key. The symmetric key generation method in this application is: a 48-bit random number is regularly generated every 1 hour.

Embodiment 3: On the basis of Embodiment 2, the session recording key can also be an asymmetric key. When the session recording key is an asymmetric key, S210 further includes that the method of generating the asymmetric key is: central The server generates a private key for each CDN edge server and a public key corresponding to the private key according to the IP of each CDN edge server every first set period of time. Synchronize the private key and its corresponding public key to the memory of the corresponding CDN edge server. The memory of the central server and the memory of each CDN edge server only save the private key and the corresponding public key generated within the preset validity period. That is, the asymmetric session recording key is deleted when the storage time in the memory of the central server and the CDN edge server exceeds the preset validity period.

The public key is used to encrypt session records, and each CDN edge server uses its stored private key randomly generated according to its IP to decrypt the session record encrypted by the public key.

The central server saves all private keys and corresponding public keys generated within the preset validity period in the memory according to the generated time sequence, and the central server clears all private keys and their corresponding public keys generated before the preset validity period from the memory.

The CDN edge server synchronously saves the private key and the public key corresponding to the private key generated by its IP within the preset validity period, and saves it in the memory according to the generated time sequence. The CDN edge server synchronizes the private key and the private key saved before the preset validity period. The public key is cleared from memory.

S220 further includes that the CDN edge server invokes the latest public key stored in its memory to encrypt the session record generated by the initial handshake between the client and the CDN edge server, and sends the encrypted session record to the client.

During the initial handshake between the client and the CDN edge server, the CDN edge server invokes the latest public key stored in its memory to encrypt the session record, and sends the encrypted session record to the client.

S230 further includes that when the client carries the public key-encrypted session record and performs the subsequent handshake with the CDN edge server, the CDN edge server sequentially calls the private key in its memory to perform the session record according to the order of the preservation time of the private key. Decrypt. If the decryption is successful, the client and the CDN edge server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, proceed to S220.

In the subsequent handshake between the client and the CDN edge server, the public key encrypted session record is carried. The CDN edge server sequentially calls the private key in its memory to decrypt the session record according to the order of the preservation time of the private key.

When using an asymmetric key, when each CDN edge server establishes an HTTPS connection with the client again, the private key used to decrypt the session record during the handshake phase is different. Each CDN edge server has its own private key to decrypt the session record, and the private key of the same CDN edge server in different first set period time is also different. Compared with the existing technology, it is more secure.

Embodiment 4: FIG. 3 is a schematic diagram of the logical structure of a system for secure handshake between a client and a server according to Embodiment 4 of the present application.

As shown in FIG. 3, a client and server secure handshake system corresponding to the method in Embodiment 1, includes: a handshake phase setting unit, a session record key generation unit, a session record encryption unit, and a session record decryption unit.

The handshake phase setting unit is used to set the handshake phase between the client and the server, and the session record is reused to realize the secure handshake between the client and the server.

The session recording key generating unit is used for the server to generate a session recording key every first set period of time and save it in its memory, and the session recording key is deleted when the storage time in the memory exceeds the preset validity period.

The session record encryption unit is used for the server to use the newly generated session record key to encrypt the session record generated by the initial handshake between the client and the server, and send the encrypted session record to the client; among them, the session record contains the It is used to encrypt the negotiated key of the interactive content between the client and the server.

The session record decryption unit is used for the client to carry the encrypted session record for subsequent handshake with the server. The server sequentially calls the session record key in its memory to decrypt the encrypted session record. If the decryption is successful, the client The client and the server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, the client and the server re-shakes hands to generate the session record, and the server uses the newly generated session record key to encrypt the session record and encrypt it After the session record is sent to the client.

Embodiment 5: A client and server secure handshake system corresponding to the method in Embodiment 2, including: a handshake phase setting unit, a session record key generation unit, a session record encryption unit, and a session record decryption unit.

The handshake phase setting unit is used to set the handshake phase between the client and each CDN edge server in the CDN, and session records are reused to realize the secure handshake between the client and the server.

The session recording key generation unit is used to set a server as the central server, and the central server generates the session recording key every first set period, saves it in its memory, and synchronously saves the session recording key to every In the memory of the CDN edge server of a CDN node, the session record key is deleted when the storage time in the memory of the central server and the CDN edge server exceeds the preset validity period.

The session record encryption unit is used for the CDN edge server to call the newly saved session record key in its memory to encrypt the session record generated by the client and the CDN edge server through the initial handshake, and send the encrypted session record to the client; The session record contains the negotiation key used to encrypt the interactive content between the client and the server.

The session record decryption unit is used for the client to carry the encrypted session record for subsequent handshake with the CDN edge server. The CDN edge server calls the session record secret in its memory in the order of the preservation time of the session record key from near to far. The key decrypts the encrypted session record. If the decryption is successful, the client and the CDN edge server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, the client and the CDN edge server re-handshake to generate a session To record, the CDN edge server calls the newly saved session record key in its memory to encrypt the session record, and sends the encrypted session record to the client.

Embodiment 6: An electronic device including a memory and a processor, and a computer program is stored in the memory. When the computer program is executed by the processor, it realizes the secure handshake between the client and the server of Embodiment 1 or Embodiment 2 or Embodiment 3 Method steps.

Embodiment 7: A computer-readable storage medium. The computer-readable storage medium may be non-volatile or volatile. Wherein, the computer-readable storage medium stores a client and server secure handshake program. When the client and server secure handshake program is executed by the processor, the client and service of Embodiment 1 or Embodiment 2 or Embodiment 3 are implemented. Steps of the end-to-end secure handshake method.

The method of the client and the server secure handshake according to the present application is described by way of example with reference to FIG. 1 and FIG. 2 above. However, those skilled in the art should understand that various improvements can be made without departing from the content of the application for the secure handshake method between the client and the server proposed in this application. Therefore, the protection scope of this application should be determined by the content of the appended claims.

The above are only specific implementations of this application, but the protection scope of this application is not limited to this. Any person skilled in the art can easily think of changes or substitutions within the technical scope disclosed in this application. Should be covered within the scope of protection of this application. Therefore, the protection scope of this application should be subject to the protection scope of the claims.

Claims

A method for secure handshake between the client and the server is achieved by using session record reuse in the handshake phase of the client and the server to realize the secure handshake between the client and the server, which includes the following steps:

S110: The server generates a session recording key every first set period of time and saves it in its memory, and the session recording key is deleted when the storage time of the memory exceeds a preset validity period;

S120: The server uses the newly generated session record key to encrypt the session record generated by the initial handshake between the client and the server, and sends the encrypted session record to the client; where The session record includes a negotiation key used to encrypt the interactive content between the client and the server;

S130: When the client carries the encrypted session record and performs a subsequent handshake with the server, the server sequentially calls the session record key in its memory to decrypt the encrypted session record, if If the decryption is successful, the client and the server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, proceed to S120.
8. The method for secure handshake between a client and a server according to claim 1, wherein the preset validity period is not less than three times the first preset period time.
The method for a secure handshake between a client and a server according to claim 1, wherein:

In S110, the server stores the session record keys generated within the preset validity period in its memory according to the generated time sequence;

In S130, the server sequentially calls the session record key in its memory to decrypt the encrypted session record in the order of the generation time of the session record key from near to far.
A method for the secure handshake between the client and the server is achieved by using session record reuse in the handshake phase between the client and the server to realize the secure handshake between the client and the server, and the server is a CDN edge server in the CDN, wherein, It includes the following steps:

S210: Set a server as a central server, and the central server generates a session record key every first set period, saves it in its memory, and synchronously saves the session record key to each CDN node In the memory of the CDN edge server, the session recording key is deleted when the storage time in the memory of the central server and the CDN edge server exceeds a preset validity period;

S220: The CDN edge server invokes the session record key newly stored in its memory to encrypt the session record generated by the initial handshake between the client and the CDN edge server, and sends the encrypted session record to all The client; wherein the session record includes a negotiation key used to encrypt the interactive content between the client and the server;

S230: When the client carries the encrypted session record and performs a subsequent handshake with the CDN edge server, the CDN edge server sequentially calls its memory in the order of the storage time of the session record key from near to far. The session record key in the session record decrypts the encrypted session record. If the decryption is successful, the client and the CDN edge server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful , Then proceed to S220.
The method for secure handshake between the client and the server according to claim 4, wherein the preset validity period is not less than three times the first preset period time.
The method for a secure handshake between a client and a server according to claim 4, wherein, in S210, the session recording key is an asymmetric key, and the method for generating the asymmetric key is: the central server At intervals of the first set period of time, a private key and a public key corresponding to the private key are generated for each CDN edge server according to the IP of each CDN edge server, and the private key and its The corresponding public key is synchronously saved in the memory of the corresponding CDN edge server.
The method for a secure handshake between a client and a server according to claim 6, wherein S220 further comprises: the CDN edge server invokes the latest public key stored in its memory to encrypt the client and the CDN edge server The session record generated by the initial handshake, and the encrypted session record is sent to the client.
8. The method for secure handshake between a client and a server according to claim 6, wherein S230 further comprises: when the client carries the session record encrypted by the public key and performs a subsequent handshake with the CDN edge server, The CDN edge server sequentially calls the private key in its memory to decrypt the session record in the order of the storage time of the private key from near to far. If the decryption is successful, the client and the CDN edge service The terminal reuses the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, proceed to S220.
An electronic device, comprising a memory and a processor, the memory and the processor are connected to each other, the memory is used to store a computer program, the computer program is configured to be executed by the processor, the computer The program configuration is used to implement a method for a client and server secure handshake. The method uses session record reuse in the client and server handshake phase to achieve a secure handshake between the client and the server. The method includes the following steps:

S110: The server generates a session recording key every first set period of time and saves it in its memory, and the session recording key is deleted when the storage time of the memory exceeds a preset validity period;

S120: The server uses the newly generated session record key to encrypt the session record generated by the initial handshake between the client and the server, and sends the encrypted session record to the client; where The session record includes a negotiation key used to encrypt the interactive content between the client and the server;

S130: When the client carries the encrypted session record and performs a subsequent handshake with the server, the server sequentially calls the session record key in its memory to decrypt the encrypted session record, if If the decryption is successful, the client and the server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, proceed to S120.
9. The electronic device of claim 9, wherein the preset validity period is not less than three times the first preset period time.
The electronic device according to claim 9, wherein:

In S110, the server stores the session record keys generated within the preset validity period in its memory according to the generated time sequence;

In S130, the server sequentially calls the session record key in its memory to decrypt the encrypted session record in the order of the generation time of the session record key from near to far.
An electronic device, comprising a memory and a processor, the memory and the processor are connected to each other, the memory is used to store a computer program, the computer program is configured to be executed by the processor, the computer The program is configured to perform a secure handshake method between the client and the server. The method uses session record reuse during the handshake phase of the client and the server to realize the secure handshake between the client and the server, and the server is a CDN In the CDN edge server in, the method includes the following steps:

S210: Set a server as a central server, and the central server generates a session record key every first set period, saves it in its memory, and synchronously saves the session record key to each CDN node In the memory of the CDN edge server, the session recording key is deleted when the storage time in the memory of the central server and the CDN edge server exceeds a preset validity period;

S220: The CDN edge server invokes the session record key newly stored in its memory to encrypt the session record generated by the initial handshake between the client and the CDN edge server, and sends the encrypted session record to all The client; wherein the session record includes a negotiation key used to encrypt the interactive content between the client and the server;

S230: When the client carries the encrypted session record and performs a subsequent handshake with the CDN edge server, the CDN edge server sequentially calls its memory in the order of the storage time of the session record key from near to far. The session record key in the session record decrypts the encrypted session record. If the decryption is successful, the client and the CDN edge server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful , Then proceed to S220.
11. The electronic device of claim 12, wherein the preset validity period is not less than three times the first preset period time.
The electronic device according to claim 12, wherein, in S210, the session recording key is an asymmetric key, and the method of generating the asymmetric key is: the central server every first device According to the IP of each CDN edge server, generate a private key and a public key corresponding to the private key according to the IP of each CDN edge server, and save the private key and its corresponding public key to In the memory of the corresponding CDN edge server.
The electronic device according to claim 14, wherein S220 further comprises: the CDN edge server invokes the latest public key stored in its memory to encrypt the session record generated by the initial handshake between the client and the CDN edge server, And send the encrypted session record to the client.
The electronic device according to claim 14, wherein, S230 further comprises: when the client carries the session record encrypted by the public key and performs a subsequent handshake with the CDN edge server, the CDN edge server performs a subsequent handshake with the CDN edge server. In the order of the storage time of the private key from near to far, the private key in its memory is sequentially invoked to decrypt the session record. If the decryption is successful, the client and the CDN edge server reuse the session record. The handshake is completed; if the decryption is unsuccessful, proceed to S220.
A computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it is used to realize a secure handshake method between a client and a server. In the handshake phase between the client and the server, the session record is reused to implement a secure handshake between the client and the server. The method includes the following steps:

S110: The server generates a session recording key every first set period of time and saves it in its memory, and the session recording key is deleted when the storage time of the memory exceeds a preset validity period;

S120: The server uses the newly generated session record key to encrypt the session record generated by the initial handshake between the client and the server, and sends the encrypted session record to the client; where The session record includes a negotiation key used to encrypt the interactive content between the client and the server;

S130: When the client carries the encrypted session record and performs a subsequent handshake with the server, the server sequentially calls the session record key in its memory to decrypt the encrypted session record, if If the decryption is successful, the client and the server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful, proceed to S120.
17. The computer-readable storage medium of claim 17, wherein the preset validity period is not less than three times the first set period time.
The computer-readable storage medium of claim 17, wherein:

In S110, the server stores the session record keys generated within the preset validity period in its memory according to the generated time sequence;

In S130, the server sequentially calls the session record key in its memory to decrypt the encrypted session record in the order of the generation time of the session record key from near to far.
A computer-readable storage medium, the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it is used to realize a secure handshake method between a client and a server. During the handshake phase between the client and the server, session record reuse is used to implement a secure handshake between the client and the server, and the server is a CDN edge server in the CDN. The method includes the following steps:

S210: Set a server as a central server, and the central server generates a session record key every first set period, saves it in its memory, and synchronously saves the session record key to each CDN node In the memory of the CDN edge server, the session recording key is deleted when the storage time in the memory of the central server and the CDN edge server exceeds a preset validity period;

S220: The CDN edge server invokes the session record key newly stored in its memory to encrypt the session record generated by the initial handshake between the client and the CDN edge server, and sends the encrypted session record to all The client; wherein the session record includes a negotiation key used to encrypt the interactive content between the client and the server;

S230: When the client carries the encrypted session record and performs a subsequent handshake with the CDN edge server, the CDN edge server sequentially calls its memory in the order of the storage time of the session record key from near to far. The session record key in the session record decrypts the encrypted session record. If the decryption is successful, the client and the CDN edge server reuse the negotiated key in the session record, and the handshake is completed; if the decryption is unsuccessful , Then proceed to S220.