1. HTTPS is not a protocol, but a structure of the standard HTTP protocol mounted on the SSL/TLS protocol. (An inappropriate statement can be considered as the superposition of the two Protocols ). HTTP is the top Layer of the OSI7 model, that is, Layer 7th: Application Layer. SSL/TLS works at Layer 4th: Transport Layer. The two layers are separated by the Presentation Layer (Layer 6) and Session Layer (Layer 5.
2. Due to TCP/IP-based communication requirements, HTTPS must expose the IP and Port, that is, this part is not in the scope of encryption. Therefore, a third party can intercept network packet data and other means to know which site the user is communicating with. Of course, the information behind the context is encrypted in addition to the data of www.domain.com: port.
3. The core of encrypted links is the handshake process of SSL/TLS, which is more complex than the three handshakes of TCP connections. Refer to the process commit described in wikipedia:
4. From the above process, we can summarize the process of establishing this secure link:
The client and server communicate with each other to ensure security. Therefore, the communication messages must be encrypted, that is, encrypted data is transmitted over the network. In order to facilitate the recipient to obtain real messages, the symmetric encryption algorithm is used. Therefore, the security of this encryption depends on the strength of the key and the selected symmetric encryption algorithm. But what keys and symmetric encryption algorithms are used? The client and server do not know each other. How can we understand what these two things use? So we have to negotiate between the client and the server!
The client sends A ClientHello message to the server, which includes the maximum TLS version supported by the client, A random number A, A set of encryption algorithms supported by the client, and A set of compression algorithms supported by the client. After receiving a ClientHello, the server compares the highest TLS version supported by the server with the highest version sent by the client. The two versions are Max, marked as max_TLS_version. The server generates a random number B by itself, and selects a specific encryption algorithm M from the encryption algorithm set passed by the client. (Note that the M here is also a set, including: asymmetric encryption algorithms are used to encrypt the pre-master secret, for example, the RSA algorithm and symmetric encryption algorithm are used for data transmission to encrypt their own content. The MAC algorithm is used to verify whether information is tampered with, and the pseudo-random algorithm is used to generate final communication. key master secret required by symmetric encryption algorithms ), select a specific compression algorithm N from the compression algorithm set. Then, send a ServerHello response to the client. This ServerHello includes the max_TLS_version/B/M/N mentioned above.
Note that the information between the client and the server is symmetric. Because both parties have negotiated all the algorithms that may be involved in the entire handshake process.
The server sends a third-party certificate to the client, telling him that your brother is licensed and you can take my certificate for investigation. The client took the certificate from the server and ran to the relevant authority for verification... (The CA certificate authentication content involved in these two steps is huge. I will not describe it here. I will focus on TLS handshake first)
If the above certificate is verified, it means that the client believes the certificate sent by the server, and the client agrees to start communication with the public key sent by the server. Note that the asymmetric encryption process starts here. The client generates a pre-master secret (usually a random number) P, uses the public key provided by the server to encrypt P and generates P', and sends it to the server.
After the server receives P', it uses its own private key to decrypt and restore P. Note that the biggest difference between P and A is encrypted transmission. Theoretically, if the server does not disclose its private key, only the server can restore P from P. So. Now, the client and server have the master secret required for symmetric encryption during communication between the two sides: both parties have A definite pseudo-random function and three random numbers A, B, and P that are known to each other.
Therefore, the two sides, on their own side, generate a master secret through a common pseudo-random number and a common material. Now, the negotiation process between the two parties is almost over. This is because the original intention of the negotiation is completely consistent. In retrospect, the whole process is not to let everyone know what symmetric encryption algorithm is used and what key is used in a non-secure environment on the Internet? Wait. In order to ensure availability, we can test whether the handshake works. So there are two steps below.
The client uses the message authentication code (MAC) algorithm agreed by both parties, such as MD5, to encrypt a piece of plaintext Q (this plaintext should be irrelevant because it will be sent to the server) to generate a MAC. Then, after encrypting Q and MAC using the symmetric encryption algorithm (such as AES) agreed by both parties, a Finished Message is generated and sent to the server. (Here, according to the TLS record protocol, the Finished Message is actually a specific TLS record. The Content type carried by the Finished Message is 20, which is equivalent to telling the server: I am ready to begin the normal communication .)
After the server receives the TLS record, it tries to decrypt the ciphertext (Decryption) first, and then uses the agreed MAC Algorithm to verify whether the content is tampered with (Verification ). At this time, if either of the two jobs fails, the success will be abandoned... This assumes that all of them are successful, so the server did the same thing with the client in the previous step: generate a Finished Message with Content type 20 and send it to the client. So far, the entire handshake process has officially ended... The following communication is the process in which both parties directly use symmetric encryption algorithms to directly encrypt and decrypt messages. Of course, each interaction process also includes the MAC verification process described above.
