SSL negotiation method, device, equipment and computer-readable storage medium

Abstract

The present application provides an SSL negotiation method, apparatus, device and computer-readable storage medium, the method comprising: receiving a server handshake message sent by a server; wherein the server handshake message includes a first algorithm suite field, and the value in the first algorithm suite field is used to represent the SSL encryption algorithm determined by the server; using a first preset encryption algorithm to encrypt the first algorithm suite field in the server handshake message to obtain an encrypted server handshake message; sending the encrypted server handshake message to a second proxy server, so that the second proxy server uses a decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field, determine the server handshake message, and send the server handshake message to the client. Through the above method, the probability of leakage of the SSL encryption algorithm is reduced, and the security of encrypted transmission using the SSL protocol is improved.

Description

Technical Field

[0001] The present application relates to the field of network security, and in particular to an SSL negotiation method, apparatus, device and computer-readable storage medium. Background Art

[0002] With the continuous development of communication technology, in order to improve communication security, the communication method has evolved from the initial plain text transmission, to ordinary encrypted transmission, to the current use of the Secure Sockets Layer (SSL) protocol for encrypted transmission, and the encryption method has been further strengthened.

[0003] Before using the SSL protocol for encrypted transmission, the client and the server perform SSL negotiation by sending handshake messages to determine the SSL encryption algorithm used for encrypted transmission. However, in the prior art, when the client and the server perform SSL negotiation, the SSL encryption algorithm is reflected in the handshake message sent in plain text, which makes the SSL encryption algorithm easy to leak, and then the encrypted information is cracked when the SSL encryption algorithm is used for encrypted transmission. Summary of the invention

[0004] The purpose of the embodiments of the present application is to provide an SSL negotiation method, apparatus, device and computer-readable storage medium to reduce the probability of leakage of the SSL encryption algorithm and improve the security of encrypted transmission using the SSL protocol.

[0005] In a first aspect, the present application provides an SSL negotiation method, which is applied to a first proxy server connected to a server, the method comprising: receiving a server handshake message sent by the server; wherein the server handshake message includes a first algorithm suite field, and the value in the first algorithm suite field is used to represent the SSL encryption algorithm determined by the server; using a first preset encryption algorithm to encrypt the first algorithm suite field in the server handshake message to obtain an encrypted server handshake message; sending the encrypted server handshake message to a second proxy server, so that the second proxy server uses a decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field, determine the server handshake message, and send the server handshake message to a client.

[0006] In the above implementation process, when the client and the server perform SSL negotiation, the first proxy server connected to the server uses a preset encryption algorithm to encrypt the first algorithm suite field in the server handshake message, and sends the encrypted server handshake message to the second proxy server. The second proxy server uses the decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field to obtain the server handshake message, and sends the server handshake message to the client. In the above manner, the first algorithm suite field in the server handshake message is encrypted, and the SSL encryption algorithm originally displayed in plain text is converted into ciphertext, which reduces the probability of leakage of the SSL encryption algorithm during the transmission process and improves the security of encrypted transmission using the SSL protocol.

[0007] In an optional implementation, before using the first preset encryption algorithm to encrypt the first algorithm suite field in the server handshake message, the method further includes: obtaining identification information of the server handshake message; and determining, based on the identification information, that the first algorithm suite field in the server handshake message needs to be encrypted.

[0008] In the above implementation process, before using the first preset encryption algorithm to encrypt the first algorithm suite field in the server handshake message, it is determined in the above manner that the first algorithm suite field in the server handshake message needs to be encrypted, thereby avoiding encrypting the server handshake message that does not use the SSL negotiation method provided in the embodiment of the present application for SSL negotiation, thereby improving applicability.

[0009] In an optional implementation, the obtaining of identification information of the server handshake message includes: parsing the server handshake message to determine a source port and a destination port of the server handshake message; correspondingly, determining, based on the identification information, whether a first algorithm suite field in the server handshake message needs to be encrypted includes: determining whether a source port of the server handshake message matches a source port in a port information table pre-configured in the first proxy server, and determining whether a destination port of the server handshake message matches a destination port in a port information table pre-configured in the first proxy server; if both match, determining that the first algorithm suite field in the server handshake message needs to be encrypted.

[0010] In the above implementation process, by judging whether the source port and destination port in the server handshake message match the information in the port information table pre-configured in the first proxy server, it is determined that the first algorithm suite field in the server handshake message needs to be encrypted. The implementation method is simple, time-saving, and processing efficiency is improved.

[0011] In an optional embodiment, before receiving the server handshake message sent by the server, the method also includes: receiving an encrypted client handshake message sent by the second proxy server; wherein the encrypted client handshake message includes a second algorithm suite field encrypted by the second proxy server using a second preset encryption algorithm, and the value in the second algorithm suite field is used to represent the SSL encryption algorithm supported by the client; using a decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field to obtain the client handshake message; and sending the client handshake message to the server.

[0012] In the above implementation process, when the client and the server perform SSL negotiation, the second proxy server connected to the client uses a preset encryption algorithm to encrypt the second algorithm suite field in the client handshake message, and sends the encrypted client handshake message to the first proxy server. The first proxy server uses a decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field to obtain the client handshake message, and sends the client handshake message to the server. In the above manner, the second algorithm suite field in the client handshake message is encrypted, and the SSL encryption algorithm supported by the client, which was originally displayed in plain text, is converted into ciphertext, which reduces the probability of leakage of the SSL encryption algorithm supported by the client during the transmission process, and further improves the security of encrypted transmission using the SSL protocol.

