CN112511597A

CN112511597A - Method and device for multiplexing TLS connection

Info

Publication number: CN112511597A
Application number: CN202011233669.7A
Authority: CN
Inventors: 李绍辉; 任亚茹; 郑闯
Original assignee: Hangzhou DPTech Technologies Co Ltd
Current assignee: Hangzhou DPTech Technologies Co Ltd
Priority date: 2020-11-06
Filing date: 2020-11-06
Publication date: 2021-03-16
Anticipated expiration: 2040-11-06
Also published as: CN112511597B

Abstract

The application provides a method and a device for multiplexing TLS connection, which achieve the multiplexing of TLS connection in the process of sending HTTP request by combining the process of multiplexing TLS connection with the process of sending HTTP request, thereby realizing the reduction of the time required by the multiplexing process of TLS connection to 0 RTT.

Description

Method and device for multiplexing TLS connection

Technical Field

The present application relates to the field of computer networks, and in particular, to a method and an apparatus for multiplexing TLS connections.

Background

With the increasing requirement of people on network transmission Security, the TLS (Transport Layer Security) protocol for improving data transmission Security comes along. The principle is that when the connection is established but actual data transmission is not started, two parties of the session firstly carry out identity authentication, key exchange and negotiation encryption and decryption algorithms.

The specific process can be described as three handshakes of TLS, where the data makes two total round trips. The first round trip is that the client initiates a request to the server, the server returns a security certificate and a key, the second round trip is that the client sends a message for indicating information to confirm receipt to the server, and the server returns information for indicating the start of TLS connection, so that the TLS connection between the client and the server is realized. This process takes 2RTT (Round-Trip Time).

To reduce the number of RTTs, the related art selects a Session ticket (Session ticket) to multiplex the TLS connection. After the TLS connection is established for the first time, the client stores the session bill corresponding to the TLS connection. After the first established TLS connection is closed, in order to reuse the TLS connection, the client may send a request carrying the session ticket to the server, and after the server confirms that the session ticket is correct and has not expired, the server returns confirmation information, and then the two parties can reuse the previously closed TLS connection and related keys to start data transmission, thereby achieving the effect of multiplexing the TLS connection.

Using session ticket multiplexing TLS to connect this process only needs one round trip of data, which reduces one RTT compared to the previous three-way handshake, but still needs 1RTT to start transmitting data.

Disclosure of Invention

In view of this, the present application provides a method and an apparatus for multiplexing TLS connection, which can further reduce RTT of TLS connection.

According to a first aspect of the present application, there is provided a method for multiplexing transport layer security TLS connections, applied to a client, the method comprising:

after TCP connection is established with the server, if TLS session information is determined to be stored, a data request message is constructed; the data request message includes: the method comprises the steps that an HTTP request message to be sent, TLS session bills corresponding to TLS session information and first negotiation information which is generated by a client and used for generating TLS communication keys are sent;

sending the data request message to the server through a TCP connection, so that after the server verifies the TLS session bill, the TLS connection from the server to the client is recovered based on TLS session information restored from the TLS session bill and the TLS communication key generated through the first negotiation information and second negotiation information generated by the server, and a data response message used for indicating successful multiplexing is constructed and returned based on the second negotiation information and an HTTP response message to be returned;

when the data response message which is returned by the server and used for indicating successful multiplexing is received through the TCP connection, the TLS communication key is generated according to the second negotiation information and the first negotiation information;

and based on the session information and the TLS communication key, recovering the TLS connection from the client to the server.

Optionally, the HTTP request packet and the first negotiation information carried in the data request packet are encrypted by a first key and an encryption and decryption algorithm extracted from the TLS session information;

the encrypted HTTP request message and the encrypted first negotiation information are used for triggering the server to extract a first key and an encryption and decryption algorithm from TLS session information after the TLS session information is restored from a TLS session bill carried by the data request message, and the encrypted HTTP request message and the first negotiation information are decrypted to obtain the HTTP request message and the first negotiation information.

Optionally, the request message also carries a request summary; the request abstract is obtained by carrying out abstract calculation on the HTTP request message through a second key and an abstract algorithm extracted from the TLS session information; the request abstract is used for triggering the server side to respond to the decrypted HTTP request message to generate the HTTP response message after the request abstract passes the verification.

Optionally, the first key and the second key are extracted from the TLS session information by:

extracting a master key from the TLS session information;

extracting a first key from the master key according to the first specified byte number;

a second key is extracted from the master key based on the second specified number of bytes.

receiving a data request message sent by the client through TCP connection;

extracting a TLS session bill, first negotiation information which is generated by the server and used for generating a TLS communication key and an HTTP request message from the data request message;

responding the HTTP request to generate an HTTP response message;

after the TLS session bill passes the verification, generating the TLS communication key based on the first negotiation information and second negotiation information generated by the server, recovering TLS connection from the server to the client based on the TLS communication key and TLS session information restored from the TLS session bill, and constructing a data response message for indicating successful multiplexing based on the second negotiation information and the HTTP response message and returning the data response message to the client;

and the data response message is used for triggering the client to generate the TLS communication key according to the second negotiation information and the first negotiation information, and recovering the TLS connection from the client to the server side based on the TLS session information and the TLS communication key.

the extracting, from the session multiplexing packet, first negotiation information for generating a TLS communication key and an HTTP request generated by the client includes:

extracting a first key and an encryption and decryption algorithm from the session information, and decrypting the encrypted HTTP request message and the first negotiation information to obtain the HTTP request message and the first negotiation information.

