How does HTTPS ensure secure transmission?

[[379186]]

Preface

The HTTPS connection process is also a common topic.

The issues involved, such as digital certificates, electronic signatures, SSL/TLS, symmetric encryption, and asymmetric encryption, always make people confused and have no idea how to answer them.

Today, let’s get familiar with the intricate relationship between them.

It is indeed unsafe! (HTTP protocol transmission) The traditional HTTP transmission protocol is a plain text transmission protocol. That is, the data is not encrypted during the communication process, and it is easy to leak data.

For example, the leakage of important user information and the sending of forged data will cause considerable problems.

So some friends thought that they could encrypt the data themselves, but this method of encrypting data by themselves also has many problems, such as:

Not safe enough. Although the data seems to be safe after being encrypted, how to manage the encryption key? This is a big problem. Save it on the client? Introduce a plug-in? I don’t think it’s a good solution. It’s still possible to be cracked.

Compatibility issues. Encrypting data by yourself involves managing encryption algorithms, and encryption algorithms are constantly evolving, which requires the client and server to maintain updated encryption compatibility. Moreover, updates cannot be made in real time, and code logic needs to be updated offline. Therefore, this is also a rather troublesome issue.

Performance issues: The process of encrypting and decrypting through code is also time-consuming and will affect performance.

Therefore, a new protocol, the SSL/TLS protocol, was added based on the original HTTP protocol, forming a new and more secure network protocol, HTTPS.

Encrypt data ~ (HTTPS transmission data) In the previous network data transmission process, I said that a series of application layer tasks for parsing data are handed over to the TCP protocol stack of the browser and operating system.

Therefore, the encryption and decryption work of HTTPS is naturally handed over to the browser, so the above-mentioned performance issues do not exist.

How is it done specifically? A symmetric encryption algorithm is used:

The client encrypts the data using a symmetric key.

The client decrypts the data using the symmetric key.

Someone may ask, isn't this the same as what we just said? How to manage this key?

This requires finding a way to tell the other party the symmetric key before officially transmitting the data. And this method is - asymmetric encryption.

How do I tell the other party this symmetric key? (Asymmetric encryption) Everyone knows that asymmetric encryption is divided into private key and public key, that is, you encrypt the data with the public key, and then I use the private key to decrypt it. Only you have the private key, so only you can decrypt the data, even if the middleman gets the data, he can't crack it.

In actual client-server communication, the server sends the public key to the client, and then the client uses the public key to encrypt the symmetric key and sends it to the client. Only the client has the private key to decrypt the ciphertext containing the symmetric encryption. This is represented by a picture:

However, the public key is transmitted in plain text, so the middleman can use this public key to forge data:

So how to solve the problem? This message needs to prove that it comes from the real server and obtains the real public key, not a forged one, which requires an electronic signature.

I want to prove that I am me! (Electronic signature)

Electronic signature is actually a use of asymmetric encryption.

Its usage is:

A uses the private key to encrypt the hash value of the data. The encrypted ciphertext is called a signature, and then transmits the ciphertext and the data itself to B.

After B receives it, he decrypts the signature with the public key and then compares it with the hash value of the transmitted data. If they are the same, it means that the signature is indeed signed by A, and only A can sign it because only A has the private key.

The actual situation is:

The server uses another private key to sign the hash value of the data, which is the data we want to transmit (public key), and then transmits it together with the data (public key). The client then uses another public key to decrypt the signature. If the decrypted data and the hash value of the data (public key) are consistent, it can be proved that the source is correct and not forged.

However, where do the additional private key and public key used for signing come from? This requires a strong CA to verify.

Powerful backend organization~(digital certificate)

A certificate authority (CA) is an institution that issues digital certificates. It is an authority responsible for issuing and managing digital certificates, and as a trusted third party in e-commerce transactions, it is responsible for verifying the legitimacy of public keys in the public key system. In actual situations, the server will pass its public key and some information about the server to the CA, and then the CA will return a digital certificate to the server, which includes:

• Server's public key
• Signature Algorithm
• Server information, including host name, etc.
• The CA's own private key signs this certificate

The server then passes this certificate to the client during the connection phase. How does the client verify it?

Careful friends must know that each client, whether it is a computer or a mobile phone, has its own system root certificate, which includes the issuing authority of the server digital certificate. Therefore, the system root certificate will use their private key to help us decrypt the signature of the digital certificate, and then compare it with the data hash value in the certificate. If they are the same, it means that the source is correct and the data has not been modified.

Of course, the middleman can also apply for a certificate through the CA, but the certificate will contain the server's host name, and this host name (domain name, IP) can verify which host your source comes from.

To expand:

In fact, there is another layer of structure between the server certificate and the root certificate: it is called the intermediate certificate. We can open any web page and click the 🔒 button in the upper left corner to see the certificate details:

You can see that a complete SSL/TLS certificate generally has three layers:

• The first layer: root certificates, which are the ones that come with the client.
• The second layer: Intermediate certificates. Generally, the root certificate will not directly issue the server certificate, because this behavior is more dangerous. If it is found that the issuance is wrong, it will be very troublesome and require the modification of the certificate. Therefore, the intermediate certificate is generally referenced. The root certificate signs the intermediate certificate, and then the intermediate certificate signs the server certificate, one layer after another.
• The third layer: server certificate. This is the certificate related to our server.

Here’s another picture to summarize:

Dedicated partner❤️(SSL/TLS)All the work mentioned above is done for us by the S in HTTPS, which is the SSL/TLS protocol.

SSL: (Secure Socket Layer) is a protocol layer located between the reliable connection-oriented network layer protocol and the application layer protocol. SSL achieves secure communication between the client and the server by mutual authentication, using digital signatures to ensure integrity, and using encryption to ensure privacy. This process is actually the traditional transport layer - HTTP layer, after obtaining the data, it is handed over to the SSL layer, and then authentication, encryption and other operations are performed.

TLS is an upgraded version of SSL, and its main goal is to make SSL more secure and to make the protocol specifications more precise and complete.

That’s all I have to say today.

In fact, only one step in the HTTPS connection process was discussed, namely the sending of the digital certificate.

I will talk about the complete connection process next week. I can’t come back. Next week, there will be an article that will solve all network problems. Look forward to it~

Reference https://wetest.qq.com/lab/view/110.html http://www.ruanyifeng.com/blog/2011/08/what_is_a_digital_signature.html https://www.zhihu.com/question/52790301

This article is reprinted from the WeChat public account "Ma Shang Ji Mu", which can be followed through the following QR code. To reprint this article, please contact the WeChat public account "Ma Shang Ji Mu".