[0013] In a second aspect, the present application provides an SSL negotiation method, which is applied to a second proxy server connected to a client, the method comprising: receiving an encrypted server handshake message sent by a first proxy server; wherein the encrypted server handshake message comprises a first algorithm suite field encrypted by the first proxy server using a first preset encryption algorithm, and the value in the first algorithm suite field is used to represent the SSL encryption algorithm determined by the server; decrypting the first algorithm suite field using a decryption algorithm corresponding to the first preset encryption algorithm to obtain the server handshake message; and sending the server handshake message to the client.

[0014] In an optional embodiment, before receiving the encrypted server handshake message sent by the first proxy server, the method further includes: receiving a client handshake message sent by the client; wherein the client handshake message includes a second algorithm suite field, and the value in the second algorithm suite field is used to represent the SSL encryption algorithm supported by the client; using a second preset encryption algorithm to encrypt the second algorithm suite field in the client handshake message to obtain an encrypted client handshake message; sending the encrypted client handshake message to the first proxy server, so that the first proxy server uses a decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field, determine the client handshake message, and send the client handshake message to the server.

[0015] In an optional implementation, before using the second preset encryption algorithm to encrypt the second algorithm suite field in the client handshake message, the method further includes: obtaining identification information of the client handshake message; and determining, based on the identification information, that the second algorithm suite field in the client handshake message needs to be encrypted.

[0016] In an optional implementation, the obtaining of identification information of the client handshake message includes: parsing the client handshake message to determine the source port and destination port of the encrypted client handshake message; correspondingly, determining that the second algorithm suite field in the client handshake message needs to be decrypted based on the identification information includes: determining whether the source port of the client handshake message matches the source port in a port information table pre-configured in the first proxy server, and determining whether the destination port of the client handshake message matches the destination port in the port information table pre-configured in the first proxy server; if both match, determining that the second algorithm suite field in the client handshake message needs to be encrypted.

[0017] In a third aspect, the present application provides an SSL negotiation device, which is configured on a first proxy server connected to a server, and the device includes: a receiving module, used to receive a server handshake message sent by the server; wherein the server handshake message includes a first algorithm suite field, and the value in the first algorithm suite field is used to represent the SSL encryption algorithm determined by the server; an encryption module, used to use a first preset encryption algorithm to encrypt the first algorithm suite field in the server handshake message to obtain an encrypted server handshake message; a sending module, used to send the encrypted server handshake message to a second proxy server, so that the second proxy server uses a decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field, determine the server handshake message, and send the server handshake message to a client.

[0018] In an optional implementation, the device further includes: an encryption determination module, configured to obtain identification information of the server handshake message; and determine, based on the identification information, that the first algorithm suite field in the server handshake message needs to be encrypted.

[0019] In an optional implementation, the encryption determination module is specifically used to parse the server handshake message to determine the source port and destination port of the server handshake message; determine whether the source port of the server handshake message matches the source port in the port information table pre-configured in the first proxy server, and determine whether the destination port of the server handshake message matches the destination port in the port information table pre-configured in the first proxy server; if both match, determine that the first algorithm suite field in the server handshake message needs to be encrypted.

[0020] In an optional embodiment, the receiving module is also used to receive an encrypted client handshake message sent by the second proxy server; wherein the encrypted client handshake message includes a second algorithm suite field encrypted by the second proxy server using a second preset encryption algorithm, and the value in the second algorithm suite field is used to characterize the SSL encryption algorithm supported by the client; the device also includes: a decryption module, used to decrypt the second algorithm suite field using a decryption algorithm corresponding to the second preset encryption algorithm to obtain the client handshake message; the sending module is also used to send the client handshake message to the server.

[0021] In a fourth aspect, the present application provides an SSL negotiation device, which is configured on a second proxy server connected to a client, and the device includes: a receiving module, used to receive an encrypted server handshake message sent by a first proxy server; wherein the encrypted server handshake message includes a first algorithm suite field encrypted by the first proxy server using a first preset encryption algorithm, and the value in the first algorithm suite field is used to represent the SSL encryption algorithm determined by the server; a decryption module, used to decrypt the first algorithm suite field using a decryption algorithm corresponding to the first preset encryption algorithm to obtain the server handshake message; and a sending module, used to send the server handshake message to the client.

[0022] In an optional embodiment, the receiving module is also used to receive a client handshake message sent by the client; wherein the client handshake message includes a second algorithm suite field, and the value in the second algorithm suite field is used to characterize the SSL encryption algorithm supported by the client; the device also includes: an encryption module, which uses a second preset encryption algorithm to encrypt the second algorithm suite field in the client handshake message to obtain an encrypted client handshake message; the sending module is also used to send the encrypted client handshake message to the first proxy server, so that the first proxy server uses a decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field, determine the client handshake message, and send the client handshake message to the server.

[0023] In an optional implementation, the device further includes: an encryption determination module, configured to obtain identification information of the client handshake message; and determine, based on the identification information, that the second algorithm suite field in the client handshake message needs to be encrypted.

