Certificate-based SOCKS5 two-way authentication method, apparatus and equipment

Abstract

This application relates to a certificate-based SOCKS5 two-way authentication method, apparatus, and device. The method includes: sending an authentication method request containing a certificate authentication method identifier based on an established transport layer connection; obtaining the certificate authentication method identifier selected by the server; sending an authentication request carrying a user certificate according to the certificate authentication method identifier selected by the server; enabling the server to verify the user certificate; obtaining the server certificate after receiving a response from the server confirming successful verification of the user certificate; performing verification of the server certificate according to the obtained server certificate; and sending an authentication success message after successful verification, thereby establishing a business data transmission channel. This application extends the SOCKS5 protocol, defines a certificate authentication identifier, and achieves strong authentication based on asymmetric cryptography through two-way certificate exchange and verification, replacing traditional cryptography and automatically establishing a secure data transmission channel.

Description

Technical Field

[0001] This application relates to the field of computer network communication technology, and in particular to a certificate-based SOCKS5 two-way authentication method, apparatus and equipment. Background Technology

[0002] SOCKS5, a widely used network proxy protocol, is fundamentally valuable for providing transparent, protocol-independent data forwarding channels for upper-layer applications and supporting various extension mechanisms, including authentication (RFC 1928). The protocol itself defines an authentication method negotiation framework, allowing clients and servers to negotiate a mutually supported authentication method, thus providing flexibility for application scenarios with different security levels. With the escalation of network security threats and increasing compliance requirements, higher demands are being placed on the strength of authentication during proxy connection establishment. Currently, although the protocol supports extending to new authentication methods, widely deployed authentication mechanisms (such as username / password) have inherent limitations at the security level and cannot meet the requirements for credential leakage resistance and bidirectional authentication in high-security scenarios.

[0003] In existing technologies, SOCKS5 authentication is essentially a one-way, secret-based verification process. The server, acting as the verifier, determines access permissions based on the username and password provided by the client. This model has significant security and management flaws: First, the password it relies on, being a static shared secret, is susceptible to leakage during transmission, storage, or management, leading to unauthorized access. Second, the process only achieves one-way identity verification from the server to the client; the client cannot perform any cryptographic verification of the server's true identity. This exposes the communication link to the risk of man-in-the-middle attacks or server impersonation from the outset, potentially allowing the client to send sensitive data to untrusted proxy endpoints, resulting in data leakage. Although the protocol framework allows for extensions, it lacks a standard authentication method that can integrate Public Key Infrastructure (PKI) and achieve strong, peer-to-peer authentication between communicating parties. Therefore, designing an authentication mechanism that can replace traditional cryptography and achieve strong, two-way authentication while fully complying with SOCKS5 protocol extension specifications is a key issue in improving the applicability of SOCKS5 proxies in security-sensitive environments. Summary of the Invention

[0004] Based on this, this application provides a certificate-based SOCKS5 two-way authentication method, characterized by comprising: Based on the established transport layer connection, send an authentication method request containing a certificate authentication method identifier, and obtain the certificate authentication method identifier selected by the server; According to the certificate authentication method identifier selected by the server, an authentication request carrying the user certificate is sent, so that the server verifies the user certificate, and after receiving the server's response that the user certificate has been verified, the server certificate is obtained. Based on the obtained server certificate, perform verification of the server certificate, and send an authentication success message after successful verification to establish a business data transmission channel.

[0005] Optionally, the step of sending an authentication method request containing a certificate authentication method identifier based on the established transport layer connection, and obtaining the certificate authentication method identifier selected by the server, includes: Based on the established transport layer connection, construct and send an authentication method request message containing the certificate authentication method identifier to initiate authentication method negotiation; Receive the authentication method response message from the server, parse it to obtain the certificate authentication method identifier selected by the server, and complete the authentication method negotiation.

[0006] Optionally, the step of sending an authentication request carrying the user certificate according to the certificate authentication method identifier selected by the server, enabling the server to verify the user certificate, and obtaining the server certificate after receiving a response from the server confirming that the user certificate has been verified, includes: Based on the certificate authentication method identifier selected by the server, an authentication request message carrying the user certificate is constructed and sent to trigger the server certificate verification process; Receive the authentication response message from the server, parse it to obtain the server certificate, and complete the server certificate acquisition.