Optionally, the data request packet further carries a request digest obtained by performing digest calculation on the HTTP request through a digest key and a digest algorithm extracted from the TLS session information;

the responding the HTTP request to generate an HTTP response message includes:

and after the request abstract is verified, responding to the HTTP request to generate an HTTP response message.

Optionally, the constructing, based on the second negotiation information and the HTTP response packet, a data response packet for indicating that multiplexing is successful and returning the data response packet to the client includes:

encrypting the HTTP response message by adopting the TLS communication key;

encrypting second negotiation information by adopting the first secret key and the encryption and decryption algorithm;

and constructing a message based on the encrypted HTTP response message and the second negotiation information, and returning the message to the client.

According to a third aspect of the present application, there is provided an apparatus for multiplexing transport layer security TLS connections, applied to a client, the apparatus comprising:

the construction unit is used for constructing a data request message if TLS session information is determined to be stored after TCP connection is established with the server; the data request message includes: the method comprises the steps that an HTTP request message to be sent, TLS session bills corresponding to TLS session information and first negotiation information which is generated by a client and used for generating TLS communication keys are sent;

a sending unit, configured to send the data request packet to the server through a TCP connection, so that after the server verifies the TLS session ticket, the server recovers the TLS connection from the server to the client based on TLS session information restored from the TLS session ticket and the TLS communication key generated by the first negotiation information and the second negotiation information generated by the server, and constructs a data response packet indicating successful multiplexing and returns the data response packet based on the second negotiation information and an HTTP response packet to be returned;

a receiving unit, configured to generate the TLS communication key according to the second negotiation information and the first negotiation information when the data response packet returned by the server and used for indicating that multiplexing is successful is received through the TCP connection;

and the recovery unit is used for recovering the TLS connection from the client to the server side based on the session information and the TLS communication key.

According to a third aspect of the present application, there is provided an apparatus for multiplexing transport layer security TLS connection, which is applied to a server, the apparatus comprising:

a receiving unit, configured to receive a data request packet sent by the client through a TCP connection;

the extracting unit is used for extracting a TLS session bill, first negotiation information which is generated by the client and used for generating a TLS communication key and an HTTP request message from the data request message;

the response unit responds to the HTTP request to generate an HTTP response message;

a recovery unit, configured to generate the TLS communication key based on the first negotiation information and second negotiation information generated by the server after the TLS session ticket is verified, recover TLS connection in a direction from the server to the client based on the TLS communication key and TLS session information restored from the TLS session ticket, construct a data response packet indicating successful multiplexing based on the second negotiation information and the HTTP response packet, and return the data response packet to the client;

The method and the device for multiplexing the transport layer secure TLS connection can combine the multiplexing TLS connection process and the process of sending the HTTP request, so that the multiplexing of the TLS connection is performed in the process of sending the HTTP request, and the time required by the TLS connection multiplexing process is reduced to 0 RTT.

Drawings

Fig. 1 is a flow chart illustrating a method for multiplexing TLS connections according to an exemplary embodiment of the present application;

FIG. 2 is a flow chart of a method for multiplexing TLS connections, as illustrated in an exemplary embodiment of the present application;

FIG. 3 is a flow chart of a method for multiplexing TLS connections as illustrated in an exemplary embodiment of the present application;

FIG. 4 is a flow chart of a method for multiplexing TLS connections, as illustrated in a most preferred exemplary embodiment of the present application;

fig. 5 is a hardware structure diagram of a client end of a bearer multiplexing TLS connection apparatus according to an exemplary embodiment of the present application;

FIG. 6 is a block diagram illustrating a multiplexed TLS connection apparatus in accordance with an exemplary embodiment of the present application;

fig. 7 is a hardware structure diagram of a server side of a bearer multiplexing TLS connection apparatus according to an exemplary embodiment of the present application;

fig. 8 is a block diagram of a multiplexing TLS connection apparatus according to an exemplary embodiment of the present application.

Detailed Description

Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.

The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the application. As used in this application and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.

It is to be understood that although the terms first, second, third, etc. may be used herein to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of the present application. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.

Data may be intercepted by the outside world when transmitted over a TCP connection, creating security problems. The TLS connection can be used at this time to improve the security of the data. When the client and the server are connected by using TLS, the data is in a state of being encrypted by the TLS connection related key in the transmission process, and the TLS connection related key is only held by both the client and the server, so that the data cannot be decrypted and acquired even if the data is intercepted by the outside in the transmission process, and the safety of the data is improved.

The first TLS connection setup by the client and server requires three handshakes, where the data makes two total round trips. The first round trip is that the client initiates a request to the server, the server returns a security certificate and a key, the second round trip is that the client sends a message for indicating the receipt of the confirmation to the server, and the server returns information for indicating the start of TLS connection, so that the TLS connection between the client and the server is realized. This process takes 2 RTT.

To reduce the amount of RTT, the prior art selects a session ticket to multiplex an unexpired session, and the process includes: after the client establishes TLS connection with the server for the first time, the client stores a session bill corresponding to the TLS connection; after the first established TLS connection is closed, if the client and the server want to reestablish the TLS connection, the client sends a request with a corresponding session bill to the server, the server returns confirmation information after confirming that the session bill is correct and not expired, then the two parties can restore the closed TLS connection, reuse the TLS connection for transmitting data, and achieve the effect of multiplexing the TLS connection. This process has only one data round trip, which is reduced compared with three-way handshake, but still needs 1RTT, and still consumes a lot of time when multiplexing a large number of TLS connections.

