A TLS-based session ticket HTTPS session protection method

Abstract

The application relates to a TLS-based Session Ticket HTTPS session protection method, in which a user initiates an identity authentication request, a server generates a random string as additional authentication data, the random string is added to a Session Ticket and is encrypted and sent to a client, the user initiates a request again thereafter, information carried in the Session Ticket returned by the client is directly verified, and if the Session Ticket sent by the client is consistent with Session Ticket information saved by the server, the session can be safely and successfully recovered. The application aims to solve the problem that a Session in a session process can be easily acquired in the related art, the Session is encrypted by the server, the Session cannot be decrypted and tampered, and therefore the security of the session is improved.

Description

Technical Field

[0001] This invention relates to the field of Internet security technology, and in particular to a TLS-based Session Ticket HTTPS session protection method. Background Technology

[0002] With the development of internet technology, HTTPS has become the protocol used by many web applications to interact with servers. HTTPS adds the SSL / TLS protocol to the HTTP protocol, providing strong confidentiality and ensuring data integrity during transmission. Furthermore, for web applications, ensuring security requires not easily trusting data submitted by clients; login authentication is mandatory for secure communication.

[0003] However, due to the stateless nature of the HTTP protocol, once data exchange is complete, the connection between the client and server is closed, and a new connection needs to be established for subsequent data exchange. This means that the server cannot track the session from the connection. To address this issue, commonly used session tracking technologies are cookies and sessions. Cookies identify users by recording information on the client side, while sessions identify users by recording information on the server side. However, since cookie and session information can be easily read by scripts such as JavaScript, user session information is at risk of being stolen. Therefore, it is necessary to propose a method to improve session information security. Summary of the Invention

[0004] In view of the above problems, the purpose of this invention is to enhance the security of user sessions based on the Session Ticket in the TLS protocol, solve the problem of information being easily obtained and tampered with during the session, and further improve session security.

[0005] The technical solution adopted by the system of the present invention is as follows:

[0006] A TLS-based Session Ticket HTTPS session protection method, characterized by the following steps:

[0007] Step 1: The client submits login information to the server via HTTPS;

[0008] Step 2: After logging in, the client accesses the authorized resources.

[0009] Preferably, step 1 specifically includes the following steps:

[0010] Step 1.1: The client sends a TLS handshake request to the HTTPS server until the client completes the handshake (Client Finshed) process;

[0011] Step 1.2: After receiving the Client Finshed data packet from the client, the HTTPS server generates a random string RStr as a parameter in the Session Ticket and encrypts the Session Ticket;

[0012] Step 1.3: The HTTPS server sends the encrypted Session Ticket to the client;

[0013] Step 1.4: The client protocol layer receives the encrypted Session Ticket data sent by the HTTPS server and saves it locally on the client. At this point, the client and the HTTPS server have completed the TLS handshake.

[0014] Step 1.5: The client sends an HTTP authentication request to the HTTPS server, using TLS encryption;

[0015] Step 1.6: After receiving the authentication request from the client, the HTTPS server performs TLS decryption and inserts a custom header CHead into the HTTP request header;

[0016] Step 1.7: After processing in Step 1.6, the application server begins to authenticate the user information, and then uses CHead as the session ID or as session-attached authentication data. If the authentication is successful, the client user's identity is successfully confirmed and the application server returns a success message. If the authentication fails, the application server returns a failure message and returns to Step 1.1.

[0017] Step 1.8: The client sends an HTTP response.

[0018] Preferably, in step 1.2, the random string RStr is used as a parameter value in the Session Ticket, and the random string RStr must meet the requirement of uniqueness.

[0019] Preferably, in step 1.6, the custom header refers to a non-HTTP standard header, and the value of the inserted custom header CHead is the random string RStr generated in step 1.2. Therefore, the random string RStr must meet the parameter format of the custom header, which is [name: value].

[0020] Preferably, in step 1.7, after successful authentication, the application server saves CHead as a subsequent authentication item.

[0021] Preferably, step 2 specifically includes the following steps:

[0022] Step 2.1: The client performs a TLS handshake with the HTTPS server, carrying the ciphertext of the Session Ticket;

[0023] Step 2.2: The HTTPS server decrypts the ciphertext of the Session Ticket sent by the client, completes the session recovery, and obtains the custom header CHead2 from the decrypted Session Ticket. At this point, the client and the HTTPS server have completed the TLS handshake.

[0024] Step 2.3: The client sends an HTTP request to the HTTPS server, using TLS encryption;

[0025] Step 2.4: The HTTPS server performs TLS decryption and adds a custom header CHEad2 to the HTTP request header;