[0007] Optionally, the step of verifying the server certificate based on the obtained server certificate, and sending an authentication success message after successful verification to establish a business data transmission channel includes: Based on the obtained server certificate, perform a certificate verification operation to confirm the legitimacy of the server's identity; After the server certificate verification is successful, an authentication success message is constructed and sent to the server to notify that the authentication is complete; After sending the authentication success message, a business data transmission channel is established, and subsequent data transmission is enabled.

[0008] Optionally, the step of constructing and sending an authentication method request message containing a certificate authentication method identifier based on the established transport layer connection, and initiating authentication method negotiation, includes: Based on the established transport layer connection and the pre-configured certificate authentication method identifier, an authentication method request message containing the certificate authentication method identifier is constructed and sent to the server to announce support for certificate-based two-way authentication capability.

[0009] Optionally, the step of constructing and sending an authentication request message carrying the user certificate based on the certificate authentication method identifier selected by the server, thereby triggering the server-side certificate verification process, includes: Based on the certificate authentication method identifier selected by the server and the stored user certificate, an authentication request message containing the user certificate is constructed and sent, triggering the server to verify the user certificate.

[0010] Optionally, the step of performing a certificate verification operation based on the obtained server certificate to confirm the legitimacy of the server's identity includes: Based on the obtained server certificate and the preset certificate verification logic, a verification operation is performed on the server certificate to confirm the legitimacy of the server identity.

[0011] This application also provides a certificate-based SOCKS5 two-way authentication device, the device comprising: The certificate authentication negotiation module is used to send an authentication method request containing a certificate authentication method identifier based on an established transport layer connection, and to obtain the certificate authentication method identifier selected by the server. The two-way authentication module is used to send an authentication request carrying the user certificate according to the certificate authentication method identifier selected by the server, so that the server can verify the user certificate, and obtain the server certificate after receiving the server's response that the user certificate has been verified. The channel establishment module is used to verify the server certificate based on the obtained server certificate, and send an authentication success message after the verification is successful to establish a business data transmission channel.

[0012] Optionally, the two-way authentication module further includes: The user certificate sending module is used to construct and send an authentication request message carrying the user certificate according to the certificate authentication method identifier selected by the server, so as to trigger the server to verify the user certificate. The server certificate acquisition module is used to receive the authentication response message carrying the server certificate returned by the server, and parse the server certificate from the authentication response message.

[0013] This application also provides an electronic device for implementing the certificate-based SOCKS5 two-way authentication method as described in any one of claims 1 to 7, comprising: The processor is configured to execute a complete two-way authentication process, including sending an authentication method request containing a certificate authentication method identifier based on an established transport layer connection and obtaining the certificate authentication method identifier selected by the server, sending an authentication request carrying the user certificate according to the selected identifier to trigger server verification and obtaining the server certificate, performing verification on the server certificate and sending an authentication success message after successful verification, until a business data transmission channel is established. The memory is used to store the certificate authentication method identifier, user certificate, preset certificate verification logic, authentication request and response messages during the processing, and authentication results necessary to implement the complete two-way authentication process.

[0014] The beneficial effects of this application are as follows: By extending the SOCKS5 protocol authentication method and defining a new certificate authentication identifier, support is declared during the algorithm negotiation phase, achieving seamless integration and smooth upgrade of certificate-based authentication capabilities with the standard protocol framework; by sending the user certificate for server verification first in the authentication process, and then receiving and verifying the server certificate after successful verification, a strict and orderly two-way certificate exchange and verification chain is constructed, achieving strong verification of the identities of both communicating parties based on asymmetric cryptography, completely eliminating the risk of password leakage and data eavesdropping by impersonating the server; and by fully automating the execution of certificate exchange, verification, and success signaling notification, a business data transmission channel is automatically established after successful two-way verification, realizing the establishment of an automated secure tunnel without human intervention throughout the entire process from identity authentication to business communication. Attached Figure Description

[0015] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the accompanying drawings required in the description of the embodiments or the prior art are briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0016] Figure 1 A flowchart illustrating a certificate-based SOCKS5 two-way authentication method according to a specific embodiment of this application is shown. Figure 2 This diagram illustrates a flowchart of a certificate-based SOCKS5 two-way authentication method according to a specific embodiment of this application. Figure 3 This is a device block diagram illustrating a certificate-based SOCKS5 two-way authentication apparatus according to a specific embodiment of this application. Detailed Implementation