[0024] In an optional implementation, the encryption determination module is specifically used to parse the client handshake message, determine the source port and destination port of the encrypted client handshake message; determine whether the source port of the client handshake message matches the source port in the port information table pre-configured in the first proxy server, and determine whether the destination port of the client handshake message matches the destination port in the port information table pre-configured in the first proxy server; if both match, determine that the second algorithm suite field in the client handshake message needs to be encrypted.

[0025] In a fifth aspect, the present application provides an electronic device, comprising: a processor, a memory and a bus; the processor and the memory communicate with each other through the bus; the memory stores program instructions that can be executed by the processor, and the processor calls the program instructions to execute a method as described in any of the foregoing embodiments.

[0026] In a sixth aspect, the present application provides a computer-readable storage medium having computer program instructions stored thereon. When the computer program instructions are read and executed by a computer, the method as described in any one of the aforementioned embodiments is executed. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings required for use in the embodiments of the present application will be briefly introduced below. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other related drawings can be obtained based on these drawings without paying creative work.

[0028] Figure 1 A structural block diagram of a communication system provided in an embodiment of the present application;

[0029] Figure 2 A flowchart of an SSL negotiation method provided in an embodiment of the present application;

[0030] Figure 3 A structural block diagram of an SSL negotiation device provided in an embodiment of the present application;

[0031] Figure 4 A structural block diagram of an SSL negotiation device provided in an embodiment of the present application;

[0032] Figure 5 A schematic diagram of the structure of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0033] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0034] See also Figure 1 , Figure 1 The communication system 100 may include: a server 101, a first proxy server 102, a second proxy server 103, and a client 104. The server 101 is connected to the first proxy server 102, and the client 104 is connected to the second proxy server 103.

[0035] It can be understood that in the embodiment of the present application, the second proxy server 103 implements the forward proxy between the client 104 and the server 101, and the first proxy server 102 implements the reverse proxy between the client 104 and the server 101.

[0036] When the client 104 and the server 101 perform message exchange, all messages will be forwarded by the first proxy server 102 and the second proxy server 103 .

[0037] See also Figure 2 , Figure 2 A flowchart of an SSL negotiation method provided in an embodiment of the present application, the SSL negotiation method is applied to Figure 1 In the system, the SSL negotiation method may include:

[0038] Step S201: The first proxy server receives a server handshake message sent by a server.

[0039] Step S202: The first proxy server uses a first preset encryption algorithm to encrypt a first algorithm suite field in the server handshake message to obtain an encrypted server handshake message.

[0040] Step S203: the first proxy server sends the encrypted server handshake message to the second proxy server.

[0041] Step S204: the second proxy server receives the encrypted server handshake message sent by the first proxy server.

[0042] Step S205: The second proxy server uses the decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field to obtain a server handshake message.

[0043] Step S206: The second proxy server sends the server handshake message to the client.

[0044] The above method is introduced in detail below.

[0045] Step S201: The first proxy server receives a server handshake message sent by a server.

[0046] In the embodiment of the present application, when the client and the server perform SSL negotiation, the server determines the SSL encryption algorithm to be used in the subsequent SSL encrypted transmission from the multiple encryption algorithms supported by the client sent by the client according to the encryption algorithms supported by itself. The server generates a server handshake message (Server Hello message), and the server handshake message includes a first algorithm suite field, and the value in the first algorithm suite field is the SSL encryption algorithm determined by the server.

[0047] Step S202: The first proxy server uses a first preset encryption algorithm to encrypt a first algorithm suite field in the server handshake message to obtain an encrypted server handshake message.

[0048] In an embodiment of the present application, during the process of transmitting a server handshake message, in order to prevent a network device or a network attacker from obtaining the server-determined SSL encryption algorithm in the first algorithm suite field in the server handshake message by capturing packets, thereby causing the leakage of the server-determined SSL encryption algorithm, a first preset encryption algorithm is preset in the first proxy server.

[0049] After receiving the handshake message from the server, the first proxy server parses the handshake message from the server, determines the content of the Cipher Suiters field (i.e., the first algorithm suite field) in the Transport Layer Security content in the handshake message from the server (i.e., determines the SSL encryption algorithm determined by the server). The first preset encryption algorithm is used to encrypt the content in the Cipher Suiters field (i.e., the SSL encryption algorithm determined by the server is encrypted), and an encrypted handshake message from the server is generated.

[0050] For example, the content of the Cipher Suiters field of the server handshake message may be: "TLS_DH_ANON_WITH_AES_256_GCM_SHA384".

[0051] In some implementations, the first preset encryption algorithm may be a random order method. The specific implementation process of the random order method is: determine a number of fields in the first algorithm suite field, rearrange the determined fields in a certain order, and complete encryption. For example, the first field, the third field, and the fifth field in the first algorithm suite field are rearranged in the order of the fifth field, the third field, and the first field.

[0052] In other implementations, the first preset encryption algorithm may be a replacement method, and the specific implementation process of the replacement method is: pre-configure a target string, select a field in the first algorithm suite field, replace the content of the field with the target string, and complete encryption.

[0053] It should be noted that the first preset encryption algorithm can also be other encryption algorithms, such as a hash algorithm, a symmetric encryption algorithm, an asymmetric encryption algorithm, etc. The first preset encryption algorithm of this application is not specifically limited.

[0054] Furthermore, before the above step S202, the SSL negotiation method provided in the embodiment of the present application also includes steps A1 and A2.

[0055] A1: Get the identification information of the server handshake message;

