Method and device for detecting establishment of a secure connection

Abstract

The present invention relates to the field of financial technology (Fintech), and discloses a method and device for detecting the establishment of a secure connection, the method comprising: a detecting end sending a first handshake message to a first detected end; the detecting end determining whether the first information to be verified is a fault factor for the failure to establish a secure connection between the first detected end and the second detected end based on whether a second handshake message from the first detected end is received. The present invention determines whether the first information to be verified is a fault factor for the failure to establish a secure connection between the first detected end and the second detected end based on whether the detecting end receives the second handshake message from the first detected end. The detecting end does not require the user to be proficient in protocol-related knowledge to use, which greatly reduces the threshold for use. At the same time, when detecting a connection failure, the detection can be completed quickly, reducing the time required for fault analysis.

Description

Technical Field

[0001] The present invention relates to the technical field of financial technology (Fintech), and in particular to a method and device for detecting the establishment of a secure connection. Background Art

[0002] With the development of computer technology, more and more technologies (such as distributed architecture, cloud computing or big data) are being applied in the financial field. Traditional finance is gradually transforming into financial technology, and big data technology is no exception. However, due to the security and real-time requirements of the financial and payment industries, there are higher requirements for the security of components used in financial systems.

[0003] Currently, there are two main methods for detecting Secure Sockets Layer (SSL) faults:

[0004] The first method: When an SSL-related failure occurs, manually search the Internet for related problems and solutions based on the error message.

[0005] For the above solution, when searching for related problems and solutions based on the error information of SSL failure on the Internet, you may need to try many methods to solve the problem, and there may be some problems that cannot be solved directly by searching.

[0006] Method 2: Use the s_client and s_server commands of OpenSSL (a toolkit for the SSL protocol) to test the SSL connection and analyze the cause of the problem based on the output results.

[0007] The above solution uses OpenSSL's s_client and s_server commands to test the SSL connection. This has a certain learning cost and requires the user to have relevant usage experience so that the cause of the failure can be analyzed based on the output results. Summary of the Invention

[0008] The present application provides a method and apparatus for detecting the establishment of a secure connection, so as to solve the problem of efficiently and accurately detecting the establishment of a secure connection.

[0009] In a first aspect, an embodiment of the present application provides a method for detecting establishment of a secure connection, comprising:

[0010] The detecting end sends a first handshake message to the first detected end; the first handshake message includes first information to be verified; the first information to be verified is information of the second detected end or information generated when the detecting end simulates the second detected end;

[0011] The detecting end determines, based on whether the second handshake message from the first detected end is received, whether the first information to be verified is a fault factor causing a failure in establishing a secure connection between the first detected end and the second detected end;

[0012] The detecting end receives a third handshake message sent by the second detected end, where the third handshake message includes second information to be verified; the second information to be verified is information of the first detected end or information of the second detected end;

[0013] The detecting end detects the second information to be verified, thereby determining whether the second information to be verified is a fault factor causing failure in establishing a secure connection between the first detected end and the second detected end.

[0014] The above scheme simulates the handshake messages of the first detected end and / or the second detected end during the process of establishing a secure connection by introducing a detection end, thereby determining whether the first information to be verified is a fault factor for the failure to establish a secure connection between the first detected end and the second detected end based on whether the second handshake message of the first detected end is received. The detection end does not require the user to be proficient in protocol-related knowledge to use, which greatly reduces the usage threshold. At the same time, when detecting connection failures, the detection can be completed quickly, reducing the time required for fault analysis. At the same time, in the detection process, the detection of the second information to be verified is introduced by the detection end to determine whether the second information to be verified is a fault factor for the failure to establish a secure connection between the first detected end and the second detected end. This detection process requires interaction between the first detected end and the second detected end, thus providing a basis for the accuracy of the detection.

[0015] Optionally, the first detected end is a client, and the second detected end is a server;

[0016] The first information to be verified is the highest protocol version supported by the server;

[0017] The second information to be verified is the highest protocol version supported by the client;

[0018] The detection end detects the second information to be verified, including: if the detection end determines that the highest protocol version supported by the client is lower than the protocol version supported by the server, determining that the fault factor is that the protocol version supported by the client does not meet the requirement of the server;

[0019] If the detecting end determines that the highest protocol version supported by the client is higher than the protocol version supported by the server, the detecting end sends the first handshake message to the first detected end; the second handshake message is sent when the client determines that the highest protocol version supported by the server meets the protocol version supported by the client; otherwise, it is determined that the failure factor is that the protocol version supported by the server does not meet the requirements of the client.

[0020] In the above scheme, if the detection end determines that the highest protocol version supported by the client is lower than the protocol version supported by the server, the fault factor is determined to be that the protocol version supported by the client does not meet the requirements of the server, thereby improving the efficiency and accuracy of fault detection.

[0021] Optionally, the first detected end is a server, and the second detected end is a client;

[0022] The first information to be verified is the cipher suite supported by the client;

[0023] The second handshake message is sent by the server after determining that the server supports the cipher suite supported by the client;

[0024] The detecting end determines, based on whether the second handshake message from the first detected end is received, whether the first information to be verified is a fault factor for failure to establish a secure connection between the first detected end and the second detected end, including:

[0025] If the detection end does not receive the second handshake message, it determines that the failure factor is that the cipher suite supported by the client does not match the cipher suite supported by the server.

[0026] The above solution determines that the fault factor is whether the cipher suite supported by the client matches the cipher suite supported by the server by detecting whether the client receives the second handshake message, thereby improving the efficiency and accuracy of fault detection.

[0027] Optionally, the first information to be verified is a detection end certificate sent by the detection end when simulating the second detected end;

[0028] The second information to be verified is the sent certificate of the first detected end or the sent certificate of the second detected end;

