In the HTTP protocol, all messages are sent and received in plain text. In the five-layer TCP/IP model, data is directly transmitted in plain text from the application layer (HTTP) to the transport layer (TCP) without any encryption in between. Implementing SSL/TLS adds a layer of security by encrypting the data before it reaches the transport layer, as illustrated in the following diagram.
This leads to the following three major risks:
So, do we have any countermeasures for these three major risks mentioned above? Yes, we do.
Of course, it’s not to say that the HTTP protocol itself definitely exposes the above three major risks. We can also use the HTTP protocol to encrypt or digitally sign the data before transmission, which can similarly avoid eavesdropping and tampering risks to the greatest extent, but it cannot be absolutely safe.
The SSL/TLS and HTTPS protocols are very closely related. HTTPS is built upon the SSL/TLS protocol.
One could understand that the ‘S’ in HTTPS refers to the SSL/TLS protocol itself.
The above simply summarizes the development history of the SSL/TLS protocol. For more detailed information, you can refer to the Transport Layer Security Protocols on Wikipedia. The SSL protocol is the predecessor of the TLS protocol; it is an improved version of the SSL protocol.
The SSL/TLS protocol is located between the application layer and the transport layer, used for encrypting upper-layer data packets and transmitting them while performing identity and data integrity verification.
In simple terms, SSL/TLS is a set of protocols that combines various encryption algorithms, digital signature algorithms, and digital certificates, aiming to ensure the security of communication.
When adopting the SSL/TLS protocol, both communicating parties need to perform a handshake before establishing a connection to negotiate a session key, which is used for subsequent encryption and decryption of communication data.
Encryption algorithms are divided into two major categories:
SSL/TLS combines the advantages and disadvantages of both, using symmetric encryption algorithms for data packet encryption, while the session key for symmetric encryption is obtained through asymmetric encryption negotiation.
Common symmetric encryption algorithms include:
Common asymmetric encryption algorithms include:
Common digital signature algorithms include:
The following uses a packet capture tool to briefly analyze the handshake process of the HTTPS protocol, using Baidu as an example:
First, we need to understand that the purpose of the handshake is to resolve the three major risks mentioned above, namely negotiating a session key, verifying data integrity, and identity authentication.
From the diagram above, the basic process of the handshake can be summarized:
Let’s analyze each step in detail:
It contains the current TLS protocol version number (Version) supported by the client, the cipher suites supported by the client, a random number, and the compression method supported by the client.
In the first step, the client informs the server of the relevant information it supports. In the second step, the server negotiates and returns confirmed information, such as determining which cipher suite or compression method to use.
These parameters can later be used by the client to calculate the session key. If using the RSA algorithm, this step is not necessary. After passing the parameters, it informs the client that the server-side handshake is complete (Done).
In this step, the client uses the public key passed in step four to generate what is called a pre-master secret, and then transmits this pre-master secret to the server. The server uses its private key to decrypt this pre-master secret, obtaining information up to this point, and both the client and the server now possess it.
Both sides then use the D-H algorithm and the relevant parameters passed in step four to generate one, which will be used for subsequent communication. It can be seen that whether the session key can be cracked depends on whether the third random number can be cracked, and the third random number cannot be captured using WireShark.
This step is to inform the server that subsequent communication will use the key we negotiated.
The client generates a digest of the previous handshake messages and encrypts it with the negotiated key (symmetric encryption); this is the first encrypted message sent by the client. If the server can decrypt it using the key, it indicates the key negotiated earlier is consistent.
Same as step 5, if the server can decrypt the digest using the D-H algorithm, the server should inform the client that the negotiation between us is consistent.