[0026] Step 2.5: After the processing in Step 2.4, the application server uses this custom header CHead2 for session verification and compares the custom header CHead2 information with the custom header CHead information saved in the application server database after successful user authentication.

[0027] Preferably, in step 2.1, the Session Ticket ciphertext is saved in step 1.4.

[0028] Preferably, step 2.5 further includes the following steps: if the application server database contains identical information for CHead2 and CHead, the verification is successful, the application server returns the corresponding information, and the client sends an HTTP response; otherwise, the verification fails, and authentication needs to be performed again, returning to step 1.1.

[0029] This invention provides a TLS-based Session Ticket HTTPS session protection method. The user initiates an authentication request from the client, and the server generates a random string as additional verification data. This random string is added to the Session Ticket, encrypted, and sent to the client. Subsequently, each time the user initiates a request, it directly verifies the information carried in the Session Ticket returned by the client. If the Session Ticket sent by the client matches the Session Ticket information stored on the server, the session can be securely and successfully restored. This invention improves session security by adding a new parameter—a random string—to the Session Ticket structure. Because the Session Ticket resides at the protocol level and is encrypted by the server before being returned to the client, client-side scripts such as JavaScript cannot read, decrypt, or tamper with the Session Ticket. Attached Figure Description

[0030] The specific embodiments of the present invention will be further described below with reference to the accompanying drawings:

[0031] Figure 1 This is a framework diagram of a TLS-based Session Ticket HTTPS session protection method provided in an embodiment of the present invention;

[0032] Figure 2 This is a schematic diagram of the first part of a TLS-based Session Ticket HTTPS session protection method provided in an embodiment of the present invention;

[0033] Figure 3 This is a schematic diagram of the second part of a TLS-based Session Ticket HTTPS session protection method provided in an embodiment of the present invention. Detailed Implementation

[0034] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0035] like Figure 1 As shown, a TLS-based Session Ticket HTTPS session protection method includes the following two main steps:

[0036] Step 1: The client submits login information to the server via HTTPS;

[0037] like Figure 2 As shown, the specific steps include:

[0038] Step 1.1: The client sends a TLS handshake request to the HTTPS server until the client completes the handshake (Client Finshed) process;

[0039] Step 1.2: After receiving the Client Finshed data packet from the client, the HTTPS server generates a random string RStr as a parameter in the Session Ticket and encrypts the Session Ticket;

[0040] Step 1.3: The HTTPS server sends the encrypted Session Ticket to the client;

[0041] Step 1.4: The client protocol layer receives the encrypted Session Ticket data sent by the HTTPS server and saves it locally on the client. At this point, the client and the HTTPS server have completed the TLS handshake.

[0042] Step 1.5: The client sends an HTTP authentication request to the HTTPS server, using TLS encryption;

[0043] Step 1.6: After receiving the authentication request from the client, the HTTPS server performs TLS decryption and inserts a custom header CHead into the HTTP request header;

[0044] Step 1.7: After processing in Step 1.6, the application server begins to authenticate the user information, and then uses CHead as the session ID or as session-attached authentication data. If the authentication is successful, the client user's identity is successfully confirmed and the application server returns a success message. If the authentication fails, the application server returns a failure message and returns to Step 1.1.

[0045] Step 1.8: The client sends an HTTP response.

[0046] In step 1.2, the random string RStr is used as a parameter value in the Session Ticket, and the random string RStr must meet the requirement of uniqueness.

[0047] In step 1.6, the custom header refers to a non-HTTP standard header. The value of the inserted custom header CHead is the random string RStr generated in step 1.2. Therefore, the random string RStr must meet the parameter format of the custom header, which is

name: value

[0048] In step 1.7, after successful authentication, the application server automatically saves CHead as a subsequent authentication item.

[0049] Step 2: After logging in, the client accesses the authorized resources.

[0050] like Figure 3 As shown, the specific steps include:

[0051] Step 2.1: The client performs a TLS handshake with the HTTPS server, carrying the ciphertext of the Session Ticket;

[0052] Step 2.2: The HTTPS server decrypts the ciphertext of the Session Ticket sent by the client, completes the session recovery, and obtains the custom header CHead2 from the decrypted Session Ticket. At this point, the client and the HTTPS server have completed the TLS handshake.

[0053] Step 2.3: The client sends an HTTP request to the HTTPS server, using TLS encryption;

[0054] Step 2.4: The HTTPS server performs TLS decryption and adds a custom header CHEad2 to the HTTP request header;

[0055] Step 2.5: After the processing in Step 2.4, the application server uses this custom header CHead2 for session verification and compares the custom header CHead2 information with the custom header CHead information saved in the application server database after successful user authentication.

[0056] In step 2.1, the Session Ticket ciphertext is saved in step 1.4.