[0056] A2: Determine, based on the identification information, that the first algorithm suite field in the handshake message of the server needs to be encrypted.

[0057] In the embodiment of the present application, it is taken into account that in the actual application process, some services use the SSL negotiation method provided by the embodiment of the present application for SSL negotiation, and some services do not use the SSL negotiation method provided by the embodiment of the present application for SSL negotiation. For services that do not use the SSL negotiation method provided by the embodiment of the present application for SSL negotiation, the first algorithm suite field in the server handshake message sent by these services cannot be encrypted, otherwise it will affect the normal processing of these services. Therefore, before executing step S202, the above steps A1 and A2 are used to determine whether it is necessary to encrypt the first algorithm suite field in the server handshake message sent by the received server. When it is determined that the first algorithm suite field in the server handshake message needs to be encrypted, step S202 is executed.

[0058] As an optional implementation, step A1 may be implemented by the following steps:

[0059] A11: The first proxy server parses the server handshake message and determines the source port and destination port of the server handshake message.

[0060] Correspondingly, step A2 can be implemented by the following steps:

[0061] A21: The first proxy server determines whether a source port of the server handshake message matches a source port in a port information table pre-configured in the first proxy server, and determines whether a destination port of the server handshake message matches a destination port in a port information table pre-configured in the first proxy server;

[0062] A22: If both match, it is determined that the first algorithm suite field in the handshake message of the server needs to be encrypted.

[0063] In the embodiment of the present application, the identification information of the server handshake message is the source port and destination port corresponding to the server handshake message. The port information table pre-configured in the first proxy server includes a source port and a destination port. If the source port of a server handshake message matches the source port in the port information table, and the destination port of the server handshake message matches the destination port in the port information table, it means that the service corresponding to the server handshake message adopts the SSL negotiation method provided in the embodiment of the present application for SSL negotiation. Therefore, the first proxy server needs to encrypt the first algorithm suite field in the server handshake message.

[0064] As another optional implementation, an identification field may be provided in the server handshake message. If the value of the identification field is a first preset value, it indicates that the service corresponding to the server handshake message adopts the SSL negotiation method provided in the embodiment of the present application to perform SSL negotiation, and determines that the first proxy server needs to encrypt the first algorithm suite field in the server handshake message.

[0065] Step S203: the first proxy server sends the encrypted server handshake message to the second proxy server.

[0066] Step S204: the second proxy server receives the encrypted server handshake message sent by the first proxy server.

[0067] In the embodiment of the present application, the first proxy server encrypts the server handshake message and sends the encrypted server handshake message to the second proxy server, and the second proxy server receives the encrypted server handshake message sent by the first proxy server.

[0068] Step S205: The second proxy server uses the decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field to obtain a server handshake message.

[0069] In the embodiment of the present application, the second proxy server is connected to the client, and when the encrypted server handshake message arrives at the second proxy server, it indicates that the next hop node of the encrypted server handshake message is the client. Since the content in the first algorithm suite field in the encrypted server handshake message is encrypted by the first proxy server using the first preset encryption algorithm, in order to enable the client to determine the SSL encryption algorithm sent by the server, the second proxy server is preset with a decryption algorithm corresponding to the first preset encryption algorithm.

[0070] After receiving the encrypted server handshake message, the second proxy server parses the server handshake message to determine the content of the Cipher Suiters field (i.e., the first algorithm suite field) in the Transport Layer Security content in the encrypted server handshake message (i.e., the encrypted SSL encryption algorithm). The decryption algorithm corresponding to the first preset encryption algorithm is used to decrypt the content in the Cipher Suiters field (i.e., restore the encrypted SSL encryption algorithm to the SSL encryption algorithm determined by the server), and restore the server handshake message.

[0071] Furthermore, considering that in the actual application process, some services use the SSL negotiation method provided in the embodiment of the present application for SSL negotiation, and some services do not use the SSL negotiation method provided in the embodiment of the present application for SSL negotiation. For services that do not use the SSL negotiation method provided in the embodiment of the present application for SSL negotiation, the second proxy server does not need to decrypt the first algorithm suite field in the server handshake message sent by these services, otherwise it will affect the normal processing of these services. Therefore, the SSL negotiation method provided in the embodiment of the present application also includes steps B1 and B2.

[0072] B1: The second proxy device obtains identification information of the handshake message from the server;

[0073] B2: The second proxy device determines, according to the identification information, that the first algorithm suite field in the handshake message of the server needs to be decrypted.

[0074] As an optional implementation, step B1 may be implemented by the following steps:

[0075] B11: The second proxy device parses the server handshake message and determines the source port and destination port of the server handshake message.

[0076] Correspondingly, step B2 can be implemented by the following steps:

[0077] B21: The second proxy device determines whether the source port of the server handshake message matches the source port in the port information table preconfigured in the second proxy server, and determines whether the destination port of the server handshake message matches the destination port in the port information table preconfigured in the second proxy server.

[0078] B22: If both match, it is determined that the first algorithm suite field in the handshake message of the server needs to be decrypted.

[0079] In the embodiment of the present application, the identification information of the server handshake message is the source port and destination port corresponding to the server handshake message. The port information table pre-configured in the second proxy server includes a source port and a destination port. If the source port of a server handshake message matches the source port in the port information table, and the destination port of the server handshake message matches the destination port in the port information table, it means that the service corresponding to the server handshake message adopts the SSL negotiation method provided in the embodiment of the present application for SSL negotiation. Therefore, after the second proxy server receives the server handshake message, it determines that the first algorithm suite field in the server handshake message needs to be decrypted.