[0029] The second handshake message is sent when the first detected end determines that the detecting end certificate sent by the detecting end matches the detecting end certificate pre-installed by the first detected end;

[0030] The detecting end determines, based on whether the second handshake message from the first detected end is received, whether the first information to be verified is a fault factor for failure to establish a secure connection between the first detected end and the second detected end, including:

[0031] If the detecting end does not receive the second handshake message, it determines that the fault factor is an error in pre-installing the certificate on the first detected end;

[0032] The detecting end detects the second information to be verified, including:

[0033] The detection end determines whether the first detected end certificate sent matches the first detected end certificate pre-installed in the detection end, or whether the second detected end certificate sent matches the second detected end certificate pre-installed in the detection end. If they do not match, it is determined that the fault factor is that the first detected end or the second detected end made an error when sending the certificate.

[0034] The above solution improves the efficiency and accuracy of certificate fault detection by determining, through the detecting end, whether the detected end has an error when pre-installing the certificate or when sending the certificate.

[0035] Optionally, the first detected end is a client, and the second detected end is a server;

[0036] The first information to be verified is a legitimate detection terminal certificate and an illegal detection terminal certificate sent by the detection terminal when simulating the second detected terminal;

[0037] The second information to be verified is the sent second detected end certificate;

[0038] The detecting end determines, based on whether the second handshake message from the first detected end is received, whether the first information to be verified is a fault factor for failure in establishing a secure connection between the first detected end and the second detected end, including:

[0039] If the detection end does not receive the second handshake message for the sent detection end legal certificate, it is determined that the fault is the certificate verification function of the client;

[0040] If the detecting end receives the second handshake message for the sent detecting end legal certificate and does not receive the second handshake message for the sent detecting end illegal certificate, it determines that the certificate verification function of the client is normal and receives the third handshake message sent by the second detected end;

[0041] The detecting end detects the second information to be verified, thereby determining whether the second information to be verified is a fault factor for failure to establish a secure connection between the first detected end and the second detected end, including:

[0042] The detecting end determines whether the sent certificate of the second detected end is legal. If illegal, it determines that the fault factor is that the certificate of the second detected end is illegal.

[0043] The above solution determines the certificate validity failure by determining whether the detecting end receives the second handshake message for the sent detecting end legal certificate and whether the sent second detected end certificate is legal, thereby improving the efficiency and accuracy of certificate fault detection.

[0044] Optionally, the method further includes:

[0045] The detecting end obtains the disabled first secure connection SSL parameter of the first detected end, where the first detecting end uses a JDK environment;

[0046] The detecting end obtains a second SSL parameter from a fourth handshake message of the second detected end;

[0047] The detection end determines whether the disabled parameters in the second SSL parameters are consistent with the first SSL parameters; if they are consistent, it is determined that the failure factor is that the SSL parameters of the second detected end are disabled by the first detected end.

[0048] The above solution determines whether the fault is caused by the SSL parameters of the second detected end being disabled by the first detected end by determining whether the disabled parameters in the second SSL parameters are consistent with the first SSL parameters by the detection end. It is simple and efficient.

[0049] In a second aspect, an embodiment of the present application provides a device for detecting establishment of a secure connection, the device comprising:

[0050] a sending module configured to send a first handshake message to a first detected end; the first handshake message includes first information to be verified; the first information to be verified is information of the second detected end or information generated when the detecting end simulates the second detected end;

[0051] A processing module is used to determine whether the first information to be verified is a fault factor for the failure to establish a secure connection between the first detected end and the second detected end based on whether a second handshake message from the first detected end is received; receive a third handshake message sent by the second detected end, the third handshake message including second information to be verified; the second information to be verified is information of the first detected end or information of the second detected end; and detect the second information to be verified to determine whether the second information to be verified is a fault factor for the failure to establish a secure connection between the first detected end and the second detected end.

[0052] Optionally, the first detected end is a client, and the second detected end is a server;

[0053] The first information to be verified is the highest protocol version supported by the server;

[0054] The second information to be verified is the highest protocol version supported by the client;

[0055] The processing module is specifically used for:

[0056] If it is determined that the highest protocol version supported by the client is lower than the protocol version supported by the server, then it is determined that the fault factor is that the protocol version supported by the client does not meet the requirements of the server;

[0057] If it is determined that the highest protocol version supported by the client is higher than the protocol version supported by the server, the detecting end sends the first handshake message to the first detected end; the second handshake message is sent when the client determines that the highest protocol version supported by the server meets the protocol version supported by the client; otherwise, it is determined that the failure factor is that the protocol version supported by the server does not meet the requirements of the client.

[0058] Optionally, the first detected end is a server, and the second detected end is a client;

[0059] The first information to be verified is the cipher suite supported by the client;

[0060] The second handshake message is sent by the server after determining that the server supports the cipher suite supported by the client;

[0061] The processing module is specifically used for:

[0062] If the second handshake message is not received, it is determined that the failure factor is that the cipher suite supported by the client does not match the cipher suite supported by the server.

[0063] Optionally, the first information to be verified is a detection end certificate sent by the detection end when simulating the second detected end;

[0064] The second information to be verified is the sent certificate of the first detected end or the sent certificate of the second detected end;

[0065] The second handshake message is sent when the first detected end determines that the detecting end certificate sent by the detecting end matches the detecting end certificate pre-installed by the first detected end;

[0066] The processing module is specifically used for:

[0067] If the second handshake message is not received, it is determined that the fault factor is an error in pre-installing the certificate on the first detected end;

[0068] The processing module is specifically used for:

[0069] Determine whether the first detected end certificate sent matches the first detected end certificate pre-installed on the detection end, or whether the second detected end certificate sent matches the second detected end certificate pre-installed on the detection end. If they do not match, determine that the fault factor is that the first detected end or the second detected end made an error when sending the certificate.