[0057] Step 2.5 further includes the following steps: if the application server database contains the same information as CHead2 and CHead, the verification is successful, the application server returns the corresponding information, and the client sends an HTTP response; otherwise, the verification fails, and the client needs to re-authenticate and return to step 1.1.

[0058] This invention provides a TLS-based Session Ticket HTTPS session protection method. The user initiates an authentication request from the client, and the server generates a random string as additional verification data. This random string is added to the Session Ticket, encrypted, and sent to the client. Subsequently, each time the user initiates a request, it directly verifies the information carried in the Session Ticket returned by the client. If the Session Ticket sent by the client matches the Session Ticket information stored on the server, the session can be securely and successfully restored. This invention improves session security by adding a new parameter—a random string—to the Session Ticket structure. Because the Session Ticket resides at the protocol level and is encrypted by the server before being returned to the client, client-side scripts such as JavaScript cannot read, decrypt, or tamper with the Session Ticket.

[0059] The above are merely specific embodiments of the present invention, and should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these all fall within the protection scope of the present invention.

Claims

1. A TLS-based Session Ticket HTTPS session protection method, characterized in that, The method comprises the following steps: Step 1: the client submits login information to the server through HTTPS; The step 1 specifically comprises the following steps: Step 1.1: the client sends a TLS handshake request to the HTTPS server until the client completes the handshake behavior; Step 1.2: after the HTTPS server receives the Client Finished data packet of the client, a random string RStr is generated as a parameter in the Session Ticket, and the Session Ticket is encrypted; wherein the random string RStr satisfies the parameter format of the custom header; Step 1.3: the HTTPS server sends the encrypted Session Ticket ciphertext to the client; Step 1.4: the client protocol layer receives the Session Ticket ciphertext data sent by the HTTPS server and saves it in the local client, thus the client and the HTTPS server complete the TLS handshake; Step 1.5: the client initiates an HTTP identity authentication request to the HTTPS server and uses TLS encryption; Step 1.6: after the HTTPS server receives the identity authentication request sent by the client, the custom header CHead is inserted in the HTTP request header after TLS decryption; wherein the custom header refers to a non-HTTP standard header, and the value of the inserted custom header CHead is the random string RStr generated in step 1.2; Step 1.7: after the processing of step 1.6, the application server starts to authenticate the user information, then uses CHead as a session ID or as session additional verification data, if the identity authentication is passed, the identity of the client user is successfully confirmed, the application server returns a successful prompt, if the authentication is not passed, the application server returns a failure prompt, and returns to step 1.1; Step 1.8: the client performs HTTP response; Step 2: the client accesses the authorized resource after completing login; The step 2 specifically comprises the following steps: Step 2.1: the client and the HTTPS server perform TLS handshake and carry the Session Ticket ciphertext; Step 2.2: the HTTPS server decrypts the Session Ticket ciphertext sent by the client to complete session recovery, and obtains the custom header CHead2 from the decrypted Session Ticket, thus the client and the HTTPS server complete the TLS handshake; Step 2.3: the client initiates an HTTP request to the HTTPS server and uses TLS encryption; Step 2.4: the HTTPS server performs TLS decryption and adds the custom header CHead2 in the HTTP request header; Step 2.5: after the processing of step 2.4, the application server uses the custom header CHead2 for session verification, compares the custom header CHead2 information with the custom header CHead information saved in the database of the application server after successful user identity verification; The user initiates a request each time to directly verify the information carried in the Session Ticket returned by the client; if the Session Ticket sent by the client is consistent with the Session Ticket information saved by the server, the session can be safely and successfully recovered.

2. The TLS-based Session Ticket HTTPS session protection method according to claim 1, characterized in that, In step 1.2, the following steps are included: The random string RStr is a parameter value in the Session Ticket, and the random string RStr must meet the requirement of uniqueness.

3. The TLS-based Session Ticket HTTPS session protection method of claim 1, wherein, The parameter format is [name:value].

4. The TLS-based Session Ticket HTTPS session protection method of claim 1, wherein, In step 1.7, the following steps are included: After successful authentication, the application server saves the CHead as a subsequent verification item.

5. The TLS-based Session Ticket HTTPS session protection method of claim 1, wherein, In step 2.1, the following steps are included: The Session Ticket ciphertext is saved through step 1.

4.

6. The TLS-based Session Ticket HTTPS session protection method of claim 1, wherein, In step 2.5, the following steps are included: If the CHead2 in the application server database is the same as the CHead information, the verification is successful, the application server returns the corresponding information, and the client performs an HTTP response; otherwise, the verification fails, and the identity authentication needs to be performed again, returning to step 1.1.

Images