HTTPS authentication process:

• ① The browser sends a connection request to the secure server.

• ② The server sends its certificate and certificate-related information to the client browser.

• ③ The client browser checks whether the certificate sent by the server is issued by a trusted CA (Certificate Authority). If it is, the protocol continues execution; if not, the client browser gives the user a warning message: warning that this certificate is not trustworthy and asking whether the user wants to continue.

• ④ Next, the client browser compares the information in the certificate, such as domain name and public key, with the relevant information just sent by the server. If they match, the client browser recognizes the server’s legal identity.

• ⑤ The server requests the client to send its own certificate. After receiving it, the server verifies the client’s certificate. If it fails verification, the connection is refused; if it passes verification, the server obtains the user’s public key.

• ⑥ The client browser informs the server of the symmetric encryption methods it supports.

• ⑦ The server selects the encryption method with the highest level of encryption from the methods sent by the client, encrypts it with the client’s public key, and notifies the browser.

• ⑧ The browser selects a session key for this encryption method, encrypts it with the server’s public key, and sends it to the server.

• ⑨ The server receives the message sent by the browser, decrypts it with its own private key, and obtains the session key.

• ⑩ The subsequent communication between the server and browser uses the symmetric encryption method, and the symmetric key is encrypted.

The above describes the specific communication process of two-way authentication SSL protocol, which requires certificates from both the server and user. One-way authentication SSL protocol does not require the client to have a CA certificate. Compared to the steps above, it only needs to remove the process of server-side verification of the client certificate, and when negotiating the symmetric encryption method and session key, the server sends the unencrypted encryption method to the client (this does not affect the security of the SSL process). This way, the specific communication content between both parties is encrypted data. If a third party attacks and obtains the data, they only get encrypted information. For the third party to obtain useful information, they need to decrypt the encrypted data, and at this point, security depends on the security of the encryption method. Fortunately, the current encryption methods are sufficiently secure as long as the communication key is long enough. This is why we emphasize the requirement to use 128-bit encrypted communication.