In view of this, the present application provides a scheme for multiplexing TLS connection, which can combine a multiplexing TLS connection process and a process of sending an HTTP request, so that multiplexing of TLS connection is performed in the process of sending the HTTP request, thereby reducing the time required for the multiplexing process of TLS connection to 0 RTT.

In order to make the technical solutions in the embodiments of the present application better understood and make the features and advantages of the embodiments of the present application more comprehensible, the technical solutions in the embodiments of the present application are described in further detail below with reference to the accompanying drawings.

Fig. 1 is a flowchart illustrating a method for multiplexing TLS connections according to an exemplary embodiment of the present application. Referring to fig. 1, the method includes:

step 102: after the client establishes TCP connection with the server, if TLS session information is determined to be stored, a data request message is constructed; the data request message includes: the method comprises the steps of sending an HTTP request message, a TLS session bill corresponding to the TLS session information, and first negotiation information which is generated by the client and used for generating a TLS communication key.

When a client needs to start to establish a TLS connection after establishing a TCP connection, it needs to first determine whether the TLS connection can be multiplexed.

The client may determine whether there is a reusable TLS connection by determining whether corresponding TLS session information is stored.

Specifically, after the TLS connection is first established with the server, the client records the correspondence between the session information of the TLS connection and the IP addresses and port addresses of the corresponding client and server.

When determining whether the TLS session information is stored, firstly, inquiring whether the session information corresponding to the IP addresses and the port addresses of the server and the client exists in the corresponding relation, if the session information is not inquired, indicating that no reusable TLS connection exists, and establishing a brand-new TLS connection by using TLS three-way handshake by the client; if the client side inquires, the client side needs to check whether the session information is expired, if the session information is aged within the aging time, the TLS connection can still be reused, if the aging time is exceeded, the TLS connection which can be reused does not exist, and the client side needs to establish connection by using TLS three-way handshake.

And constructing a data request message after determining that the TLS connection can be multiplexed. The data request packet may be a packet that extends the TLS protocol, for example, the formed packet may be a reply _ request type that extends the TLS subprotocol reply data (multiplexing data), or a packet of another protocol, where the data request packet is only exemplarily described here, and is not specifically limited.

Several implementations of constructing the data request message are described below.

Example 1: the client can construct a data request message based on the HTTP request to be sent, the TLS session ticket corresponding to the TLS session information, and the first negotiation information generated by the client for generating the TLS communication key.

Specifically, the client may obtain an HTTP request to be sent.

The HTTP request may be the first HTTP request to be sent, or the nth HTTP request to be sent, where the HTTP request to be sent is not limited. Optimally, the HTTP request message to be sent is the first HTTP request to be sent by the client, and at this time, the TLS connection can be established earlier, so that it is ensured that as much data as possible is sent by the client through the TLS connection, and the security of the data is improved.

In addition, the client may obtain a session ticket. And after the three-way handshake establishes connection, the client stores the corresponding session bill for connection. In general, a session ticket is generated by a server and encrypted by using a ticket key (ticket key) before being sent to a client for storage.

Further, the client may also generate first negotiation information for generating the TLS traffic key.

The first negotiation information generated by the client for generating the TLS communication key may be a 32-bit random number generated by the client, or may be a sum of multiple random numbers generated by the client, and the first negotiation information is only exemplified here, and is not limited in particular. Because the first negotiation information is randomly generated, the same random number sequence cannot be obtained outside, so that the TLS communication keys generated during each multiplexing connection are different and are difficult to be known by the outside, and the security of the TLS communication keys is improved.

Example 2: the client side can construct a data request message based on the encrypted HTTP request to be sent, the TLS session ticket corresponding to the TLS session information, and the encrypted first negotiation information generated by the client side and used for generating the TLS communication key.

Because the client sends the data request message without completing the TLS connection with the server, there is a risk that the content of the data request message is captured and learned by the outside, in order to improve the security of the data request message, the HTTP request to be sent and the first negotiation information may be encrypted, and then the data request message is constructed based on the encrypted HTTP request and the encrypted first negotiation information.

The present application provides an encryption method as follows:

the client may encrypt the HTTP request packet to be sent and the first negotiation information using the first key and the encryption/decryption algorithm extracted from the TLS session information, respectively. The first key may be a pre-encryption key (pre _ key) extracted from the TLS session information, or may be other sequences that can be used as keys in the TLS session information, and here, the first key is merely exemplified and is not limited in detail. The HTTP request message to be sent and the first negotiation information are encrypted, so that the safety of the data request message can be effectively improved.

Example 3: the client side can construct a data request message based on the encrypted HTTP request to be sent, the TLS session ticket corresponding to the TLS session information, the encrypted first negotiation information generated by the client side and used for generating the TLS communication key, and the request abstract.

In order to ensure the integrity of the HTTP request message to be sent in the transmission process, the data request message carries the encrypted first HTTP request to be sent, the encrypted first negotiation information, the session ticket, and the encrypted data digest.

The application provides a method for acquiring a request abstract, which comprises the following steps:

the client can extract the second key and the digest algorithm from the TLS session information, and perform digest calculation on the HTTP request packet. The second key may be a pre-Authentication key (pre _ MAC _ key) extracted from the TLS session information, the digest algorithm may select a Hash-based Message Authentication Code (HMAC), and calculate a corresponding request digest by using the second key and the HTTP request Message to be sent as inputs, or may select other keys and algorithms, where the second key and the digest algorithm are only exemplarily described and are not specifically limited. If the HTTP request message is changed a little, the calculated request summary will be distinct.