[0070] Optionally, the first detected end is a client, and the second detected end is a server;

[0071] The first information to be verified is a legitimate detection terminal certificate and an illegal detection terminal certificate sent by the detection terminal when simulating the second detected terminal;

[0072] The second information to be verified is the sent second detected end certificate;

[0073] The processing module is specifically used for:

[0074] If the second handshake message for the sent valid certificate of the detection end is not received, determining that the fault is a certificate verification function of the client;

[0075] If a second handshake message for the sent valid certificate of the detection end is received, and a second handshake message for the sent invalid certificate of the detection end is not received, determining that the certificate verification function of the client is normal, and receiving the third handshake message sent by the second detected end;

[0076] The processing module is specifically used for:

[0077] Determine whether the sent second detected terminal certificate is legal; if illegal, determine that the fault factor is that the certificate of the second detected terminal is illegal.

[0078] Optionally, the processing module is further configured to:

[0079] Obtaining a disabled first secure connection SSL parameter of the first detected end, where the first detecting end uses a JDK environment;

[0080] Obtaining a second SSL parameter from a fourth handshake message of the second detected end;

[0081] Determine whether the disabled parameters in the second SSL parameters are consistent with the first SSL parameters; if they are consistent, determine that the failure factor is that the SSL parameters of the second detected end are disabled by the first detected end.

[0082] Accordingly, an embodiment of the present invention further provides a computing device, including:

[0083] a memory for storing program instructions;

[0084] The processor is configured to call the program instructions stored in the memory and execute the above-mentioned method for detecting the establishment of a secure connection according to the obtained program.

[0085] Accordingly, an embodiment of the present invention further provides a computer-readable non-volatile storage medium, comprising computer-readable instructions. When a computer reads and executes the computer-readable instructions, the computer executes the above-mentioned method for detecting establishment of a secure connection. BRIEF DESCRIPTION OF THE DRAWINGS

[0086] In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0087] Figure 1 A schematic diagram of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0088] Figure 2 A schematic diagram of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0089] Figure 3 A system framework for a method for detecting the establishment of a secure connection provided by an embodiment of the present invention;

[0090] Figure 4 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0091] Figure 5A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0092] Figure 6 A system framework for a method for detecting the establishment of a secure connection provided by an embodiment of the present invention;

[0093] Figure 7 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0094] Figure 8 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0095] Figure 9 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0096] Figure 10 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0097] Figure 11 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0098] Figure 12 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0099] Figure 13 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0100] Figure 14 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0101] Figure 15 A flowchart of a method for detecting establishment of a secure connection provided by an embodiment of the present invention;

[0102] Figure 16 A schematic structural diagram of a device for detecting establishment of a secure connection provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0103] To make the objectives, technical solutions, and advantages of the present invention more apparent, the present invention will be further described in detail below with reference to the accompanying drawings. It is apparent that the embodiments described are only some, not all, of the present invention. All other embodiments derived by persons of ordinary skill in the art based on the embodiments of the present invention without creative effort are intended to fall within the scope of protection of the present invention.

[0104] First, the present invention is mainly aimed at SSL failures. Some terms in this application are explained below to facilitate understanding by those skilled in the art.

[0105] The SSL (Secure Sockets Layer) secure socket protocol and its subsequent version TLS (Transport Layer Security) secure transport layer protocol are protocols used to establish authenticated and encrypted links between networked computers.

[0106] Before introducing the embodiments of the present invention, the prior art is described as follows to provide a better understanding of the present invention.

[0107] The detection terminal provided in the embodiment of the present invention is used in a proxy-like manner. When a client fails to connect to the server, the detection terminal acts as an intermediate proxy to check whether the failure is caused by the client or the server, and provides the specific cause of the failure and detailed steps to solve the problem.

[0108] Furthermore, when the client connects directly to the server, such as Figure 1 When the client connects to the server through the detection end, as shown in Figure 2 shown.

[0109] From the above content, it can be seen that for the client, the detection end exists as the server in the connection; for the server, the detection end exists as the client in the connection.

[0110] Based on this, the embodiment of the present invention provides a method for detecting the establishment of a secure connection. The method for detecting the establishment of a secure connection provided by the embodiment of the present invention can be applied to Figure 3 In the system architecture shown, the system architecture includes a first detected end 100 , a detecting end 200 , and a second detected end 300 .

[0111] Among them, the detecting end 200 sends a first handshake message to the first detected end 100; the detecting end 200 determines whether the first information to be verified is a fault factor for the failure to establish a secure connection between the first detected end 100 and the second detected end 300 based on whether it receives a second handshake message from the first detected end 100.

[0112] It should be noted that the first information to be verified is information of the second detected end 300 or information generated when the detecting end 200 simulates the second detected end 300.

[0113] Based on the system architecture shown above, Figure 4 A flowchart corresponding to a method for detecting the establishment of a secure connection provided by an embodiment of the present invention is shown as follows: Figure 4 As shown, the method includes:

[0114] Step 401: A detecting end sends a first handshake message to a first detected end.

[0115] It should be noted that the first handshake message includes the first information to be verified; the first information to be verified is information of the second detected end or information generated when the detecting end simulates the second detected end.

[0116] Step 402: The detecting end determines whether the first information to be verified is a fault factor for failure in establishing a secure connection between the first detected end and the second detected end based on whether the second handshake message from the first detected end is received.

[0117] The above scheme determines whether the first information to be verified is the fault factor for the failure to establish a secure connection between the first detected end and the second detected end based on whether the detecting end receives the second handshake message from the first detected end. The detecting end does not require the user to be proficient in protocol-related knowledge to use it, which greatly reduces the usage threshold. At the same time, when detecting connection failures, it can complete the detection quickly, reducing the time required for fault analysis.

[0118] In a possible implementation, the first detected end is a server, and the second detected end is a client.

