The purpose of HTTPS is to ensure the communication security between the client and the server. Actually, HTTPS is the HTTP protocol that works on SSL. The SSL handshake protocol consists of four phases:
Phase one: Build security capabilities
It is initiated by the Client and sends a Client Hello message to the server, which contains the SSL version, Client random number (used to generate the key), session number, list of encryption algorithms, and list of compression algorithms.
The Server returns a Server Hello message containing the SSL version, the Server random number (used to generate the key), the session number, the selected encryption algorithm, and the selected compression algorithm.
The idea is to greet each other first and tell each other who they are and what they do.
Phase 2: Server authentication and key exchange
At this stage, the server is the only sender. There are three steps:
Step 1: certificate. The server sends the server digital certificate and the whole CA certificate chain to the client, and the client obtains the server public key. In this step the client can choose whether to verify the server can be trusted, not validation is equivalent to skip the certificate validation of this step, to communicate directly, the premise is the server support, good so HTTPS will lose its original security role, so still need to verify, if untrusted clients can stop the connection, and remind users;
Step 2: Certificate request. The server requests a digital certificate from the client. Client authentication is optional in SSL, so this step is also optional.
Step 3: The server handshake is complete. After sending the message, the server waits for the client to respond.
Phase 3: Client authentication and key exchange
In this stage, the client is the only sender of the message, which consists of three steps.
Step 1: certificate. The client sends the client digital certificate to the server, which contains the client’s public key. Normally this certificate should be distributed to the client by the service provider and issued by the specified CA so that the server can verify the validity of the client certificate and decide whether to continue.
Step 2: key exchange. The client generates a “pre-master password”, encrypts it with the server’s public key, and sends it to the server. This encrypted “pre-master password” is known only to the client and server, and is related to the symmetric key that follows the symmetric encryption. This step also indirectly validates the server, which must have the private key corresponding to the certificate to decrypt the pre-master password.
Step 3: Certificate authentication, the client also need to server validation is a true client (digital certificate to prove the client has legitimate public key, but cannot prove that it is the client, with the public key corresponding private key is the key), so the client has encryption “master password” beforehand, the client containing random number and your signature certificate, sent to the server. The server verifies the validity of the CA, the validity of the random number, etc. If it passes, the server will unlock the encrypted “pre-master password” with its own private key, and then perform a series of steps to generate the master communication password. (The client obtains the master communication password in the same way as the server.)
Stage 4: Completion
At this stage, the client and server independently generate the same master communication password, known as a symmetric key.
After the SSL handshake, the client and server enter the session phase. The symmetric keys generated in the handshake protocol are used for encryption and decryption to ensure communication security.
To sum up, the following keys and certificates are required to complete HTTPS bidirectional authentication:
Server: 1. Private key of the server. 2. A digital certificate containing the server public key issued by the CA. 3. The CA digital certificate. In the practice of two-way authentication, usually the server can act as the certificate authority itself and the server CA issues both the server certificate and the client certificate.
Client: 1. The private key of the client is obtained through the digital certificate and CA certificate of the server. 2. A digital certificate containing the client public key issued by the CA. To avoid man-in-the-middle attacks, clients also need built-in server certificates that verify that the server they connect to is the specified server.