The request abstract is used for triggering the server to verify the request abstract and confirming whether the received HTTP request message is complete or not. In order to improve the security of the request digest, the HTTP request to be sent and the request digest may be encrypted by using the first key and the encryption and decryption algorithm in combination, or the HTTP request and the request digest may be encrypted separately.

Therefore, preferably, a data request message may be constructed based on the encrypted HTTP request, the first negotiation information, and the request digest.

In addition, as to how the client extracts the first key and the second key from the TLS session information, the application is not particularly limited, and an exemplary embodiment is provided as follows:

the client side can extract the main key from the TLS session information, and then extract the first key from the main key according to the first specified byte number and extract the second key from the main key according to the second specified byte number. The number of bytes specified may be set depending on the use case, for example, the upper 36 bytes of the master key may be used as the first key, the lower 12 bytes of the master key may be used as the second key, and so on.

Step 104: and the client sends the data request message to the server.

Step 106: and the server side extracts the TLS session bill, the first negotiation information which is generated by the client side and used for generating the TLS communication key and the HTTP request message from the data request message.

In an optional implementation manner, corresponding to embodiment 1, in embodiment 1, the data request packet carries an HTTP request to be sent, a TLS session ticket corresponding to TLS session information, and a first negotiation information server generated by the client and used for generating a TLS communication key, and the HTTP request and the first negotiation information may be directly extracted by the first negotiation information server.

Therefore, when extracting the TLS session ticket, the server can decrypt the acquired TLS session ticket using the corresponding ticket key.

In another optional implementation manner, corresponding to the above embodiment 2, in embodiment 2, the data request message carries, in addition to the TLS session ticket corresponding to the TLS session information, the encrypted HTTP request to be sent and the first negotiation information.

In order to obtain the encrypted first negotiation information and the encrypted HTTP request, the server may recover the TLS session information using the TLS session ticket, extract the first key and the encryption/decryption algorithm from the TLS session information, and decrypt the first negotiation information and the HTTP request packet.

Step 108: and the server responds to the HTTP request message to generate an HTTP response message.

In implementation, an optional implementation manner is that the server directly responds to an HTTP request message sent by the client, and generates an HTTP corresponding message.

In another optional implementation manner, corresponding to the above embodiment 3, in order to ensure that an HTTP request packet carried in the data request packet does not change in a transmission process, the data request packet carries an encrypted request digest in addition to the encrypted HTTP request to be sent, the encrypted TLS session ticket, and the encrypted first negotiation information. Therefore, the server can obtain the request summary besides the HTTP request message, the session ticket and the first negotiation information, verify the HTTP request message using the request summary, and respond to the HTTP request message after the HTTP request message passes the verification.

The detailed steps are as follows:

the server can obtain the request abstract from the data request message, and if the client encrypts the request abstract and the HTTP request message together and then sends the encrypted request abstract and the HTTP request message to the server, the server can decrypt the encrypted request abstract.

Specifically, the server may obtain the encrypted request digest from the data request packet, and then decrypt the request digest by using an encryption/decryption algorithm and a first key extracted from the recovered session information to obtain the request digest.

The server may then use the digest to validate the received HTTP request message.

In order to confirm that the received HTTP request message is not different from the sending time, the server side can firstly confirm whether the HTTP request message passes the abstract verification, if the HTTP request message passes the verification, the server side responds to the HTTP request message, and if the HTTP request message does not pass the verification, the TLS connection multiplexing fails.

When confirming whether the HTTP request message passes the abstract verification, the server side can calculate the abstract of the HTTP request message carried by the data request message by using a second key and an abstract algorithm, compare the request abstract carried by the data request message with the abstract calculated by the server side, if the comparison result is inconsistent, the received HTTP request message is changed in the transmission process, and if the verification fails, the TLS connection multiplexing of the server side fails; if the comparison result is consistent, the received HTTP request message is not changed in the transmission process, the verification is passed, and the server side continues to perform multiplexing TLS connection.

And after the HTTP request message passes the verification, the server side responds to the HTTP request message. The specific implementation mode is as follows: and the server side submits the HTTP request message passing the verification to an HTTP service program of an upper layer, and the upper layer responds to obtain a corresponding HTTP response message.

Step 110: and after the server side verifies the TLS session ticket, generating the TLS communication key based on the first negotiation information and the second negotiation information generated by the server side.

And after the server side verifies that the TLS session ticket is error-free and not expired, the TLS session ticket is used for recovering the TLS session information. The second negotiation information generated by the server may be a 32-bit random number generated by the server, or a sum of multiple random numbers generated by the server, and the like, and here, the second negotiation information is only exemplarily described, and is not specifically limited.

The TLS communication Key generated by the server may include an encryption Key (Key), an authentication Key (MAC _ Key), an initial Vector (IV, i.e., an Initialization Vector, a value used for block encryption), and the like, which is not specifically limited in this application. The TLS communication key generation method is not limited in the present application, and an exemplary TLS communication key generation method is as follows:

the server obtains a plurality of first hashes on the master key, the first negotiation information, the second negotiation information and different specific character strings obtained from the TLS session information by using a SHA-1 Algorithm (Secure Hash Algorithm 1). And (3) subjecting each first hash to an MD5 Algorithm (MD5 Message-Digest Algorithm, MD5 information Digest Algorithm) respectively with the first key, namely the pre-encryption key and a different specific character string to obtain a plurality of second hashes, and combining the second hashes to serve as the key material. The key material is the TLS communication key, and different components of the TLS communication key are obtained through different byte bit divisions.

Step 112: and the server restores the TLS connection from the server to the client based on the TLS communication key and the TLS session information restored from the TLS session ticket.

During implementation, the TLS communication key group and the related algorithm related to the TLS connection are stored in the TLS layer, and the TLS communication key of the recording layer is used for the server side to encrypt data, so that the server side needs to transfer the TLS communication key from the TLS layer to the recording layer, set the recording layer to be in a normal encryption and decryption state, and the subsequent data sent by the server side to the client side can be encrypted by using the TLS communication key of the recording layer, thereby realizing recovery of the TLS connection in the direction from the server side to the client side.

Step 114: and the server constructs a data response message for indicating successful multiplexing based on the second negotiation information and the HTTP response message.

In order to notify the client receiving the data response packet that TLS connection from the server to the client has been restored, the client may attach multiplexing indication information in the data response packet, for example, a variable may be set to indicate that multiplexing is successful, or may indicate that multiplexing is successful in other manners, which is not limited in this application. If the multiplexing failure is caused by abstract verification failure, session bill verification failure and the like, the data response message carries information indicating that the multiplexing is not successful, or the server does not select a response client, and the method for the server to notify the client of the multiplexing failure is not limited in the application.

The data response packet carrying the multiplexing indication information may be a packet that extends the TLS protocol, for example, the formed packet may be a reply _ response type that extends the TLS subprotocol reply data, or a packet of another protocol, where the data response packet is only exemplarily described here, and is not specifically limited.

Several implementations of constructing a data response packet are described below:

in an alternative implementation, the server constructs the data response message based on the multiplexing indication information, the second negotiation information, and the HTTP response message. In another optional implementation manner, the server constructs a data response message based on the encrypted multiplexing indication information, the second negotiation information and the HTTP response message.

The HTTP response message sent by the server may be intercepted by the outside during the transmission process, so that when constructing the data response message, the server may encrypt the HTTTP response message by using the TLS communication key and assemble the HTTTP response message into the data response message, so as to prevent the HTTP response message from being acquired by the outside.

Similarly, further, in order to prevent the second negotiation information in the data response message sent by the server from being obtained externally, the server may encrypt the second negotiation information using the first key and then assemble the second negotiation information into the data response message.

It should be noted that the key used by the server to encrypt the HTTP response message and to encrypt the second negotiation information is different. The server encrypts the HTTP response packet using the TLS communication key, but does not encrypt the second negotiation information using the TLS communication key, but encrypts the second negotiation information using the first key and the encryption/decryption algorithm that are both known to the client and the server, because:

the second negotiation information is a component of the TLS communication key, and if the second negotiation information is encrypted by using the TLS communication key, the situation that the client cannot acquire the second negotiation information because there is no TLS communication key when receiving the data response packet, and cannot acquire the second negotiation information and cannot acquire the TLS communication key occurs, so that the server can encrypt the second negotiation information by using the first key and an encryption and decryption algorithm, thereby avoiding the problem.

Furthermore, the server may also encrypt the second negotiation information and the multiplexing indication information together by using the first key and the encryption and decryption algorithm, and then assemble the second negotiation information and the multiplexing indication information into the data response message.

The reason why the multiplexing indication information is not encrypted using the TLS traffic key is that: the client needs to verify whether the multiplexing indication information in the data response message is the information indicating the successful multiplexing and then obtains the second negotiation information, and when the multiplexing indication information is encrypted by using the TLS communication key, the second negotiation information needs to be obtained first and then the multiplexing indication information needs to be obtained, so that the multiplexing indication information is encrypted by using the first key.

Step 116: and the server side sends the data response message to the client side.

Step 118: and after receiving the data response message, the client generates the TLS communication key according to the first negotiation information and the second negotiation information.

Step 118 is described in detail below by steps 1181 to 1184.

Step 1181: the client determines to receive a data response message for indicating successful multiplexing.

When the multiplexing is successfully performed, after receiving the data response message, the client may check whether the data response message is a data response message for indicating that the multiplexing is successful. If so, the following steps 1182 to 1184 are executed, i.e., the client acquires the second negotiation information, the client generates the TLS communication key, and the client acquires and processes the HTTP request. And if not, deleting the related TLS session information and the session ticket, and establishing connection between the client and the server through three times of handshaking.

The following describes a manner of checking whether the data response packet is a data response packet indicating successful multiplexing:

the client can obtain the multiplexing indication information from the data response message.

If the multiplexing indication information indicates that the multiplexing is successful, for example, the value of the multiplexing indication information is 1, determining that the data response message is a data response message for indicating that the multiplexing is successful;

if the multiplexing indication information indicates that multiplexing is unsuccessful, for example, the value of the multiplexing indication information is 0, it is determined that the data response packet is not a data response packet for indicating that multiplexing is successful.

Step 1182: and the client acquires the second negotiation information.

After determining that the data response packet indicating successful multiplexing is received, the client may obtain the second negotiation information from the data response packet.

During the obtaining, an optional implementation manner is to directly obtain the second negotiation information from the data response message; another optional implementation manner is that, for security, the data response message carries the encrypted second negotiation information, so that the second negotiation information can be obtained by decrypting with the first key during obtaining.