[0080] As another optional implementation, an identification field may be provided in the server handshake message. If the value of the identification field is a first preset value, it indicates that the service corresponding to the server handshake message adopts the SSL negotiation method provided in the embodiment of the present application for SSL negotiation. After the second proxy server receives the server handshake message, it determines that the second proxy server needs to decrypt the first algorithm suite field in the server handshake message.

[0081] Step S206: The second proxy server sends the server handshake message to the client.

[0082] In an embodiment of the present application, the second proxy server uses a decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field, and after obtaining the server handshake message, sends the server handshake message to the client, so that the client can determine the SSL encryption algorithm selected by the server based on the first algorithm suite field in the server handshake message, so as to perform encrypted transmission according to the SSL encryption algorithm subsequently.

[0083] Furthermore, before the above step S201, the SSL negotiation method provided in the embodiment of the present application may further include:

[0084] Step S301: the second proxy server receives a client handshake message sent by a client.

[0085] Step S302: The second proxy server uses a second preset encryption algorithm to encrypt the second algorithm suite field in the client handshake message to obtain an encrypted client handshake message.

[0086] Step S303: the second proxy server sends the encrypted client handshake message to the first proxy server.

[0087] Step S304: the first proxy server receives the encrypted client handshake message sent by the second proxy server.

[0088] Step S305: The first proxy server uses the decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field to obtain a client handshake message.

[0089] Step S306: The first proxy server sends the client handshake message to the server.

[0090] The above method is introduced in detail below.

[0091] Step S301: the second proxy server receives a client handshake message sent by a client.

[0092] In an embodiment of the present application, when the client and the server perform SSL negotiation, the client generates a client handshake message (Client Hello message) based on the encryption algorithm supported by itself. The client handshake message includes a second algorithm suite field. The value in the second algorithm suite field is the SSL encryption algorithm supported by the client.

[0093] Step S302: The second proxy server uses a second preset encryption algorithm to encrypt the second algorithm suite field in the client handshake message to obtain an encrypted client handshake message.

[0094] In an embodiment of the present application, during the process of transmitting the client handshake message, in order to prevent the network device or network attacker from obtaining the SSL encryption algorithm supported by the client in the second algorithm suite field in the client handshake message by capturing packets, thereby causing the leakage of the SSL encryption algorithm supported by the client, a second preset encryption algorithm is preset in the second proxy server.

[0095] After receiving the client handshake message, the second proxy server parses the client handshake message, determines the content of the Cipher Suiters field (i.e., the second algorithm suite field) in the Transport Layer Security content in the client handshake message (i.e., determines the SSL encryption algorithm supported by the client). The second preset encryption algorithm is used to encrypt the content in the Cipher Suiters field (i.e., the SSL encryption algorithm supported by the client is encrypted), and an encrypted client handshake message is generated.

[0096] For example, assuming that the client supports three SSL encryption algorithms, the content of the CipherSuiters field of the client handshake message can be: "TLS_DH_ANON_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256".

[0097] It can be understood that the second preset encryption algorithm is similar to the first preset encryption algorithm. To make the specification concise, the same or similar parts can be referenced to each other and will not be repeated here.

[0098] It should be noted that the second preset encryption algorithm may be the same as the first preset encryption algorithm, or may be different from the first preset encryption algorithm, and this application does not make any specific limitation on this.

[0099] Furthermore, before the above step S302, the SSL negotiation method provided in the embodiment of the present application also includes steps C1 and C2.

[0100] C1: Get the identification information of the client handshake message;

[0101] C2: Determine, based on the identification information, that the second algorithm suite field in the client handshake message needs to be encrypted.

[0102] As an optional implementation, step C1 may be implemented by the following steps:

[0103] C11: The second proxy server parses the client handshake message and determines the source port and destination port of the client handshake message.

[0104] Correspondingly, step C2 can be implemented by the following steps:

[0105] C21: The second proxy server determines whether the source port of the client handshake message matches the source port in the port information table pre-configured in the second proxy server, and determines whether the destination port of the client handshake message matches the destination port in the port information table pre-configured in the second proxy server;

[0106] C22: If both match, it is determined that the second algorithm suite field in the client handshake message needs to be encrypted.

[0107] It can be understood that the above steps C1, C2, C11, C21 and C22 are similar to the above steps A1, A2, A11, A21 and A22. To make the specification concise, the same or similar parts can refer to each other and will not be repeated here.

[0108] As another optional implementation, an identification field may be provided in the client handshake message. If the value of the identification field is a second preset value, it indicates that the service corresponding to the client handshake message adopts the SSL negotiation method provided in the embodiment of the present application for SSL negotiation, and determines that the second proxy server needs to encrypt the second algorithm suite field in the client handshake message.

[0109] Step S303: the second proxy server sends the encrypted client handshake message to the first proxy server.

[0110] Step S304: the first proxy server receives the encrypted client handshake message sent by the second proxy server.

[0111] In the embodiment of the present application, after encrypting the client handshake message, the second proxy server sends the encrypted client handshake message to the first proxy server, and the first proxy server receives the encrypted client handshake message sent by the second proxy server.

[0112] Step S305: The first proxy server uses the decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field to obtain a client handshake message.