[0119] Specifically, the first information to be verified is the cipher suite supported by the client; the second handshake message is sent by the server after the server determines that the server supports the cipher suite of the client;

[0120] In step 402, if the detection end does not receive the second handshake message, it determines that the failure factor is that the cipher suite supported by the client does not match the cipher suite supported by the server.

[0121] For example, for a failure caused by a mismatch between the cipher suites supported by the client and the server, when using the detection terminal for detection, such as Figure 5 As shown, follow these steps:

[0122] S11: Use the client connection detection end to send the SSL cipher suite list it supports in the Client Hello message.

[0123] It should be noted that the Client Hello message is always the first message in a new handshake process. This message conveys the client's capabilities and preferences to the server.

[0124] S12: The detection end receives the SSL cipher suite list supported by the client and records it.

[0125] S13: The detection end connects to the server and sends a Client Hello message, in which the list of SSL cipher suites supported by the client is included.

[0126] S14: After receiving the request, if the server supports the client's cipher suite, it selects one and returns it in a ServerHello message. If it does not support the client's cipher suite, the handshake is terminated, and no handshake message is received from the server. This indicates that the fault is caused by a mismatch between the cipher suites used by the server and the client. The detection end generates a fault detection result and a solution and ends the detection.

[0127] Furthermore, the embodiment of the present invention provides a method for detecting the establishment of a secure connection. The method for detecting the establishment of a secure connection provided by the embodiment of the present invention can be applied to Figure 6 In the system architecture shown, the system architecture includes a first detected end 400 , a detecting end 500 , and a second detected end 600 .

[0128] The detecting end 500 receives the third handshake message sent by the second detected end 600 and detects the second information to be verified to determine whether the second information to be verified is a fault factor for failure to establish a secure connection between the first detected end 400 and the second detected end 600.

[0129] It should be noted that Figure 6 This is only an example of the system architecture of the embodiment of the present application, and the present application does not make any specific limitations on this.

[0130] Based on the system architecture shown above, Figure 7 A flowchart corresponding to a method for detecting the establishment of a secure connection provided by an embodiment of the present invention is shown as follows: Figure 7 As shown, the method includes:

[0131] Step 701: The detecting end receives a third handshake message sent by the second detected end.

[0132] It should be noted that the third handshake message includes the second information to be verified; the second information to be verified is the information of the first detected end or the information of the second detected end.

[0133] In step 702, the detecting end detects the second information to be verified, thereby determining whether the second information to be verified is a fault factor causing failure in establishing a secure connection between the first detected end and the second detected end.

[0134] The above scheme detects the second information to be verified by the detection end, so as to determine whether the second information to be verified is the fault factor for the failure to establish a secure connection between the first detected end and the second detected end. The detection end does not require the user to be proficient in protocol-related knowledge to use it, which greatly reduces the usage threshold. At the same time, when detecting connection failures, it can complete the detection quickly, reducing the time required for fault analysis.

[0135] It should be noted that the above method is Figure 4 The method flow shown can be executed in parallel, that is, simultaneously, or in series, that is, first Figure 4 The method flow is then executed, and the above method flow is not specifically limited in this application.

[0136] In a possible implementation, the first detected end is a client, and the second detected end is a server.

[0137] Specifically, the first information to be verified is the highest protocol version supported by the server; the second information to be verified is the highest protocol version supported by the client;

[0138] Furthermore, in step 702, if the detection end determines that the highest protocol version supported by the client is lower than the protocol version supported by the server, it is determined that the fault factor is that the protocol version supported by the client does not meet the requirements of the server;

[0139] Furthermore, if the detection end determines that the highest protocol version supported by the client is higher than the protocol version supported by the server, the detection end sends a first handshake message to the first detected end; the first handshake message is sent when the client determines that the highest protocol version supported by the server is consistent with the protocol version supported by the client; otherwise, it is determined that the fault factor is that the protocol version supported by the server does not meet the client's requirements.

[0140] For example, for a fault caused by a mismatch between the SSL protocol versions supported by the client and the server, when using the detection terminal for detection, such as Figure 8 As shown, follow these steps:

[0141] S21: Use the detection end to connect to the server and send each version of the SSL protocol in the Client Hello message in sequence.

[0142] S22: The detection end receives the SSL protocol version supported by the server returned in the Server Hello message and records it.

[0143] S23: Use the client connection detection end to send the highest SSL protocol version supported by itself in the Client Hello message.

[0144] S24: The detection end determines whether the protocol versions supported by the server include the highest version supported by the client. If not, the fault is determined to be caused by a discrepancy between the SSL protocol version used by the client and the server. The detection end then generates a fault detection result and a troubleshooting solution, and ends the detection. Otherwise, the detection end returns the highest SSL protocol version supported by the server to the client in a Server Hello message. If the SSL handshake fails, the fault is caused by a discrepancy between the SSL protocol version used by the server and the SSL client. The detection end generates a fault detection result and a troubleshooting solution, and ends the detection.

[0145] In another possible implementation, the first information to be verified is the detecting end certificate sent when the detecting end simulates the second detected end; the second information to be verified is the sent first detected end certificate or the sent second detected end certificate.

[0146] Furthermore, the second handshake message is sent when the first detected end determines that the detecting end certificate sent by the detecting end matches the detecting end certificate pre-installed in the first detected end.

[0147] In a possible example, if the detecting end does not receive the second handshake message, it determines that the fault factor is an error in pre-installing the certificate on the first detected end.

[0148] In another possible example, the detection end determines whether the first detected end certificate sent matches the first detected end certificate pre-installed on the detection end, or whether the second detected end certificate sent matches the second detected end certificate pre-installed on the detection end. If they do not match, it is determined that the fault factor is that the first detected end or the second detected end made an error when sending the certificate.