Step 1183: the client generates the TLS traffic key.

If the data response message carries the encrypted HTTP response message, the server may generate the TLS communication key based on the first negotiation information and the second negotiation information after acquiring the second negotiation information from the data response message, so as to perform the following step 1184 of decrypting and acquiring the HTTP response message. The method for generating the TLS communication key based on the first negotiation information and the second negotiation information is the same as the method for generating the TLS communication key by the server in step 110, and is not described herein again.

Step 1184: the client obtains and processes the HTTP request.

In an optional implementation manner, the client may directly obtain the HTTP request from the data response packet, and transmit the HTTP request to the upper layer for response; in another optional implementation manner, if the data response packet carries an encrypted HTTP response packet, the client decrypts the encrypted HTTP response packet to obtain the HTTP response packet and uploads the HTTP response packet to the upper layer, and the specific steps are as follows: after generating the TLS communication key, the client decrypts by using the TLS communication key to obtain the HTTP response message, and transmits the HTTP response message to the HTTP application program of the upper layer.

Step 120: and the client recovers the TLS connection from the client to the server side based on the session information and the TLS communication key.

Similar to step 112, the client transfers the TLS communication key from the TLS layer to the recording layer, and sets the recording layer to be in a normal encryption/decryption state, so that the data sent by the subsequent client to the server can be encrypted by using the TLS communication key set in the recording layer, thereby recovering the TLS connection in the direction from the server to the client.

Therefore, the multiplexing TLS connection process and the process of sending the HTTP request are combined, the multiplexing of the TLS connection is carried out in the process of sending the HTTP request, the client and the server use the same TLS communication key for encrypted communication, the multiplexing of the TLS connection in both directions is completed, and the effect of reducing the time required by the TLS connection multiplexing process to 0RTT is achieved.

Fig. 2 is a flowchart illustrating a method for multiplexing TLS connection according to an exemplary embodiment of the present application, where the flowchart may be applied to a client, and may include the following steps:

step 202: after TCP connection is established with the server, if TLS session information is determined to be stored, a data request message is constructed; the data request message includes: the method comprises the steps that an HTTP request message to be sent, TLS session bills corresponding to TLS session information and first negotiation information which is generated by a client and used for generating TLS communication keys are sent;

step 204: sending the data request message to the server through a TCP connection, so that after the server verifies the TLS session bill, the TLS connection from the server to the client is recovered based on TLS session information restored from the TLS session bill and the TLS communication key generated through the first negotiation information and second negotiation information generated by the server, and a data response message used for indicating successful multiplexing is constructed and returned based on the second negotiation information and an HTTP response message to be returned;

step 206: when the data response message which is returned by the server and used for indicating successful multiplexing is received through the TCP connection, the TLS communication key is generated according to the second negotiation information and the first negotiation information;

step 208: and based on the session information and the TLS communication key, recovering the TLS connection from the client to the server.

The detailed implementation manner can refer to the description in the above steps 102-120, and is not described herein again.

Fig. 3 is a flowchart illustrating a method for multiplexing TLS connection according to an exemplary embodiment of the present application, where the flowchart may be applied to a client, and may include the following steps:

step 302: receiving a data request message sent by the client through TCP connection;

step 304: extracting a TLS session bill, first negotiation information which is generated by the client and used for generating a TLS communication key and an HTTP request message from the data request message;

step 306: responding the HTTP request to generate an HTTP response message;

step 308: after the TLS session bill passes the verification, generating the TLS communication key based on the first negotiation information and second negotiation information generated by the server, recovering TLS connection from the server to the client based on the TLS communication key and TLS session information restored from the TLS session bill, and constructing a data response message for indicating successful multiplexing based on the second negotiation information and the HTTP response message and returning the data response message to the client; and the data response message is used for triggering the client to generate the TLS communication key according to the second negotiation information and the first negotiation information, and recovering the TLS connection from the client to the server side based on the TLS session information and the TLS communication key.

Fig. 4 is a flowchart of a method for multiplexing TLS connections according to a most preferred exemplary embodiment of the present application, which may include the following steps:

s402: after the client establishes TCP connection with the server, if TLS session information is determined to be stored, a data request message is constructed;

s404: the client performs abstract calculation on the HTTP request message by using a second key and an abstract algorithm extracted from the TLS session information to obtain a request abstract;

s406: the client encrypts a first HTTP request message to be sent, a request summary and first negotiation information which is generated by the client and used for generating a TLS communication key by using a first key and an encryption and decryption algorithm which are extracted from the TLS session information;

s408: the client constructs a data request message based on the encrypted HTTP request message, the encrypted request abstract, the encrypted first negotiation information and the encrypted session bill;

s410: the client sends the data request message to a server;

s412: the server side acquires a session bill from the data request message, and recovers TLS session information by using the session bill after the session bill passes verification;

s414: the server side extracts a first key, a second key, an encryption and decryption algorithm and a digest algorithm from the TLS session information;

s416: the server side decrypts the HTTP request message, the request abstract and the first negotiation information carried by the data request message by using the first secret key and the encryption and decryption algorithm;

s418: the server side uses a second key and a digest algorithm to perform digest verification on the HTTP request, and after the digest verification is passed, the HTTP request message is transmitted to an upper layer to obtain an HTTP response message;