[0017] Various exemplary embodiments, features, and aspects of this application will now be described in detail with reference to the accompanying drawings. The same reference numerals in the drawings denote elements that have the same or similar functions. Although various aspects of the embodiments are shown in the drawings, they are not necessarily drawn to scale unless specifically indicated otherwise.

[0018] The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of this application, "multiple" means two or more, unless otherwise explicitly specified.

[0019] The term “exemplary” as used herein means “serving as an example, embodiment, or illustration.” Any embodiment illustrated herein as “exemplary” is not necessarily to be construed as superior to or better than other embodiments.

[0020] Furthermore, to better illustrate this application, numerous specific details are provided in the following detailed embodiments. Those skilled in the art should understand that this application can be implemented without certain specific details. In some instances, methods, means, components, and circuits well-known to those skilled in the art have not been described in detail in order to highlight the main points of this application.

[0021] This application proposes a certificate-based SOCKS5 two-way authentication method to address the risks of password leakage, high management costs, and data leakage due to the single authentication method (only supporting username / password) and single authentication direction (only server authenticating client) in the traditional SOCKS5 protocol. The core of this application lies in the innovative extension of the standard SOCKS5 protocol. Within the existing authentication method framework, a new authentication method identifier is defined and introduced to declare support for a two-way authentication mechanism based on X.509 digital certificates. To this end, a strictly ordered interaction process is designed. During the algorithm negotiation phase after the TCP transport layer connection is established, the client carries the new authentication method identifier in its request. After the server confirms the selection of this method, the two-way authentication sub-process is triggered. This process first involves the client sending its user certificate to the server, and the server verifying the validity of the certificate. Only after successful verification will the server send its server certificate to the client for verification. After both parties successfully verify each other's certificates, the client sends an authentication success message, and only then is a secure data transmission channel established. This method abandons fragile cryptographic credentials and leverages the strength of Public Key Infrastructure (PKI) to achieve strong two-way authentication. This not only significantly improves the security of the connection establishment process, preventing man-in-the-middle attacks and password theft, but also reduces operational complexity by eliminating the need for password management. While fully complying with the SOCKS5 protocol extension specifications, this application achieves a qualitative leap in authentication security with minimal protocol overhead and compatibility costs, providing crucial technical support for the application of SOCKS5 proxies in high-security scenarios such as finance and government.

[0022] Example 1 like Figure 1 The diagram shown is a flowchart of a certificate-based SOCKS5 two-way authentication method according to an embodiment of this application. The method specifically includes the following: S100: Based on the established transport layer connection, send an authentication method request containing a certificate authentication method identifier, and obtain the certificate authentication method identifier selected by the server.

[0023] Specifically, step S100 is the initialization and negotiation phase of the authentication process, the core of which lies in the extension and adaptation of the standard SOCKS5 protocol authentication framework. After successfully establishing a transport layer connection based on protocols such as TCP, the client does not immediately exchange identity credentials, but first negotiates authentication capabilities. The client constructs an authentication method request message based on the new authentication methods defined and supported by this scheme. The key to this message is that its list of authentication methods includes a newly added, certificate-specific unique identifier. This identifier is defined in the unused identifier space reserved by the protocol, explicitly declaring that the client supports the subsequent two-way authentication process based on X.509 certificates. This request message is sent to the peer. Upon receiving the request, the peer (server) searches its own set of supported authentication methods. When it identifies the newly added identifier, it confirms that both parties support this certificate authentication method and selects that method. Subsequently, the peer returns the selected certificate authentication method identifier to the initiator through an authentication method response message. At this point, both parties have reached an agreement at the protocol level that this connection will adopt a certificate-based two-way authentication method, completing the extension of the standard protocol handshake phase. This lays a clear protocol foundation for the subsequent execution of specific certificate exchange and verification processes, ensuring the compatibility and smooth transition of the entire process with the SOCKS5 protocol architecture.

[0024] S200: Based on the certificate authentication method identifier selected by the server, an authentication request carrying the user certificate is sent, so that the server verifies the user certificate, and after receiving the server's response that the user certificate has been verified, the server certificate is obtained.