[0149] For example, there are two situations for client and server to verify the certificate:

[0150] 1. One-way authentication: The client verifies the server certificate, but the server does not verify the client certificate.

[0151] In the embodiment of the present application, for the client, the detection end is equivalent to another different server.

[0152] Specifically, such as Figure 9 As shown, follow these steps:

[0153] S31: Use the client to connect to the detection end and send a Client Hello message;

[0154] S32: After receiving the message, the detection end sends a Client Hello message to the server;

[0155] S33: After receiving the above message, the server returns a Server Hello and Server Certificate message, and returns the SSL certificate provided by the server in the Server Certificate message;

[0156] S34: After receiving the above message from the server, the detection end verifies whether the certificate returned in the Server Certificate message is consistent with the pre-installed certificate;

[0157] S35: If the certificate returned by the server does not match, it indicates that the fault is caused by an incorrect certificate returned by the server, i.e., an error occurred when the server sent the certificate. The detection end generates a fault detection result and a fault solution and ends the detection.

[0158] Furthermore, the certificate returned by the server does not match, and the detection end returns a Server Hello and Server Certificate message to the client, and returns the SSL certificate provided by the detection end in the Server Certificate message. After receiving the message returned by the detection end, the client verifies whether the certificate returned in the Server Certificate message matches the pre-installed certificate; if the client fails to verify the certificate returned by the detection end, the client will terminate the SSL handshake. The detection end fails to receive the handshake message returned by the client, indicating that the cause of the failure is that the client configured the server certificate incorrectly. The detection end will generate a fault detection result and a fault solution and end the detection.

[0159] 2. Two-way authentication: Both the client and the server verify the other party's certificate.

[0160] In a possible implementation of the embodiment of the present application, a detection terminal is used to detect a fault caused by a mismatch in a two-way authentication certificate. First, it is detected whether the fault is caused by the client, and then it is detected whether the fault is caused by the server.

[0161] It should be noted that the embodiment of the present application may also first detect whether the fault is caused by the server, and then detect whether the fault is caused by the client. This application does not make specific limitations on this.

[0162] Specifically, when using the detection end to detect whether the certificate mismatch failure is caused by the client, for the client, the detection end is equivalent to another different SSL server.

[0163] In the embodiment of the present application, the detection terminal is used to detect whether the fault is caused by the client. Figure 10 As shown, follow these steps:

[0164] S41: Use the client to connect to the detection end and send a Client Hello message.

[0165] S42: After receiving the message, the detection end returns a Server Hello, Server Certificate, and Certificate Request message to the client, adds the detection end's certificate to the Server Certificate message, and requests the client to send the certificate through a Certificate Request message.

[0166] S43: After receiving the message returned by the detection end, the client verifies whether the certificate returned by the Server Certificate message is consistent with the pre-installed certificate.

[0167] S44: If the client fails to verify the certificate, the client terminates the SSL handshake. The detection end fails to receive the handshake message from the client, indicating that the cause of the failure is that the client incorrectly configured the server certificate. The detection end generates a fault detection result and a fault solution and ends the test. If the client verifies the certificate, the client sends a Client Certificate message containing the client certificate to the detection end. The detection end verifies whether the certificate sent by the client matches the pre-installed certificate. If the verification fails, it indicates that the cause of the failure is that the client certificate sent by the client is incorrect. The detection end generates a fault detection result and a fault solution and ends the test.

[0168] Furthermore, when using the detection end to detect whether the certificate mismatch failure is caused by the server end, for the server end, the detection end is equivalent to another identical client end.

[0169] In the embodiment of the present application, when the detection end is used to detect whether the fault is caused by the service end, Figure 11 As shown, follow these steps:

[0170] S51: Use the detection end to connect to the server and send a Client Hello message;

[0171] S52: After receiving the message, the server returns a Server Hello, Server Certificate, and Certificate Request message to the detection end. The server certificate is added to the Server Certificate message, and the detection end is requested to send the certificate through the Certificate Request message.

[0172] S53: After receiving the message returned by the server, the detection end verifies whether the certificate returned by the Server Certificate message is consistent with the pre-installed certificate;

[0173] S54: If the detection end fails to verify the server certificate, it means that the cause of the fault is that the certificate returned by the server is incorrect. The detection end will generate a fault detection result and a fault solution and end the detection; if the detection end verifies the server certificate, the detection end will send a Client Certificate message to the server, which contains the SSL client certificate; the server verifies whether the certificate sent by the detection end is consistent with the pre-installed certificate. If the verification fails, the handshake is terminated, indicating that the cause of the fault is that the client certificate configured by the server is incorrect. The detection end will generate a fault detection result and a fault solution and end the detection.

[0174] The above is the fault caused by the verification process of whether the certificate matches. In addition, illegal certificates can also cause faults. The following is a detailed introduction:

[0175] In the embodiment of the present application, the first detected end is a client, and the second detected end is a server;

[0176] Specifically, the first information to be verified is the legal certificate of the detecting end and the illegal certificate of the detecting end sent when the detecting end simulates the second detected end; the second information to be verified is the certificate of the second detected end sent.

[0177] Furthermore, if the detection end does not receive the second handshake message for the sent detection end legal certificate, it is determined that the fault is the certificate verification function of the client;

[0178] If the detection end receives the second handshake message for the sent detection end legal certificate and does not receive the second handshake message for the sent detection end illegal certificate, it determines that the certificate verification function of the client is normal and receives the third handshake message sent by the second detected end;

[0179] The detecting end determines whether the sent certificate of the second detected end is legal. If illegal, it is determined that the fault factor is that the certificate of the second detected end is illegal.

[0180] In a possible implementation, the legal certificate is a non-expired certificate, and the illegal certificate is an expired certificate.