s420: the server generates a TLS communication key based on the first negotiation information and second negotiation information generated by the server, and recovers TLS connection from the server to the client on the basis of the TLS communication key and the TLS session information;

s422: the server side encrypts second negotiation information and multiplexing indication information by using a first key and an encryption and decryption algorithm, encrypts the HTTP response message by using a TLS communication key, and constructs the encrypted second negotiation information, multiplexing indication information and HTTP response message into a data response message;

s424: the server side sends the data response message to the client side;

s426: the client decrypts the data response message by using a first key and an encryption and decryption algorithm to acquire the multiplexing indication information;

s428: if the client can obtain the multiplexing indication information, decrypting by using a first key and an encryption and decryption algorithm to obtain the second negotiation information, generating a TLS communication key based on the first negotiation information and the second negotiation information, and decrypting by using the communication key to obtain an HTTP response message;

s430: and the client recovers the TLS connection from the client to the server side based on the session information and the TLS communication key.

Corresponding to the foregoing embodiments of the multiplexing TLS connection method, the present application also provides embodiments of a multiplexing TLS connection apparatus applied to a client. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. The software implementation is taken as an example, and as a logical device, the device is formed by reading corresponding computer program instructions in the nonvolatile memory into the memory for operation through the processor of the client where the device is located. From a hardware aspect, as shown in fig. 5, a hardware structure diagram of a client where the multiplexing TLS device is located in the present application is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 5, a processor where the device is located in the embodiment may also include other hardware according to an actual function of the client, which is not described again.

Fig. 6 is a block diagram of a multiplexing TLS connection apparatus according to an exemplary embodiment of the present application, where the apparatus is applied to a client, and includes:

a constructing unit 602, configured to, after establishing a TCP connection with the server, if it is determined that TLS session information is already stored, construct a data request packet; the data request message includes: the method comprises the steps that an HTTP request message to be sent, TLS session bills corresponding to TLS session information and first negotiation information which is generated by a client and used for generating TLS communication keys are sent;

a sending unit 604, configured to send the data request packet to the server through a TCP connection, so that after the server verifies the TLS session ticket, the server recovers a TLS connection from the server to the client based on TLS session information restored from the TLS session ticket and the TLS communication key generated by the first negotiation information and the second negotiation information generated by the server, and constructs a data response packet indicating successful multiplexing and returns the data response packet based on the second negotiation information and an HTTP response packet to be returned;

a receiving unit 606, configured to generate the TLS communication key according to the second negotiation information and the first negotiation information when the data response packet returned by the server and used for indicating that multiplexing is successful is received through the TCP connection;

a recovering unit 608, configured to recover the TLS connection from the client to the server based on the session information and the TLS communication key.

Optionally, the HTTP request packet and the first negotiation information carried in the data request packet are encrypted by a first key and an encryption and decryption algorithm extracted from the TLS session information; the encrypted HTTP request message and the encrypted first negotiation information are used for triggering the server to extract a first key and an encryption and decryption algorithm from TLS session information after the TLS session information is restored from a TLS session bill carried by the data request message, and the encrypted HTTP request message and the first negotiation information are decrypted to obtain the HTTP request message and the first negotiation information.

Optionally, the constructing unit 602 extracts the first key and the second key from the TLS session information by: extracting a master key from the TLS session information; extracting a first key from the master key according to the first specified byte number; a second key is extracted from the master key based on the second specified number of bytes.

Corresponding to the foregoing embodiments of the multiplexing TLS connection method, the present application also provides embodiments of a multiplexing TLS connection apparatus applied to a server.

The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. The software implementation is taken as an example, and as a device in a logical sense, a processor of a service end reads corresponding computer program instructions in a nonvolatile memory into a memory for operation. From a hardware aspect, as shown in fig. 7, a hardware structure diagram of a service end where the multiplexing TLS device of the present application is located is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 7, a processor where the device is located in the embodiment may also include other hardware according to an actual function of the service end, which is not described again.

Fig. 8 is a block diagram of a multiplexing TLS connection apparatus according to an exemplary embodiment of the present application, where the apparatus is applied to a server side, and includes:

a receiving unit 802, configured to receive a data request packet sent by the client through a TCP connection;

an extracting unit 804, configured to extract, from the data request packet, a TLS session ticket, first negotiation information generated by the client and used for generating a TLS communication key, and an HTTP request packet;

a response unit 806, configured to respond to the HTTP request to generate an HTTP response packet;

a recovering unit 808, configured to generate the TLS communication key based on the first negotiation information and the second negotiation information generated by the server after the TLS session ticket is verified, recover a TLS connection from the server to the client based on the TLS communication key and the TLS session information restored from the TLS session ticket, construct a data response packet indicating successful multiplexing based on the second negotiation information and the HTTP response packet, and return the data response packet to the client;

the extracting unit 804 is configured to, when extracting, from the session multiplexing packet, first negotiation information used for generating a TLS communication key and an HTTP request generated by the client, extract a first key and an encryption/decryption algorithm from the session information, and decrypt the encrypted HTTP request packet and the first negotiation information to obtain the HTTP request packet and the first negotiation information.

the responding unit 806, when responding to the HTTP request to generate an HTTP response packet, is configured to respond to the HTTP request to generate an HTTP response packet after the request digest is verified.

Optionally, the recovering unit 808 is configured to encrypt the HTTP response packet with the TLS communication key when constructing a data response packet indicating successful multiplexing based on the second negotiation information and the HTTP response packet and returning the data response packet to the client; encrypting second negotiation information by adopting the first secret key and the encryption and decryption algorithm; and constructing a message based on the encrypted HTTP response message and the second negotiation information, and returning the message to the client.