[0113] It can be understood that step S305 is similar to the aforementioned step S205. To make the description concise, the same or similar parts can be referenced to each other and will not be described in detail here.

[0114] Furthermore, considering that in actual application, some services use the SSL negotiation method provided in the embodiment of the present application for SSL negotiation, and some services do not use the SSL negotiation method provided in the embodiment of the present application for SSL negotiation. For services that do not use the SSL negotiation method provided in the embodiment of the present application for SSL negotiation, the first proxy server does not need to decrypt the second algorithm suite field in the client handshake message sent by these services, otherwise it will affect the normal processing of these services. Therefore, the SSL negotiation method provided in the embodiment of the present application also includes the steps of:

[0115] D1: The first proxy device obtains identification information of the client handshake message;

[0116] D2: The first proxy device determines, according to the identification information, that the second algorithm suite field in the client handshake message needs to be decrypted.

[0117] As an optional implementation, step B1 may be implemented by the following steps:

[0118] D11: The first proxy device parses the client handshake message and determines the source port and the destination port of the client handshake message.

[0119] Correspondingly, step D2 can be implemented by the following steps:

[0120] D21: The first proxy device determines whether the source port of the client handshake message matches the source port in the port information table preconfigured in the first proxy server, and determines whether the destination port of the client handshake message matches the destination port in the port information table preconfigured in the first proxy server.

[0121] D22: If both match, it is determined that the second algorithm suite field in the client handshake message needs to be decrypted.

[0122] It can be understood that the above steps D1, D2, D11, D21 and D22 are similar to the above steps B1, B2, B11, B21 and B22. To make the specification concise, the same or similar parts can refer to each other and will not be repeated here.

[0123] Step S306: The first proxy server sends the client handshake message to the server.

[0124] In an embodiment of the present application, the first proxy server uses a decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field, and after obtaining the client handshake message, sends the client handshake message to the server, so that the server can select the SSL encryption algorithm it supports according to the second algorithm suite field in the client handshake message, so as to subsequently generate a server handshake message according to the SSL encryption algorithm.

[0125] It should be noted that, in some embodiments, when the client and the server conduct SSL negotiation, the above steps S201-S206 can be used to encrypt the server handshake message, thereby improving the chance of leakage of the SSL encryption algorithm determined by the server and improving the security of encrypted transmission using the SSL protocol. In other embodiments, when the client and the server conduct SSL negotiation, the above steps S301-S306 can be used to encrypt the client handshake message first, and then the above steps S201-S206 can be used to encrypt the server handshake message, thereby encrypting the client handshake message and the server handshake message. In the above manner, the chance of leakage of the SSL encryption algorithm supported by the client and the SSL encryption algorithm determined by the server can be reduced at the same time, further improving the security of encrypted transmission using the SSL protocol.

[0126] Based on the same inventive concept, the present application embodiment also provides an SSL negotiation device. Figure 3 , Figure 3 This is a structural block diagram of an SSL negotiation device provided in an embodiment of the present application. The SSL negotiation device 300 is configured on a first proxy server, and the first proxy server is connected to a server. The SSL negotiation device includes:

[0127] The receiving module 301 is used to receive a server handshake message sent by the server; wherein the server handshake message includes a first algorithm suite field, and the value in the first algorithm suite field is used to represent the SSL encryption algorithm determined by the server;

[0128] The encryption module 302 is used to encrypt the first algorithm suite field in the server handshake message by using a first preset encryption algorithm to obtain an encrypted server handshake message;

[0129] The sending module 303 is used to send the encrypted server handshake message to the second proxy server, so that the second proxy server uses a decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field, determine the server handshake message, and send the server handshake message to the client.

[0130] In an optional implementation, the device further includes: an encryption determination module 304, configured to obtain identification information of the server handshake message; and determine, based on the identification information, that the first algorithm suite field in the server handshake message needs to be encrypted.

[0131] In an optional implementation, the encryption determination module 304 is specifically used to parse the server handshake message to determine the source port and destination port of the server handshake message; determine whether the source port of the server handshake message matches the source port in the port information table pre-configured in the first proxy server, and determine whether the destination port of the server handshake message matches the destination port in the port information table pre-configured in the first proxy server; if both match, determine that the first algorithm suite field in the server handshake message needs to be encrypted.

[0132] In an optional embodiment, the receiving module 301 is also used to receive an encrypted client handshake message sent by the second proxy server; wherein the encrypted client handshake message includes a second algorithm suite field encrypted by the second proxy server using a second preset encryption algorithm, and the value in the second algorithm suite field is used to represent the SSL encryption algorithm supported by the client; the device also includes: a decryption module 305, which is used to decrypt the second algorithm suite field using a decryption algorithm corresponding to the second preset encryption algorithm to obtain the client handshake message; the sending module 303 is also used to send the client handshake message to the server.

[0133] Based on the same inventive concept, the present application embodiment also provides an SSL negotiation device. Figure 4 , Figure 4 The present invention provides a structural block diagram of an SSL negotiation device according to an embodiment of the present invention. The SSL negotiation device 400 is configured on a second proxy server, and the second proxy server is connected to a client. The SSL negotiation device includes:

[0134] The receiving module 401 is used to receive an encrypted server handshake message sent by the first proxy server; wherein the encrypted server handshake message includes a first algorithm suite field encrypted by the first proxy server using a first preset encryption algorithm, and the value in the first algorithm suite field is used to represent the SSL encryption algorithm determined by the server;