[0181] Determine whether the handshake status of the client for the expired certificate and the non-expired certificate is consistent. If they are consistent, it is determined that the fault result is that the client did not detect whether the server certificate is expired.

[0182] Specifically, for failures caused by expired server certificates, when using the detection terminal for detection, such as Figure 12 As shown, follow these steps:

[0183] S61: Use the client to connect to the detection end and send a Client Hello message;

[0184] S62: After receiving the message, the detection end returns a Server Hello and a Server Certificate message, and returns the unexpired / expired certificate in the Server Certificate message respectively;

[0185] S63: After receiving the message, if the detection end returns a non-expired certificate, the client will continue with the subsequent operation; if the detection end returns an expired certificate, the client will terminate the SSL handshake.

[0186] It should be noted that after the above tests, the detection end can determine whether the client has detected whether the server certificate has expired.

[0187] S64: The detection end connects to the server and sends a Client Hello message;

[0188] S65: After receiving the message, the server returns a Server Hello and Server Certificate message, and returns the certificate in the Server Certificate message;

[0189] S66: After receiving the message, the detection end checks whether the server certificate returned in the Server Certificate message has expired;

[0190] S67: When the detection end has confirmed that the client will verify whether the server certificate is expired, if the detection end detects that the certificate returned by the server has expired, it means that the cause of the fault is that the certificate returned by the server has expired. The detection end will generate a fault detection result and a fault solution and end the detection.

[0191] In another possible embodiment, a legitimate certificate is a certificate whose CN information of the server certificate is consistent with the server address, and an illegal certificate is a certificate whose CN information of the server certificate is inconsistent with the server address.

[0192] Specifically, determine whether the handshake status of the client for the certificate whose CN information of the server certificate is consistent with the server address or inconsistent with the server address is consistent. If they are consistent, it is determined that the fault result is that the client did not detect whether the CN information of the server certificate is consistent with the server address;

[0193] If they are inconsistent, determine whether the CN information of the certificate provided by the server is consistent with the server address;

[0194] If they are inconsistent, it is determined that the fault is that the CN information of the certificate returned by the server is inconsistent with the server address.

[0195] In the embodiment of the present application, for the failure caused by the inconsistency between the CN information of the server certificate and the server address, when using the detection terminal for detection, such as Figure 13As shown, follow these steps:

[0196] S71: Use the client to connect to the detection end and send a Client Hello message;

[0197] S72: After receiving the message, the detection end returns a Server Hello and a Server Certificate message, and in the Server Certificate message, returns the certificate whose CN information is consistent or inconsistent with the server address;

[0198] S73: After receiving the message, if the detection end returns a certificate whose CN information is consistent with the server address, the SSL client will continue with subsequent operations; if the returned certificate has CN information inconsistent with the server address, the SSL client will terminate the SSL handshake.

[0199] It should be noted that after the above tests, the detection end can determine whether the client has the detection server certificate CN information and whether it is consistent with the server address.

[0200] S74: The detection end connects to the server and sends a Client Hello message;

[0201] S75: After receiving the message, the server returns a Server Hello and a Server Certificate message. In the Server Certificate message, the server returns a certificate whose CN information is consistent with or inconsistent with the server address.

[0202] S76: After receiving the message, the detection end checks whether the server certificate CN information returned in the Server Certificate message is consistent with the server address;

[0203] S77: When the detection end has confirmed that the client will verify whether the server certificate CN information is consistent with the server address, if the detection end detects that the certificate CN information returned by the SSL server is inconsistent with the server address, it means that the cause of the fault is that the certificate CN information returned by the server is inconsistent with the server address. The detection end will generate a fault detection result and a fault solution and end the detection.

[0204] Furthermore, considering that JDK (Java Development Kit) disables some insecure SSL parameters by default, including SSL protocol version, signature, HASH, data encryption-related cryptographic algorithms, key length, etc., for example, JDK8 disables MD2, MD5, SSLv3, RC4, MD5withRSA, etc.

[0205] After disabling some SSL parameters based on the JDK, SSL clients or servers using the JDK environment may experience SSL failures during connections due to the use of the disabled SSL parameters.

[0206] In the embodiment of the present application, the detecting end obtains the disabled first secure connection SSL parameter of the first detected end, and the first detecting end uses the JDK environment;

[0207] The detecting end obtains the second SSL parameter from the fourth handshake message of the second detected end;

[0208] The detection end determines whether the disabled parameters in the second SSL parameters are consistent with the first SSL parameters; if they are consistent, it is determined that the fault factor is that the SSL parameters of the second detected end are disabled by the first detected end.

[0209] For a clearer explanation, the following describes two cases: one using the JDK environment on the client side and the other using the JDK environment on the server side.

[0210] When the client uses the JDK environment, use the detection terminal to check whether the SSL failure is caused by disabling SSL parameters on the client JDK. The detection terminal and the client need to be installed on the same server, such as Figure 14 As shown, the detection process is as follows:

[0211] S81: The detection end obtains the SSL parameters disabled by the client JDK;

[0212] S82: Use the detection end to connect to the SSL server and send a Client Hello message;

[0213] S83: After receiving the message, the server returns a Server Hello and a Server Certificate message. The Server Hello message returns the SSL protocol version and cipher suite selected by the server, and the Server Certificate message returns the certificate provided by the server.

[0214] S84: After receiving the above message, the detection end checks whether the SSL parameters returned by the SSL server are disabled according to the SSL parameters disabled by the client JDK. If they are disabled, it means that the cause of the fault is that the parameters returned by the server are disabled by the client JDK. The detection end will generate the fault detection results and fault solution and end the detection.

[0215] When the server uses the JDK environment, use the detection terminal to check whether the SSL failure is caused by disabling SSL parameters on the server JDK. The detection terminal and the server need to be installed on the same server, such as Figure 15 As shown, the detection process is as follows:

[0216] S91: Use the client connection detection end to send a Client Hello message, which contains information such as the highest SSL protocol version supported by the client and the list of supported cipher suites;

[0217] S92: After receiving the message, the detection end obtains the SSL parameters disabled by the server JDK;

[0218] S93: The detection end checks whether the SSL parameters sent by the SSL client are disabled based on the SSL parameters disabled by the server JDK. If they are disabled, it means that the cause of the fault is that the parameters used by the client are disabled by the server JDK. The detection end will generate the fault detection results and fault solution and end the detection.

[0219] The above solution can detect the connection fault and provide user-friendly and detailed fault information and solutions efficiently and accurately, so that users can understand the cause of the problem and how to solve it in detail.

[0220] Based on the same inventive concept, Figure 16 An apparatus for detecting establishment of a secure connection provided by an embodiment of the present invention is exemplarily shown. The apparatus may be a flow of a method for detecting establishment of a secure connection.

[0221] The sending module 1601 is configured to send a first handshake message to the first detected end; the first handshake message includes first information to be verified; the first information to be verified is information of the second detected end or information generated when the detecting end simulates the second detected end;

[0222] Processing module 1602 is used to determine whether the first information to be verified is a fault factor for the failure to establish a secure connection between the first detected end and the second detected end based on whether the second handshake message of the first detected end is received; receive a third handshake message sent by the second detected end, the third handshake message containing second information to be verified; the second information to be verified is information of the first detected end or information of the second detected end; detect the second information to be verified, so as to determine whether the second information to be verified is a fault factor for the failure to establish a secure connection between the first detected end and the second detected end.

[0223] Optionally, the first detected end is a client, and the second detected end is a server;

[0224] The first information to be verified is the highest protocol version supported by the server;

[0225] The second information to be verified is the highest protocol version supported by the client;

[0226] The processing module 1602 is specifically configured to:

[0227] If it is determined that the highest protocol version supported by the client is lower than the protocol version supported by the server, then it is determined that the fault factor is that the protocol version supported by the client does not meet the requirements of the server;

[0228] If it is determined that the highest protocol version supported by the client is higher than the protocol version supported by the server, the detecting end sends the first handshake message to the first detected end; the first handshake message is sent when the client determines that the highest protocol version supported by the server meets the protocol version supported by the client; otherwise, it is determined that the failure factor is that the protocol version supported by the server does not meet the requirements of the client.

[0229] Optionally, the first detected end is a server, and the second detected end is a client;

[0230] The first information to be verified is the cipher suite supported by the client;

[0231] The second handshake message is sent by the server after determining that the server supports the cipher suite of the client;

[0232] The processing module 1602 is specifically configured to:

[0233] If the second handshake message is not received, it is determined that the failure factor is that the cipher suite supported by the client does not match the cipher suite supported by the server.

[0234] Optionally, the first information to be verified is a detection end certificate sent by the detection end when simulating the second detected end;

[0235] The second information to be verified is the sent certificate of the first detected end or the sent certificate of the second detected end;

[0236] The second handshake message is sent when the first detected end determines that the detecting end certificate sent by the detecting end matches the detecting end certificate pre-installed by the first detected end;

[0237] The processing module 1602 is specifically configured to:

[0238] If the second handshake message is not received, it is determined that the fault factor is an error in pre-installing the certificate on the first detected end;

[0239] The processing module 1602 is specifically configured to:

[0240] Determine whether the first detected end certificate sent matches the first detected end certificate pre-installed on the detection end, or whether the second detected end certificate sent matches the second detected end certificate pre-installed on the detection end. If they do not match, determine that the fault factor is that the first detected end or the second detected end made an error when sending the certificate.

[0241] Optionally, the first detected end is a client, and the second detected end is a server;

[0242] The first information to be verified is a legitimate detection terminal certificate and an illegal detection terminal certificate sent by the detection terminal when simulating the second detected terminal;

[0243] The second information to be verified is the sent second detected end certificate;

[0244] The processing module 1602 is specifically configured to:

[0245] If the second handshake message for the sent valid certificate of the detection end is not received, determining that the fault is a certificate verification function of the client;

[0246] If a second handshake message for the sent valid certificate of the detection end is received, and a second handshake message for the sent invalid certificate of the detection end is not received, determining that the certificate verification function of the client is normal, and receiving the third handshake message sent by the second detected end;

[0247] The processing module 1602 is specifically configured to:

[0248] Determine whether the sent second detected terminal certificate is legal; if illegal, determine that the fault factor is that the certificate of the second detected terminal is illegal.

[0249] Optionally, the processing module 1602 is further configured to:

[0250] Obtaining a disabled first secure connection SSL parameter of the first detected end, where the first detecting end uses a JDK environment;

[0251] Obtaining a second SSL parameter from a fourth handshake message of the second detected end;

[0252] Determine whether the disabled parameters in the second SSL parameters are consistent with the first SSL parameters; if they are consistent, determine that the failure factor is that the SSL parameters of the second detected end are disabled by the first detected end.

[0253] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0254] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0255] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0256] Although the preferred embodiments of the present invention have been described, those skilled in the art may make additional changes and modifications to these embodiments once they have learned the basic creative concept. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments and all changes and modifications that fall within the scope of the present invention.

[0257] Obviously, those skilled in the art may make various changes and modifications to the present invention without departing from the spirit and scope of the present invention. Thus, if such changes and modifications fall within the scope of the claims and their equivalents, the present invention is intended to include such changes and modifications.

Claims