[0025] Specifically, step S200 is the core execution phase of the two-way authentication mechanism, realizing the transformation from traditional one-way password verification to two-way strong identity verification based on asymmetric cryptography. After negotiating and determining the certificate authentication method in step S100, the client immediately initiates the substantive identity verification process. Based on the negotiated certificate authentication method identifier, the client constructs an authentication request message. The payload of this message is no longer the traditional username and password combination, but includes a user certificate in X.509 format that identifies the client. This certificate is issued by a trusted certificate authority and contains the client's public key, identity information, and digital signature. This authentication request message is sent to the peer (server). Upon receiving the message, the peer extracts the user certificate and performs strict certificate verification operations, including but not limited to verifying the trustworthiness of the certificate chain, checking the certificate's validity period, and confirming that the certificate has not been revoked. Only when the peer successfully completes all verifications of the user certificate and confirms the client's legitimate identity will the process continue. Subsequently, the peer constructs an authentication response message, the payload of which is the peer's own server certificate in X.509 format. This response message is sent back to the entity that initiated the authentication. By receiving this message, the entity obtains the server certificate from the other party. This orderly process design of "client certificate sent and verified first, server certificate returned subsequently" constitutes a strict two-way authentication chain, ensuring that neither party exposes more information or establishes trust before verifying the other party's identity. From a process mechanism perspective, it effectively prevents man-in-the-middle attacks and the risk of server impersonation under one-way authentication.

[0026] S300: Based on the obtained server certificate, perform verification of the server certificate, and send an authentication success message after successful verification to establish a business data transmission channel.

[0027] Specifically, step S300 is the final verification and business channel establishment stage of the authentication process, completing the closed loop of two-way verification and automating the construction of a secure communication tunnel. After successfully obtaining the server certificate returned by the peer (server) in step S200, the client must fulfill its responsibilities as the verifier. The client immediately performs a complete verification operation on the obtained server certificate. The logic and strength of this verification are consistent with the server's verification of the user certificate, relying on the same PKI trust system and verification rules to ensure the authenticity, validity, and matching of the certificate itself with the current connection intent. Only when the verification of the server certificate is successful, indicating that both parties' identities have been confirmed as legitimate, does the client construct an authentication success message and send it to the peer. This message serves as a clear signaling, declaring the entire two-way certificate authentication process successfully completed. Subsequently, based on the established strong mutual trust, both parties automatically trigger the full readiness of the business data transmission channel. From this point onward, all subsequent application layer business data can be securely transmitted over this established transport layer connection. This process, from certificate verification to channel establishment, is fully automated and requires no manual intervention. It achieves high-strength two-way identity authentication while ensuring efficient connection establishment, forming a seamless connection from identity authentication to secure communication.

[0028] In summary, this application addresses the security and functional deficiencies of the traditional SOCKS5 protocol authentication mechanism by proposing a two-way authentication method based on X.509 digital certificates. First, this application innovatively extends the authentication framework of the standard SOCKS5 protocol by defining a dedicated authentication method identifier. By declaring and selecting this identifier during the algorithm negotiation phase, SOCKS5 clients and servers can explicitly enable subsequent certificate-based authentication processes while maintaining compatibility with the standard protocol. This solves the problem of traditional protocol authentication methods being singular and unable to directly support strong cryptographic credentials, achieving a secure upgrade and smooth transition of the authentication mechanism. Second, this application designs a rigorous and orderly two-way certificate exchange and verification process. During the authentication phase, the client first sends its user certificate for the server to verify. After successful verification, the server returns its server certificate to the client for verification. This "client-first, server-later" certificate exchange order, combined with rigorous verification of the certificate chain, validity period, and revocation status, constitutes a complete two-way strong identity verification based on Public Key Infrastructure (PKI). This fundamentally solves the security and management deficiencies of traditional username / password authentication, effectively preventing password leakage, identity spoofing, and man-in-the-middle attacks, and ensuring reliable verification of the identities of both communicating parties. Finally, this application automates the entire authentication and communication establishment process. After both parties' certificates are verified, an authentication success signal is automatically sent, and the business data transmission channel becomes immediately available. The entire process, from negotiation, certificate exchange, two-way verification to channel establishment, requires no manual intervention. This significantly improves connection security while ensuring efficient connection establishment, forming a secure, efficient, and automated method for network proxy authentication and channel establishment.

[0029] As an optional implementation of this application, optionally, in step S100, based on the established transport layer connection, an authentication method request containing a certificate authentication method identifier is sent, and the certificate authentication method identifier selected by the server is obtained, including: 110. Based on the established transport layer connection, construct and send an authentication method request message containing the certificate authentication method identifier to initiate authentication method negotiation.

[0030] Specifically, after a successful transport layer connection is established, the client immediately initiates the SOCKS5 authentication negotiation process, such as... Figure 2As shown, this step corresponds to the "Authentication Method Request" stage in the flowchart, marking the formal start of the authentication process. The client needs to construct an authentication method request message conforming to the SOCKS5 protocol specification. The body of this message is a list of methods used to announce to the peer (server) all authentication methods supported by the client. The core extension of this application is that this list must include a specific, newly defined authentication method identifier. This identifier takes a value within the space reserved by the SOCKS5 protocol but not allocated by the standard, such as a value in the range of 0x80-0xFE, to uniquely identify the certificate-based two-way authentication method to be used subsequently. Specifically, this identifier acts like a key for the protocol extension. When the server recognizes this key, it knows that the client supports the new process defined in this scheme. In implementation, the client constructs and sends an authentication method request message containing the certificate authentication method identifier based on the established transport layer connection and the pre-configured certificate authentication method identifier, announcing to the server that it supports certificate-based two-way authentication capabilities. This is not simply a matter of filling in the list with identifiers; rather, it requires ensuring that the entire request message (including the version number, number of methods, and method list) is formatted correctly so that the server can parse it accurately. Once the message is constructed, the client sends it to the server through the established connection to formally initiate authentication method negotiation.

[0031] 120. Receive the authentication method response message from the server, parse it to obtain the certificate authentication method identifier selected by the server, and complete the authentication method negotiation.

[0032] Specifically, after sending an authentication method request, the client will wait for and receive a response from the server to confirm the authentication method mutually selected by both parties, such as... Figure 2As shown, this step corresponds to the "Authentication Method Response" stage in the flowchart, which is the closed loop of the negotiation process. The client reads the authentication method response message returned by the server from the network socket. According to the SOCKS5 protocol, this response message has a fixed structure, containing the protocol version number and the method identifier selected by the server. The client first verifies the correctness of the protocol version number, and then parses out the method identifier selected by the server. Specifically, after receiving the list of supported methods sent by the client, the server iterates through the methods it supports and selects a method that both parties support. If the server also supports the defined certificate authentication method, it will return that specific identifier in the response. For example, if the list sent by the client contains [0x00, 0x02, 0x80] (representing no authentication, username / password authentication, and certificate authentication of this scheme, respectively), and the server supports and selects certificate authentication, then the selected method field in the response message will be 0x80. The client obtains this identifier by parsing it and compares it with its own pre-configured certificate authentication method identifier. If the match is successful, it confirms that both parties have reached an agreement on using a certificate-based two-way authentication method, and the authentication method negotiation phase is completed. If the identifier does not match, it may fall back to other authentication methods or terminate the connection directly.

[0033] As an optional implementation of this application, optionally, in step S200, an authentication request carrying the user certificate is sent according to the certificate authentication method identifier selected by the server, so that the server verifies the user certificate, and after receiving the server's response that the user certificate has been verified, the server certificate is obtained, including: 210. Based on the certificate authentication method identifier selected by the server, construct an authentication request message carrying the user certificate and send it to trigger the server certificate verification process.

[0034] Specifically, after negotiating the authentication method and confirming the use of certificate authentication, the client enters the first stage of two-way authentication, proving its identity to the server, such as... Figure 2As shown, this step corresponds to the "Authentication Request (Client Sends User Certificate)" stage in the flowchart. The client needs to construct an "Authentication Request" message. Unlike the standard SOCKS5 "Username / Password" sub-negotiation message structure, the payload of the authentication request message defined in this application is the client's X.509 format user certificate. This certificate contains the client's public key, identity information (such as common name CN, organization O, etc.), and a digital signature issued by a Certificate Authority (CA). Based on the certificate authentication method identifier and stored user certificate selected by the server, an authentication request message containing the user certificate is constructed and sent, triggering the server to verify the user certificate. When constructing the message, not only should the binary DER encoding of the certificate be used as the payload, but information such as the length should also be explicitly specified in the message header to ensure that the server can correctly parse it. After receiving this message, the server will initiate its verification logic. The sending action in step 210 is the initiation of one-way authentication (client authenticating to server), and it is also a necessary condition for triggering the server to subsequently send its own certificate. This "client certificate first" order is one of the key designs for implementing strict two-way verification in this application, ensuring that the client's identity has been preliminarily confirmed before the server exposes its own identity credentials.

[0035] 220. Receive the authentication response message from the server, parse it to obtain the server certificate, and complete the server certificate acquisition.

[0036] Specifically, after sending its own certificate, the client enters a waiting state, preparing to receive the server's verification result of its identity and the server's own identity credentials, such as... Figure 2 As shown, this step corresponds to the "Authentication Response (Server Certificate)" stage in the flowchart. The client reads the authentication response message sent back by the server from the network connection. The composition of this message depends on the server's verification result of the user's certificate. After receiving the client's certificate, the server performs a series of strict verification operations, including verifying the certificate chain (whether it was issued by a trusted CA), checking the certificate's validity (whether it is within its validity period, whether it has been revoked CRL / OCSP), and verifying whether the identity information in the certificate conforms to the access policy. Only when all verifications pass will the server construct this authentication response message and return its own X.509 server certificate as the message payload. If verification fails, the server will return an error response and terminate the connection. After receiving the response, the client needs to parse the message. The parsing process includes reading the message header, confirming that the message type is an authentication response, and then extracting the binary data of the server certificate. Obtaining the server certificate signifies the confirmation of the result of the "Server Authentication Client" stage (executed by the server) in the two-way authentication process, and the readiness of the input required for the "Client Authentication Server" stage (executed by the client). At this point, the client has successfully obtained the other party's identity credentials, creating the conditions for executing the final verification loop.

[0037] As an optional implementation of this application, optionally, in step S300, based on the obtained server certificate, verification of the server certificate is performed, and an authentication success message is sent after successful verification to establish a business data transmission channel, including: 310. Based on the obtained server certificate, perform a certificate verification operation to confirm the legitimacy of the server's identity.

[0038] Specifically, after successfully resolving the server certificate, the client must fulfill its responsibility as the verifier and perform strong authentication of the server's identity to achieve true "two-way" authentication, such as... Figure 2 As shown, this step corresponds to the "Client verifies server certificate" stage in the flowchart. The client needs to perform a certificate verification operation that is just as rigorous as the server's verification of the client certificate, but with the opposite verification object. This includes several core sub-steps: First, verify the integrity and authenticity of the certificate itself, i.e., check whether its digital signature is valid. This requires obtaining the CA root certificate or intermediate certificate that issued the server certificate and verifying the signature using its public key. Second, verify the validity period of the certificate to ensure that it has not expired and is not before its effective date. Third, confirm that the certificate has not been revoked by the issuing authority by querying the Certificate Revocation List (CRL) or Online Certificate Status Protocol (OCSP) response. Finally, it can also verify whether the subject information (such as the domain name) in the certificate matches the expected target server according to local policies. Based on the obtained server certificate and the preset certificate verification logic, the verification operation of the server certificate is performed to confirm the legitimacy of the server's identity. This verification process relies on the trust chain of the entire Public Key Infrastructure (PKI). The server's identity is only confirmed as legitimate when the server certificate is issued by a CA trusted by the client and passes all verification checks. Successful execution of step 310 fundamentally solves the security vulnerability of the traditional SOCKS5 protocol where the client cannot verify the server's identity. It effectively resists man-in-the-middle attacks and the risk of data eavesdropping by impersonating the server. It is the final link in achieving two-way trust and the ultimate guarantee of the security of the entire authentication process.

[0039] 320. After the server certificate verification is successful, construct an authentication success message and send it to the server to notify that the authentication is complete.

[0040] Specifically, once the client successfully verifies the server's certificate, all technical steps of the two-way authentication process are complete, and the identities of both parties are mutually confirmed. At this point, according to the protocol specifications, a clear success signal needs to be sent to the server to formally end the authentication sub-process, such as... Figure 2As shown, this step corresponds to the "Authentication Successful" stage in the flowchart. The client constructs a short authentication success message. According to the SOCKS5 protocol's sub-negotiation specification, this message typically contains a status byte indicating success (e.g., 0x00). Sending this message serves a dual purpose: firstly, as a protocol-level confirmation, it informs the server that the client-side verification has also passed, and the entire two-way authentication process has been successfully completed; secondly, as a synchronization mechanism, it ensures that both parties are in the same cognitive state, that is, both believe that identity authentication has been passed and that business data can be securely transmitted. The client must adhere to the protocol format when constructing this message to ensure its accuracy. Subsequently, the message is sent to the server through the established transport layer connection. The completion of step 320, from the perspective of protocol interaction, marks the end of the complex secure handshake process from connection establishment and method negotiation to two-way certificate verification, clearing the final protocol obstacle for the subsequent unimpeded transmission of actual application data, and realizing the state switch from the "identity authentication stage" to the "data transmission stage."

[0041] 330. After sending the authentication success message, establish a business data transmission channel and enable subsequent data transmission.

[0042] Specifically, after successful authentication and signaling exchange, the two parties have established strong identity trust based on digital certificates. At this point, the connection is ready to carry actual application data, such as... Figure 2 As shown, this step corresponds to the "Transmitting Business Layer Data" stage in the flowchart. Establishing a business data transmission channel does not mean re-establishing a physical or logical connection, but rather removing the blocking or restriction on application layer data transmission and reception on top of an existing transport layer (such as TCP) connection, allowing it to enter a normal working state. In implementation, after completing all authentication steps, the SOCKS5 protocol stack on both the client and server sides will switch its internal state machine to the "authenticated / transferable" state. This state switch means that the protocol processing layer will no longer intercept or parse subsequent data packets as authentication messages, but will transparently pass them to the upper-layer SOCKS5 proxy logic or forward them directly. From this point on, any data sent and received through this connection will be considered protected business data. For example, HTTP requests sent by a browser through this SOCKS5 proxy connection, or graphical data sent by a remote desktop client, will begin to flow freely at this moment. Step 330 is the ultimate goal and value embodiment of the entire authentication method, transforming all the complex security handshake results of the preceding steps into a simple, reliable, and highly secure data transmission pipeline. The channel established through this application not only possesses the original functions of a SOCKS5 proxy, but also, due to its underlying two-way certificate authentication, has the ability to resist identity spoofing and man-in-the-middle attacks, providing a solid foundation for the transmission of sensitive data.

[0043] Example 2 Based on the same principle as the aforementioned method, a certificate-based SOCKS5 two-way authentication device is also proposed, see [link to relevant documentation]. Figure 3 The certificate-based SOCKS5 two-way authentication device 100 of this disclosure includes: The certificate authentication negotiation module 110 is used to send an authentication method request containing a certificate authentication method identifier based on an established transport layer connection, and to obtain the certificate authentication method identifier selected by the server. The two-way authentication module 120 is used to send an authentication request carrying the user certificate according to the certificate authentication method identifier selected by the server, so that the server verifies the user certificate, and obtains the server certificate after receiving the server's response that the user certificate has been verified. The channel establishment module 130 is used to verify the server certificate based on the obtained server certificate, and send an authentication success message after the verification is successful to establish a business data transmission channel.

[0044] As an optional implementation of this application, the two-way authentication module 120 may further include: User certificate sending module 121 is used to construct and send an authentication request message carrying the user certificate according to the certificate authentication method identifier selected by the server, so as to trigger the server to verify the user certificate. The server certificate acquisition module 122 is used to receive an authentication response message carrying the server certificate returned by the server, and parse the server certificate from the authentication response message.

[0045] Obviously, those skilled in the art should understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the control methods described above. The modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Therefore, this application is not limited to any specific hardware and software combination.

[0046] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the control methods described above. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0047] Example 3 Furthermore, an electronic device for implementing any of the described certificate-based SOCKS5 two-way authentication methods includes: The processor is configured to execute a complete two-way authentication process, including sending an authentication method request containing a certificate authentication method identifier based on an established transport layer connection and obtaining the certificate authentication method identifier selected by the server, sending an authentication request carrying the user certificate according to the selected identifier to trigger server verification and obtaining the server certificate, performing verification on the server certificate and sending an authentication success message after successful verification, until a business data transmission channel is established. The memory is used to store the certificate authentication method identifier, user certificate, preset certificate verification logic, authentication request and response messages during the processing, and authentication results necessary to implement the complete two-way authentication process.

[0048] The electronic device of this disclosure includes a processor and a memory for storing processor-executable instructions. The processor is configured to implement any of the certificate-based SOCKS5 two-way authentication methods described above when executing the executable instructions.

[0049] It should be noted that the number of processors can be one or more. Furthermore, the electronic device in this embodiment may also include input devices and output devices. The processor, memory, input devices, and output devices can be connected via a bus or other means, without specific limitations herein.