[0135] A decryption module 402, configured to decrypt the first algorithm suite field using a decryption algorithm corresponding to the first preset encryption algorithm to obtain the server handshake message;

[0136] The sending module 403 is used to send the server handshake message to the client.

[0137] In an optional implementation, the receiving module 401 is also used to receive a client handshake message sent by the client; wherein the client handshake message includes a second algorithm suite field, and the value in the second algorithm suite field is used to characterize the SSL encryption algorithm supported by the client; the device also includes: an encryption module 404, which is used to encrypt the second algorithm suite field in the client handshake message using a second preset encryption algorithm to obtain an encrypted client handshake message; the sending module 403 is also used to send the encrypted client handshake message to the first proxy server, so that the first proxy server uses a decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field, determine the client handshake message, and send the client handshake message to the server.

[0138] In an optional implementation, the device further includes: an encryption determination module 405, configured to obtain identification information of the client handshake message; and determine, based on the identification information, that the second algorithm suite field in the client handshake message needs to be encrypted.

[0139] In an optional implementation, the encryption determination module 405 is specifically used to parse the client handshake message, determine the source port and destination port of the encrypted client handshake message; determine whether the source port of the client handshake message matches the source port in the port information table pre-configured in the first proxy server, and determine whether the destination port of the client handshake message matches the destination port in the port information table pre-configured in the first proxy server; if both match, determine that the second algorithm suite field in the client handshake message needs to be encrypted.

[0140] See also Figure 5 , Figure 5 This is a schematic diagram of the structure of an electronic device 500 according to an embodiment of the present application, and the electronic device 500 includes: at least one processor 501, at least one communication interface 502, at least one memory 503 and at least one bus 504. Among them, the bus 504 is used to realize the direct connection and communication of these components, the communication interface 502 is used to communicate signaling or data with other node devices, and the memory 503 stores machine-readable instructions executable by the processor 501. When the electronic device 500 is running, the processor 501 communicates with the memory 503 through the bus 504, and the machine-readable instructions are executed when called by the processor 501 as the above-mentioned SSL negotiation method.

[0141] The processor 501 can be an integrated circuit chip with signal processing capabilities. The above-mentioned processor 501 can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) or other programmable logic devices, discrete gates or transistor logic devices, discrete hardware components. It can implement or execute various methods, steps and logic block diagrams disclosed in the embodiments of the present application. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc.

[0142] The memory 503 may include but is not limited to random access memory (RAM), read only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), etc.

[0143] Understandably, Figure 5 The structure shown is for illustration only. The electronic device 500 may also include Figure 5 More or fewer components as shown, or with Figure 5 Different configurations shown. Figure 5 Each component shown in can be implemented by hardware, software or a combination thereof. In the embodiment of the present application, the electronic device 500 can be, but is not limited to, a physical device such as a desktop computer, a laptop computer, a smart phone, a smart wearable device, a vehicle-mounted device, etc., and can also be a virtual device such as a virtual machine. In addition, the electronic device 500 is not necessarily a single device, but can also be a combination of multiple devices, such as a server cluster, etc.

[0144] In addition, an embodiment of the present application further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a computer, the SSL negotiation method in the above embodiment is executed.

[0145] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. The device embodiments described above are merely schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be through some communication interfaces, and the indirect coupling or communication connection of the devices or units can be electrical, mechanical or other forms.

[0146] In addition, the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0147] Furthermore, the functional modules in the various embodiments of the present application may be integrated together to form an independent part, or each module may exist separately, or two or more modules may be integrated to form an independent part.

[0148] It should be noted that if the function is implemented in the form of a software function module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application can essentially be embodied in the form of a software product, or the part that contributes to the prior art or the part of the technical solution. The computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM) random access memory (RAM), disk or optical disk, and other media that can store program codes.

[0149] In this document, relational terms such as first and second, etc. are used merely to distinguish one entity or operation from another entity or operation, but do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0150] The above description is only an embodiment of the present application and is not intended to limit the protection scope of the present application. For those skilled in the art, the present application may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. An SSL negotiation method, characterized in that: Applied to a first proxy server connected to a server, the method comprises: Receive a server handshake message sent by the server; wherein the server handshake message includes a first algorithm suite field, and the value in the first algorithm suite field is used to represent the SSL encryption algorithm determined by the server; Encrypting the first algorithm suite field in the server handshake message using a first preset encryption algorithm to obtain an encrypted server handshake message; Sending the encrypted server handshake message to the second proxy server, so that the second proxy server uses a decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field, determine the server handshake message, and send the server handshake message to the client; Before encrypting the first algorithm suite field in the server handshake message using the first preset encryption algorithm, the method further includes: Obtaining identification information of the server handshake message; Determining, according to the identification information, that the first algorithm suite field in the server handshake message needs to be encrypted; The obtaining identification information of the server handshake message includes: Parsing the server handshake message to determine the source port and destination port of the server handshake message; The determining, according to the identification information, that the first algorithm suite field in the server handshake message needs to be encrypted includes: Determine whether the source port of the server handshake message matches the source port in the port information table pre-configured in the first proxy server, and determine whether the destination port of the server handshake message matches the destination port in the port information table pre-configured in the first proxy server; if both match, determine that the first algorithm suite field in the server handshake message needs to be encrypted.