The implementation process of the functions and actions of each unit in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.

The above-described embodiments of the apparatus are merely illustrative, and the units described as separate parts may or may not be physically separate, and parts displayed as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the scheme of the application. One of ordinary skill in the art can understand and implement it without inventive effort.

Embodiments of the subject matter and the functional operations described in this specification can be implemented in: digital electronic circuitry, tangibly embodied computer software or firmware, computer hardware including the structures disclosed in this specification and their structural equivalents, or a combination of one or more of them. Embodiments of the subject matter described in this specification can be implemented as one or more computer programs, i.e., one or more modules of computer program instructions, encoded on a tangible, non-transitory program carrier for execution by, or to control the operation of, data processing apparatus. Alternatively or additionally, the program instructions may be encoded on an artificially generated propagated signal, e.g., a machine-generated electrical, optical, or electromagnetic signal, that is generated to encode and transmit information to suitable receiver apparatus for execution by the data processing apparatus. The computer storage medium may be a machine-readable storage device, a machine-readable storage substrate, a random or serial access memory device, or a combination of one or more of them.

The processes and logic flows described in this specification can be performed by one or more programmable computers executing one or more computer programs to perform corresponding functions by operating on input data and generating output. The processes and logic flows can also be performed by, and apparatus can also be implemented as, special purpose logic circuitry, e.g., an FPGA (field programmable gate array) or an ASIC (application-specific integrated circuit).

Computers suitable for executing computer programs include, for example, general and/or special purpose microprocessors, or any other type of central processing unit. Generally, a central processing unit will receive instructions and data from a read-only memory and/or a random access memory. The basic components of a computer include a central processing unit for implementing or executing instructions and one or more memory devices for storing instructions and data. Generally, a computer will also include, or be operatively coupled to receive data from or transfer data to, or both, one or more mass storage devices for storing data, e.g., magnetic, magneto-optical disks, or optical disks. However, a computer does not necessarily have such a device. Moreover, a computer may be embedded in another device, e.g., a mobile telephone, a Personal Digital Assistant (PDA), a mobile audio or video player, a game console, a Global Positioning System (GPS) receiver, or a portable storage device such as a Universal Serial Bus (USB) flash drive, to name a few.

Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media and memory devices, including by way of example semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., an internal hard disk or a removable disk), magneto-optical disks, and CD ROM and DVD-ROM disks. The processor and the memory can be supplemented by, or incorporated in, special purpose logic circuitry.

While this specification contains many specific implementation details, these should not be construed as limitations on the scope of any invention or of what may be claimed, but rather as descriptions of features specific to particular embodiments of particular inventions. Certain features that are described in this specification in the context of separate embodiments can also be implemented in combination in a single embodiment. In other instances, features described in connection with one embodiment may be implemented as discrete components or in any suitable subcombination. Moreover, although features may be described above as acting in certain combinations and even initially claimed as such, one or more features from a claimed combination can in some cases be excised from the combination, and the claimed combination may be directed to a subcombination or variation of a subcombination.

Similarly, while operations are depicted in the drawings in a particular order, this should not be understood as requiring that such operations be performed in the particular order shown or in sequential order, or that all illustrated operations be performed, to achieve desirable results. In some cases, multitasking and parallel processing may be advantageous. Moreover, the separation of various system modules and components in the embodiments described above should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve desirable results. Further, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some implementations, multitasking and parallel processing may be advantageous.

The above description is only exemplary of the present application and should not be taken as limiting the present application, as any modification, equivalent replacement, or improvement made within the spirit and principle of the present application should be included in the scope of protection of the present application.

Claims

1. A method for multiplexing Transport Layer Security (TLS) connection, applied to a client, is characterized in that the method comprises:

2. The method of claim 1,

the HTTP request message and the first negotiation information carried by the data request message are encrypted by a first key and an encryption and decryption algorithm extracted from the TLS session information;

3. The method of claim 2,

the request message also carries a request abstract; the request abstract is obtained by carrying out abstract calculation on the HTTP request message through a second key and an abstract algorithm extracted from the TLS session information; the request abstract is used for triggering the server side to respond to the decrypted HTTP request message to generate the HTTP response message after the request abstract passes the verification.

4. The method of claim 3,

extracting the first key and the second key from the TLS session information by the following method:

extracting a master key from the TLS session information;

5. A method for multiplexing TLS connection is applied to a server side, and is characterized in that the method comprises the following steps:

receiving a data request message sent by the client through TCP connection;

extracting a TLS session bill, first negotiation information which is generated by the client and used for generating a TLS communication key and an HTTP request message from the data request message;

responding the HTTP request to generate an HTTP response message;

6. The method of claim 5,

7. The method of claim 6,

the data request message also carries a request abstract obtained by carrying out abstract calculation on the HTTP request through an abstract key and an abstract algorithm extracted from the TLS session information;

the responding the HTTP request to generate an HTTP response message includes:

8. The method according to claim 6, wherein the constructing and returning a data response packet indicating successful multiplexing to the client based on the second negotiation information and the HTTP response packet comprises:

encrypting the HTTP response message by adopting the TLS communication key;

9. An apparatus for multiplexing TLS connections, the apparatus being applied to a client and comprising:

10. An apparatus for multiplexing TLS connection, the apparatus being applied to a server and comprising: