Understanding HTTPS: A Comprehensive Guide

1. The client initiates an HTTPS request, sending a series of supported Cipher Suites (key algorithm suites, abbreviated as Cipher) to the server.

2. The server receives all the Ciphers from the client and compares them with its own supported ones. If there is no match, the connection is terminated; otherwise, it selects one encryption algorithm and a HASH algorithm to return to the client in the form of a certificate. The certificate also contains the public key, issuing authority, website, expiration date, etc.

3. Upon receiving the server’s response, the client performs the following actions:

Verify the legality of the certificate:

Check whether the issuing authority is legitimate and whether it has expired, and whether the website address included in the certificate matches the address being accessed. If the certificate verification passes, a small lock will appear in the browser’s address bar.

Generate a random password:

If the certificate verification passes, or if the user accepts an untrusted certificate, the browser will generate a random number and encrypt it using the public key in the certificate.

HASH handshake information:

Using the initially agreed HASH method, take the HASH value of the handshake message, and then encrypt the “handshake message + handshake message HASH value (signature)” with the random number and send it to the server. The reason for taking the HASH value of the handshake message is mainly to sign the handshake message to verify that it has not been tampered with during transmission.

4. The server receives the ciphertext sent by the client, uses its private key to decrypt the handshake message to retrieve the random password, and then uses the random password to decrypt the handshake message and HASH value, comparing it with the received HASH value to confirm whether they match. It then encrypts a segment of the handshake message (handshake message + HASH value of the handshake message) with the random password and sends it to the client.

5. The client decrypts using the random number and calculates the HASH of the handshake message. If it matches the HASH sent by the server, the handshake process ends. After this, all communication data will be encrypted using the random password generated by the browser and symmetric encryption algorithms, as this key is known only to the client and server. Therefore, even if the request is intercepted, the data cannot be decrypted, ensuring communication security.

Asymmetric encryption algorithms: RSA, DSA/DSS; during the mutual verification process between the client and server, symmetric encryption is used.

Symmetric encryption algorithms: AES, RC4, 3DES; after mutual verification, when using the random number as the key, it is symmetric encryption.

HASH algorithms: MD5, SHA1, SHA256; used to confirm that the handshake message has not been tampered with.

1. Verify whether the certificate is within its validity period.

The certificate returned by the server contains the validity period, which can be verified using the expiration date.

2. Verify whether the certificate has been revoked.

A revoked certificate is invalid. There are two methods to verify revocation: CRL (Certificate Revocation List) and OCSP (Online Certificate Status Protocol).

Once a certificate is revoked, it is recorded in the CRL, which the CA periodically publishes. Applications can rely on the CRL to check if the certificate has been revoked.

The CRL has two drawbacks: it can be very large, making it cumbersome to download. To address this, there is an incremental CRL solution. Secondly, there is a lag; even if the certificate has been revoked, the application can only know after the latest CRL is published.

Incremental CRLs solve some problems but do not completely resolve them. OCSP is an online certificate status checking protocol. Applications send a request according to the standard to query a specific certificate, and the server returns the certificate status.

OCSP can be considered instantaneous (though there may be some delay in actual implementation), thus avoiding the drawbacks of CRL.

3. Verify whether the certificate is issued by a higher-level CA.

Windows retains all trusted root certificates, and browsers can view trusted root certificates, allowing them to verify whether the web server’s certificate is issued by these trusted root certificates or by subordinate certificate authorities of trusted root certificates (the root certificate authority may delegate to intermediate certificate authorities, which then issue intermediate certificates).