2. The method according to claim 1, characterized in that Before receiving the server handshake message sent by the server, the method further includes: Receive an encrypted client handshake message sent by the second proxy server; wherein the encrypted client handshake message includes a second algorithm suite field encrypted by the second proxy server using a second preset encryption algorithm, and a value in the second algorithm suite field is used to represent an SSL encryption algorithm supported by the client; Decrypting the second algorithm suite field using a decryption algorithm corresponding to the second preset encryption algorithm to obtain the client handshake message; Send the client handshake message to the server.

3. An SSL negotiation method, characterized in that: Applied to a second proxy server connected to a client, the method comprises: Receive an encrypted server handshake message sent by the first proxy server; wherein the encrypted server handshake message includes a first algorithm suite field encrypted by the first proxy server using a first preset encryption algorithm, and a value in the first algorithm suite field is used to represent an SSL encryption algorithm determined by the server; Decrypting the first algorithm suite field using a decryption algorithm corresponding to the first preset encryption algorithm to obtain the server handshake message; Sending the server handshake message to the client; Before decrypting the first algorithm suite field using the decryption algorithm corresponding to the first preset encryption algorithm, the method further includes: Obtaining identification information of the server handshake message; Determining, according to the identification information, that the first algorithm suite field in the server handshake message needs to be encrypted; The obtaining identification information of the server handshake message includes: Parsing the server handshake message to determine the source port and destination port of the server handshake message; The determining, according to the identification information, that the first algorithm suite field in the server handshake message needs to be encrypted includes: Determine whether the source port of the server handshake message matches the source port in the port information table pre-configured in the first proxy server, and determine whether the destination port of the server handshake message matches the destination port in the port information table pre-configured in the first proxy server; if both match, determine that the first algorithm suite field in the server handshake message needs to be encrypted.

4. The method according to claim 3, characterized in that Before receiving the encrypted server handshake message sent by the first proxy server, the method further includes: receiving a client handshake message sent by the client; wherein the client handshake message includes a second algorithm suite field, and a value in the second algorithm suite field is used to represent an SSL encryption algorithm supported by the client; Encrypting the second algorithm suite field in the client handshake message by using a second preset encryption algorithm to obtain an encrypted client handshake message; The encrypted client handshake message is sent to the first proxy server, so that the first proxy server uses a decryption algorithm corresponding to the second preset encryption algorithm to decrypt the second algorithm suite field, determine the client handshake message, and send the client handshake message to the server.

5. The method according to claim 4, characterized in that Before encrypting the second algorithm suite field in the client handshake message by using the second preset encryption algorithm, the method further includes: Obtaining identification information of the client handshake message; It is determined according to the identification information that the second algorithm suite field in the client handshake message needs to be encrypted.

6. An SSL negotiation device, characterized in that: A first proxy server configured to be connected to a server, the device comprising: A receiving module, configured to receive a server handshake message sent by the server; wherein the server handshake message includes a first algorithm suite field, and a value in the first algorithm suite field is used to represent an SSL encryption algorithm determined by the server; An encryption module, used to encrypt the first algorithm suite field in the server handshake message by using a first preset encryption algorithm to obtain an encrypted server handshake message; a sending module, configured to send the encrypted server handshake message to a second proxy server, so that the second proxy server uses a decryption algorithm corresponding to the first preset encryption algorithm to decrypt the first algorithm suite field, determine the server handshake message, and send the server handshake message to the client; An encryption determination module is used to obtain identification information of the server handshake message; determine, based on the identification information, that a first algorithm suite field in the server handshake message needs to be encrypted; parse the server handshake message to determine a source port and a destination port of the server handshake message; determine whether the source port of the server handshake message matches a source port in a port information table pre-configured in the first proxy server, and determine whether the destination port of the server handshake message matches a destination port in a port information table pre-configured in the first proxy server; if both match, determine that the first algorithm suite field in the server handshake message needs to be encrypted.

7. An SSL negotiation device, characterized in that: A second proxy server configured to be connected to the client, the device comprising: A receiving module, configured to receive an encrypted server handshake message sent by a first proxy server; wherein the encrypted server handshake message includes a first algorithm suite field encrypted by the first proxy server using a first preset encryption algorithm, and a value in the first algorithm suite field is used to represent an SSL encryption algorithm determined by the server; a decryption module, configured to decrypt the first algorithm suite field using a decryption algorithm corresponding to the first preset encryption algorithm to obtain the server handshake message; A sending module, used for sending the server handshake message to the client; An encryption determination module is used to obtain identification information of the server handshake message; determine, based on the identification information, that a first algorithm suite field in the server handshake message needs to be encrypted; parse the server handshake message to determine a source port and a destination port of the server handshake message; determine whether the source port of the server handshake message matches a source port in a port information table pre-configured in the first proxy server, and determine whether the destination port of the server handshake message matches a destination port in a port information table pre-configured in the first proxy server; if both match, determine that the first algorithm suite field in the server handshake message needs to be encrypted.

8. An electronic device, characterized in that: include: processor, memory, and bus; The processor and the memory communicate with each other via the bus; The memory stores program instructions executable by the processor, and the processor calls the program instructions to execute the method according to any one of claims 1-2 or 3-5.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are read and executed by a computer, the method according to any one of claims 1 to 2 or 3 to 5 is executed.

Images