HTTPS is the SSL/TLS protocol added on the basis of HTTP, as can be seen from its name. Therefore, if you understand SSL/TLS, you will understand the core of HTTPS
SSL/TLS
SSL/TLS (Secure Socket Layer) is located between the application Layer and TCP/IP Layer. SSL was the original name before an organization acquired the protocol
SSL/TLS is a set of complex protocols to ensure communication security. The communication parties using Http only need to establish TCP link before they can communicate directly, while the communication parties using SSL/TLS need to establish SSL link before they communicate, as shown below
TCL Links –>SSL links –> Communication
The general workflow for SSL/TLS looks like this:
The client requests the public key from the server and verifies that the two sides negotiate to generate the reply key (session Id) for communication
The first two steps, called handsshake, are asymmetric encryption stages in HTTPS communication, and the subsequent communication is symmetric encryption with the session key.
Because asymmetric encryption uses complex mathematical principles, if every communication is encrypted with asymmetric encryption, it will seriously affect the performance of network communication. In addition, SSL has a complex design to ensure that the generated session key is only known by the communication parties that establish SSL links. Therefore, symmetric encrypted communication with the session key in subsequent communication is actually secure
The detailed process of handsshake
There are four communications in the handshake phase, all in clear text
1. The client sends an encrypted communication request to the server. This request is called ClientHello
A random number x, which is used for subsequent production of session keys Encryption algorithm supported by the client Compression mode supported by the SSL protocol version supported by the client
2. After receiving the request, the server responds to the request, called ServerHello, and returns the following data
Confirm the supported SSL protocol version Confirm the encryption algorithm Server public key. For data security, a random number Y is added to the certificate for subsequent production of session keys
3. After receiving the response from the server, the client verifies the validity of the certificate (whether the certificate is issued by an authentication authority and whether the certificate is within the validity period). After the verification succeeds, the client extracts the public key from the certificate and sends the following data to the server
A random number Z is used for subsequent production of the session key. Note that this random number encrypts a notification with the public key, telling the server that the subsequent communication uses the agreed encryption mode and the session key to send a notification, telling the server that the client ends the handshake
When this process is complete, the client has three random numbers, which are then used in conjunction with the asymmetric encryption algorithm to generate a session key
4. After receiving the last random number, the server uses the private key to decrypt it and has the same three random numbers as the client, and then generates the same random numbers as the clientThe session key“And make a final response
A notification, telling the client that subsequent communications are notified using an agreed encryption mode and session key, telling the client that the server ends the handshake
After the four times of communication, the client and server each have the same session key and no longer need to transmit the notification object. Therefore, the subsequent communication can be carried out by symmetric encryption with the session key.
I drew a picture just to make sense of it
