I believe you will be familiar with HTTPS in your interview. Maybe you can only simply say the difference between HTTPS and HTTP, but is the real principle clear? How safe is he? Let’s use plain English to demystify HTTPS.

What is the HTTPS

What is HTTPS? A: Isn’t HTTPS HTTP with an “S” at the end?

The S here stands for SSL/TLS, and HTTPS uses SSL/TLS to encrypt data packets on top of HTTP.

Let us keep in mind two main purposes:

  • Encrypt data

  • Verify web server identity

How does HTTPS encrypt data

We already know that the first purpose of HTTPS is to encrypt data. For data encryption, we will talk about two types of encryption:

  • ** Symmetric encryption: ** symmetric refers to the same sender and receiver on both sides of the same key, encryption and decryption are the same key from the beginning to the end only need to save a key on the line.

  • ** Asymmetric encryption: ** The sender and receiver use a pair of keys, public and private. Generally, the private key is confidential and cannot be disclosed, and the public key can be transmitted externally. We can encrypt with public key and decrypt with private key (data encryption) or we can encrypt with private key and decrypt with public key (signature explained below)

** Hybrid encryption: ** Knowing the advantages and disadvantages of both encryption methods, our HTTPS is very impressive, it uses a mixture of both encryption methods.

What happened to symmetric encryption keys? Let’s switch to another way of thinking, we transfer the key in our symmetric encryption with asymmetric encryption in the transmission process.

This sentence is a bit convoluted. Let’s look at the picture above:

  • The client generated session key is the key generated by symmetric encryption.

  • It is encrypted with a public key and then transmitted (this time it is not the data that is encrypted but the session key is encrypted). The public key in this case is the public key in asymmetric encryption which is passed by the server (public).

  • The server decrypts our session key using asymmetrically encrypted private keys.

  • Both client and server can now use the same session key for encryption and decryption.

Even if an attacker intercepts the encrypted session key during the transfer, he can’t get the session key without the server’s private key.

The neat thing about this whole process is that before we passed the key, now we pass the safe, the key is in the safe, and even if you get the safe, you can’t get the key without the key to the safe.

HTTPS how to verify the identity of the web server

The second purpose of HTTPS is to authenticate web servers. How does this work?

First, we have solved the problem of data encryption. Although an attacker cannot decrypt the data, he can tamper with it. How do we know that the data has not been manipulated?

What if the data is tampered with

This is the time to use digital signature. Digital signature: the original text (part of the key data) is first used to generate message digest with Hash function, and then encrypted with the sender’s private key to generate digital signature, together with the original text sent to the receiver. Two key points:

  • The Hash algorithm generates a summary of information

  • Private key encryption generates a digital signature

How does a client verify a digital signature? After the client receives the digital signature from the server:

  • Decrypt the digital signature with the server’s public key to get the message digest (original untampered)

  • Use the Hash function to compute the received text to generate a summary (potentially tampered with).

If the two summaries are the same, the data has not been tampered with. OK, here you may feel no problem! Finally, there is a crucial point: all of our assumptions are based on the public key of the client being passed from the server, so what if an attacker forged the public key of the server?

What if the server public key is tampered with

This is where digital certificates come in, and the Digital Certificate Authority (CA) is in the position of a third-party organization that both client and server can trust.

The server applies for a digital certificate from the CA. After the certificate is approved, the CA issues a certificate to the applicant, which contains the following contents:

After obtaining the digital certificate, the server transfers it to the client.

How does the client verify the digital certificate

The steps are as follows:

  • First, the browser reads information about the certificate owner and validity period for verification.

  • The browser searches for the built-in trusted CA in the operating system and compares it with the CA in the certificate sent by the server to verify whether the certificate is issued by a legitimate authority.

  • If not, the browser will report an error indicating that the certificate from the server is untrustworthy. If found, the browser extracts the issuer CA’s public key from the operating system and decrypts the signature in the certificate sent from the server.

  • The browser uses the same Hash algorithm to compute a summary of the information based on the contents of the certificate and compares the calculated value with the decrypted value of the certificate.

  • If the comparison results are the same, the certificate sent by the server is valid and not impersonated. The browser can then read the public key in the certificate for subsequent encryption.

The principle of HTTPS is shown as follows:

Original: https://juejin.cn/post/6844904150115827725