1. A method for detecting the establishment of a secure connection, characterized in that: The method comprises: The detecting end sends a first handshake message to the first detected end; the first handshake message includes first information to be verified; the first information to be verified is information of the second detected end or information generated when the detecting end simulates the second detected end; the detecting end is used to act as an intermediate agent when a connection failure occurs between the first detected end and the second detected end, check whether the failure is caused by the first detected end or the second detected end, and provide a specific cause of the failure and detailed steps for resolving the failure; The detecting end determines, based on whether the second handshake message from the first detected end is received, whether the first information to be verified is a fault factor causing a failure in establishing a secure connection between the first detected end and the second detected end; The detecting end receives a third handshake message sent by the second detected end, where the third handshake message includes second information to be verified; the second information to be verified is information of the first detected end or information of the second detected end; The detecting end detects the second information to be verified, thereby determining whether the second information to be verified is a fault factor causing failure in establishing a secure connection between the first detected end and the second detected end.

2. The method according to claim 1, wherein The first detected end is a client, and the second detected end is a server; The first information to be verified is the highest protocol version supported by the server; The second information to be verified is the highest protocol version supported by the client; The detecting end detects the second information to be verified, including: If the detection end determines that the highest protocol version supported by the client is lower than the protocol version supported by the server, it determines that the failure factor is that the protocol version supported by the client does not meet the requirements of the server.

3. The method according to claim 1, wherein The first detected end is a server, and the second detected end is a client; The first information to be verified is the cipher suite supported by the client; The second handshake message is sent by the server after determining that the server supports the cipher suite supported by the client; The detecting end determines, based on whether the second handshake message from the first detected end is received, whether the first information to be verified is a fault factor for failure to establish a secure connection between the first detected end and the second detected end, including: If the detection end does not receive the second handshake message, it determines that the failure factor is that the cipher suite supported by the client does not match the cipher suite supported by the server.

4. The method according to claim 1, wherein The first information to be verified is a detection end certificate sent by the detection end when simulating the second detected end; The second information to be verified is the sent certificate of the first detected end or the sent certificate of the second detected end; The second handshake message is sent when the first detected end determines that the detecting end certificate sent by the detecting end matches the detecting end certificate pre-installed by the first detected end; The detecting end determines, based on whether the second handshake message from the first detected end is received, whether the first information to be verified is a fault factor for failure to establish a secure connection between the first detected end and the second detected end, including: If the detecting end does not receive the second handshake message, it determines that the fault factor is an error in pre-installing the certificate on the first detected end; The detecting end detects the second information to be verified, including: The detection end determines whether the first detected end certificate sent matches the first detected end certificate pre-installed in the detection end, or whether the second detected end certificate sent matches the second detected end certificate pre-installed in the detection end. If they do not match, it is determined that the fault factor is that the first detected end or the second detected end made an error when sending the certificate.

5. The method according to claim 1, wherein The first detected end is a client, and the second detected end is a server; The first information to be verified is a legitimate detection terminal certificate and an illegal detection terminal certificate sent by the detection terminal when simulating the second detected terminal; The second information to be verified is the sent second detected end certificate; The detecting end determines, based on whether the second handshake message from the first detected end is received, whether the first information to be verified is a fault factor for failure to establish a secure connection between the first detected end and the second detected end, including: If the detection end does not receive the second handshake message for the sent detection end legal certificate, it is determined that the fault is the certificate verification function of the client; If the detecting end receives the second handshake message for the sent detecting end legal certificate and does not receive the second handshake message for the sent detecting end illegal certificate, it determines that the certificate verification function of the client is normal and receives the third handshake message sent by the second detected end; The detecting end detects the second information to be verified, thereby determining whether the second information to be verified is a fault factor for failure to establish a secure connection between the first detected end and the second detected end, including: The detecting end determines whether the sent certificate of the second detected end is legal. If illegal, it determines that the fault factor is that the certificate of the second detected end is illegal.

6. The method according to any one of claims 1 to 5, characterized in that The method further comprises: The detecting end obtains a first SSL parameter that is disabled by the first detected end, where the first detected end uses a JDK environment; The detecting end obtains a second SSL parameter from a fourth handshake message of the second detected end; The detection end determines whether the disabled parameters in the second SSL parameters are consistent with the first SSL parameters; if they are consistent, it is determined that the failure factor is that the SSL parameters of the second detected end are disabled by the first detected end.

7. A device for detecting establishment of a secure connection, characterized in that: include: A sending module, configured to send a first handshake message to a first detected end; The first handshake message includes first information to be verified; The first information to be verified is information of the second detected end or information generated when the detecting end simulates the second detected end; The detecting end is configured to, when a fault occurs in the connection between the first detected end and the second detected end, act as an intermediate agent to check whether the fault is caused by the first detected end or the second detected end, and provide a specific cause of the fault and detailed steps for resolving the fault; a processing module, configured to determine, based on whether a second handshake message from the first detected end is received, whether the first information to be verified is a fault factor causing a failure in establishing a secure connection between the first detected end and the second detected end; receiving a third handshake message sent by the second detected end, where the third handshake message includes second information to be verified; the second information to be verified is information of the first detected end or information of the second detected end; The second information to be verified is detected to determine whether the second information to be verified is a fault factor for failure in establishing a secure connection between the first detected end and the second detected end.

8. The device according to claim 7, wherein The first detected end is a client, and the second detected end is a server; The first information to be verified is the highest protocol version supported by the server; The second information to be verified is the highest protocol version supported by the client; The processing module is specifically used for: If the detection end determines that the highest protocol version supported by the client is lower than the protocol version supported by the server, it determines that the failure factor is that the protocol version supported by the client does not meet the requirements of the server.

9. A computing device, characterized in that include: a memory for storing program instructions; A processor, configured to call the program instructions stored in the memory and execute the method according to any one of claims 1 to 6 according to the obtained program.

10. A computer-readable non-volatile storage medium, characterized in that: The method comprises computer-readable instructions, and when a computer reads and executes the computer-readable instructions, the computer is caused to perform the method according to any one of claims 1 to 6.

Images