[0050] The memory, serving as a computer-readable storage medium for automated fault handling and self-learning methods in modules, can be used to store software programs, computer-executable programs, and various modules, such as the program or module corresponding to the certificate-based SOCKS5 two-way authentication method in this disclosure. The processor executes various functional applications and data processing of the electronic device by running the software programs or modules stored in the memory.

[0051] The various embodiments of this application have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A certificate-based SOCKS5 two-way authentication method, characterized in that, include: Based on the established transport layer connection, send an authentication method request containing a certificate authentication method identifier, and obtain the certificate authentication method identifier selected by the server; The certificate authentication method identifier is taken from the space reserved by the SOCKS5 protocol that has not been allocated by the standard, and is used to uniquely identify the certificate-based two-way authentication method to be used subsequently. Based on the certificate authentication method identifier selected by the server, an authentication request carrying the user certificate is sent, enabling the server to verify the user certificate. Upon receiving a response from the server confirming successful verification of the user certificate, the server certificate is obtained, including: Based on the certificate authentication method identifier selected by the server, an authentication request message carrying the user certificate is constructed and sent to trigger the server certificate verification process; Specifically, constructing and sending an authentication request message carrying the user certificate to trigger the server-side certificate verification process includes: Based on the certificate authentication method identifier selected by the server and the stored user certificate, construct an authentication request message containing the user certificate and send it to trigger the server to verify the user certificate; Receive the authentication response message from the server, parse it to obtain the server certificate, and complete the server certificate acquisition. The authentication response message is returned by the server after verifying the user certificate, and the authentication response message carries the server certificate. Based on the obtained server certificate, perform verification of the server certificate, and send an authentication success message after successful verification to establish a business data transmission channel; The step of performing the verification of the server certificate includes verifying whether the subject information in the certificate matches the expected target server for connection according to the local policy. The authentication success message is sent by the client constructing the authentication success message and sending it to the server to notify that authentication is complete.

2. The certificate-based SOCKS5 two-way authentication method as described in claim 1, characterized in that, The step of sending an authentication method request containing a certificate authentication method identifier based on the established transport layer connection, and obtaining the certificate authentication method identifier selected by the server, includes: Based on the established transport layer connection, construct and send an authentication method request message containing the certificate authentication method identifier to initiate authentication method negotiation; Receive the authentication method response message from the server, parse it to obtain the certificate authentication method identifier selected by the server, and complete the authentication method negotiation.

3. The certificate-based SOCKS5 two-way authentication method as described in claim 1, characterized in that, The step of verifying the server certificate based on the obtained server certificate, and sending an authentication success message after successful verification to establish a business data transmission channel includes: Based on the obtained server certificate, perform a certificate verification operation to confirm the legitimacy of the server's identity; After the server certificate verification is successful, an authentication success message is constructed and sent to the server to notify that the authentication is complete; After sending the authentication success message, a business data transmission channel is established, and subsequent data transmission is enabled.

4. The certificate-based SOCKS5 two-way authentication method as described in claim 2, characterized in that, The process of constructing and sending an authentication method request message containing a certificate authentication method identifier based on the established transport layer connection to initiate authentication method negotiation includes: Based on the established transport layer connection and the pre-configured certificate authentication method identifier, an authentication method request message containing the certificate authentication method identifier is constructed and sent to the server to announce support for certificate-based two-way authentication capability.

5. The certificate-based SOCKS5 two-way authentication method as described in claim 3, characterized in that, The step of performing a certificate verification operation based on the obtained server certificate to confirm the legitimacy of the server's identity includes: Based on the obtained server certificate and the preset certificate verification logic, a verification operation is performed on the server certificate to confirm the legitimacy of the server identity.

6. An electronic device for implementing the certificate-based SOCKS5 two-way authentication method as described in any one of claims 1 to 5, comprising: The processor is configured to execute a complete two-way authentication process, including sending an authentication method request containing a certificate authentication method identifier based on an established transport layer connection and obtaining the certificate authentication method identifier selected by the server, sending an authentication request carrying the user certificate according to the selected identifier to trigger server verification and obtaining the server certificate, performing verification on the server certificate and sending an authentication success message after successful verification, until a business data transmission channel is established. The memory is used to store the certificate authentication method identifier, user certificate, preset certificate verification logic, authentication request and response messages during the processing, and authentication results necessary to implement the complete two-way authentication process.

Images