🐲 [4] Shutdown HTTP series -HTTPS

Shutdown HTTP series introduction

One of the big guys once said to me, “Your limit is partly determined by your network knowledge.”

Is the ceiling really that low for me, who knows nothing about HTTP… Can’t you take some time to tidy up 🤔️?

This time please give Lin Dull a chance to follow in my footsteps 👣 learn it from 1. In addition, the HTTP series that I have compiled are basically accompanied by a matching answer for the shallow and deep answers in the interview. The shallow answers are for you to remember better, and the deep answers make sure that you really understand the knowledge points in the shallow answers.

Down the whole series, let’s Shutdown HTTP completely!! 💪

Series of mind maps:

Series catalog:

• 🐲 [1] Shutdown HTTP Series – Basics
• 🐲 [2] Shutdown HTTP Series -HTTP Packet
• 🐲 [3] Shutdown HTTP Series -Cookie
• 🐲 [4] Shutdown HTTP series -HTTPS
• 🐲 [5] Shutdown HTTP series -CCPG
• 🐲 [6] Shutdown HTTP Interview Series

All the content of the article has been sorted out to LinDaiDai/ Niubility -coding-js come and give me the Star 😊~

This directory

By reading this article you can learn:

• HTTPS concept
• Advantages over HTTP/Why HTTPS
• Differences between HTTP and HTTPS
• Specific solution
• SSL/TLS
• Why don’t all websites use HTTPS

1. The HTTPS concept

HTTPS is not a new protocol, but the communication interface is replaced by SSL or TLS (establishing an intermediate layer between HTTP and TCP).

In other words, HTTPS is HTTP in a shell of SSL.

It can be understood as:

HTTPS = HTTP + SSL/TLS
Copy the code

2. Advantages over HTTP/Why HTTPS

In fact, it makes up for the shortcomings of HTTP:

• Data privacy, content encrypted symmetrically;
• Data integrity, content integrity verification;
• Identity authentication: A third party cannot disguise the identity of the client/server

3. The difference between HTTP and HTTPS

It can be seen from the following aspects:

• HTTPS standard port 443, HTTP 80
• HTTPS is based on the transport layer, and HTTP is based on the application layer
• HTTPS displays a green security lock on the browser, while HTTP does not
• Make up for the shortcomings of HTTP, data privacy, integrity, authentication. So it’s safer.

4. Specific solutions

For the specific solution of HTTPS, I think it is still based on its functions:

• Resolving eavesdropping (encryption and decryption)
• Resolving content tampering (digital signature)
• Resolving communication Party Identity Masquerade (Digital certificate)

This is a lot of stuff, so let’s look at it separately.

4.1 Troubleshooting Eavesdropping (Encryption and Decryption)

4.1.1 Symmetric Key Encryption (Shared Key Encryption)

Concept: is the simplest encryption method, refers to encryption and decryption with the same key.

Process:

• The sender of the secret message sends the encrypted content (that is, the secret message) along with the key to the recipient.

• The recipient then uses the key to decrypt the secret message and retrieve its contents

Advantages:

• Encryption and decryption is very efficient

Disadvantages:

• It’s not secure. Anyone with a key can decrypt it

4.1.2 Asymmetric Key Encryption (Public Key Encryption)

Concept: Use a pair of asymmetric keys, that is, there will be two keys, one is a private key (only oneself can have), and one is a public key (can be released to anyone). The number of packets encrypted with the private key can only be solved by the public key, and the data packets encrypted with the public key can only be solved by the private key.

Process: The party that sends the secret message encrypts the message with the “public key of the other party”. After receiving the encrypted message, the other party decrypts it with its private key.

Features: One to many information transmission, the server only needs to maintain a good private key can be encrypted communication with multiple clients.

Advantages:

• Makes the transmissions uncrackable. For example, if the data is encrypted with a public key, even if a third party intercepts the data but does not have the corresponding private key, it cannot be cracked.

Disadvantages:

• The public key is public and accessible to anyone, so if an encrypted message is sent using a private key, a hacker with a public key can use the public key to decrypt and access the information inside.
• The public key does not contain information about the server, and using asymmetric encryption algorithms does not ensure the validity of the server’s identity. There may be a man-in-the-middle attack, in which the public key sent from the server to the client may be intercepted and tampered with along the way.
• It takes some time to encrypt and decrypt data, which reduces the efficiency of data transmission.

4.1.3 Hybrid Encryption Mechanism (HTTPS Mode)

Concept: Combining the advantages of the two encryption modes, asymmetric encryption mode is used in the key exchange and symmetric encryption mode is used in the subsequent communication exchange message establishment.

Process: The party sending the ciphertext uses the “public key of the other party” to encrypt the “symmetric key”. After receiving the ciphertext, the other party uses its private key to decrypt the “symmetric key” to obtain the “symmetric key”. This ensures that the exchanged key is secure and uses the symmetric encryption mode to communicate.

Q1: What are the benefits of hybrid encryption?

Difficulty: 🌟 🌟

It has been said that symmetric key encryption and asymmetric key encryption have their advantages and disadvantages, and hybrid encryption mechanism is the combination of the two to use their respective advantages for encryption transmission.

For example, since symmetric keys have the advantage of fast encryption and decryption, they can be used for encrypted transmission after the connection between the client and the server is confirmed. But only if it’s resolved so that both parties can safely access the symmetric key. In this case, asymmetric key encryption can be used to transmit the symmetric key, because we know that the advantage of asymmetric key encryption is to ensure that the transmitted content is secure.

Therefore, its advantage is that it not only ensures the secure transmission of symmetric key between the two parties, but also uses symmetric encryption mode to communicate, which is much faster than using asymmetric encryption communication only. In order to solve the HTTP content may be eavesdropping problem.

Q2: What are the disadvantages of hybrid encryption?

Difficulty: 🌟 🌟

Hybrid encryption is primarily designed to address the problem of content being eavesdropped in HTTP. However, it does not guarantee the integrity of data, that is to say, data may be tampered with by a third party during transmission, such as completely replaced, so it does not verify the integrity of data. If you need to do this, you need to use a digital signature.

4.1.4 HTTPS workflow

(For a brief description, if the interviewer wants to hear the specific process, please refer to 4.2 versions of the handshake in the later part of the article.)

Difficulty: 🌟 🌟 🌟

HTTPS is transmitted using a hybrid encryption mechanism consisting of symmetric key encryption and asymmetric key encryption.

That is, the party sending the ciphertext encrypts the “symmetric key” with the “public key of the other party”, and the other party decrypts the “symmetric key” with its own private key after receiving the ciphertext. In this way, on the premise of ensuring the security of the key exchanged between the two parties, symmetric key is used for communication.

The process is simply:

1. The client first sends an HTTPS request to the server
2. The server returns the pre-configured public key certificate to the client along with other information
3. After receiving the certificate from the server, the client authenticates the certificate by referring to the process of digital certificate authentication to obtain the information about the server and its public key
4. After successful validation, a parameter called client_params is generated and sent to the server; At the same time, they will use pseudo random function to generate a secret, which is the symmetric key for their subsequent communication.
5. After the server receives the client_params it just received, it also generates a secret based on the pseudo-random function. Both sides now have the same symmetric key.
6. The subsequent transmission will use this secret for symmetric key encryption and decryption transmission

4.1.5 Differences between Symmetric key Encryption and asymmetric Key Encryption

Difficulty: 🌟 🌟

Symmetric key encryption is the simplest encryption method, which uses the same key for encryption and decryption. The advantage of this is that the encryption and decryption efficiency is fast, but it is not secure. If someone gets the key, anyone can decrypt it.

An asymmetric key has two keys. One is a private key, and only the asymmetric key has its own key. One is a public key that can be published to anyone. And the encrypted content can only be solved by a matching key. One of the benefits of this is that the transmission is secure because, for example, if the data is encrypted with a public key, even if a third party intercepts the data without the corresponding private key, it cannot be decrypted. However, it also has disadvantages. First, the public key is public, so anyone can pass it. If the content is encrypted by the private key, the hacker who has the corresponding public key can use this public key to decrypt the information inside. Second, the public key does not contain the server information, that is, it cannot ensure the legitimacy of the server identity; In addition, asymmetric encryption consumes a certain amount of time, which reduces the data transmission efficiency.

4.2 Resolving Content Tampering (Digital Signature)

4.2.1 Basic Concepts

The reason for digital signature: Although the mixed encryption mechanism ensures that the content is not monitored, the transmitted data may be tampered with (for example, completely replaced), that is, data integrity cannot be verified. Digital signatures are meant to verify data integrity.

Features:

• You can be sure that the message is actually signed and sent by the sender because no one else can impersonate the sender’s signature.
• Can determine the integrity of the content and prove that the data has not been tampered with.

The Hash function:

• That’s the hash function, hash digest function, hash function.
• Simply put, it is a function that compresses a message of any length into a message digest of a fixed length.

4.2.2 Digital signature process

(Concept of digital signature and verification process)

Difficulty: 🌟 🌟 🌟

The main purpose of digital signature is to solve the problem that HTTP content may be tampered, that is, to verify the integrity of data. It can be sure that the message is from the sender, because there is a process to verify the digital signature, and no one can fake the sender’s signature.

What is a digital signature? The first step is to Hash the text into something called a message digest, and the second step is to encrypt the message digest with the sender’s private key. This result is called a digital signature, and it is usually sent to the recipient along with the original text.

And the process of verifying it is not complicated.

• First the sender sends the original text along with a digital signature (that is, an encrypted abstract) to the recipient
• The recipient receives these two things, the original text and the digital signature
• The recipient hashes the text to get a message digest
• Decrypting the digital signature with the sender’s public key also results in a message digest
• You can verify that the data has not been tampered with by simply comparing whether the two message digests are equal

Of course, the key step here is to ensure that the public key transmitted by the sender is reliable, which is when the digital certificate is used.

Let’s look at the flow chart of the data signature:

4.3 Resolving Communication Party Identity Masking (Digital Certificate)

4.3.1 Concepts of digital Certificates

Difficulty: 🌟 🌟 🌟

Digital certificates are also called public key certificates, or simply certificates. It is mainly to solve the problem that the identity of the communicator is disguised, that is, to verify the identity of the communicator.

Because we know that in HTTPS, although there is a mixed encryption mechanism to ensure that the data is not monitored, there is a digital signature to verify the integrity of the data, but the premise of digital signature verification is to get the sender’s public key and ensure that the public key is reliable, so it needs a digital certificate.

It is simply a file issued to the server by some authoritative digital authentication authority. A Digital Certification Authority, or CA, is a third-party organization that both clients and servers trust. I know that a well-known one is VeriSign.

4.3.2 Process of issuing digital certificates

• The server operators submit their public keys, organizational information, and personal information to the certification authority and apply for authentication
• The certification body will verify the authenticity of the information submitted by applicants through various online and offline channels after getting the information
• After confirming its authenticity, the certification authority gives the information (the applicant’s public key, organization information, personal information and certification authority’s own information, etc.), which is referred to as plaintext information, to carry out digital signature. The process is also the steps of digital signature mentioned in signature:
  • 1. Use the Hash function to process plaintext information and generate a summary.
  • 2. Use the private key of the authentication authority to encrypt the summary.
  • The file generated by these two steps is called a digital signature.
• The certificate, a combination of plaintext information and digital signatures, is then issued to the applicant, the server.

I drew the certificate issuing process:

(If the above image does not load, you can see here: hexo-blog-1256114407.cos.ap-shenzhen-fsi.myqcloud.com/%E6%95%B0%E…

4.3.3 Composition of certificates

It mainly consists of two parts:

• Clear information
  • Public key of the applicant
  • Applicant’s organization information and personal information
  • Information about issuing agency CA
  • In plain text, such as the validity time and certificate serial number
• The signature
  • Its generation process is actually the generation of digital signature introduced above
  • Generation process: THE CA first generates a message digest by using Hash function to process the public plaintext information, and then encrypts the message digest with its own private key to generate a signature.

The combination of this plaintext information and this signature is called a certificate, which the certification authority issues to the applicant (the server).

4.3.4 Why can digital certificate verify the identity of the communication party?

(Digital certificates allow the browser to authenticate the server and its authentication process)

Difficulty: 🌟 🌟 🌟

That’s because the first time the client sends an HTTPS request to the server, the server sends its own certificate back to the client along with other information (such as server_random, server_Params, encryption suites to use, and so on).

The client first validates the certificate upon receipt, and only then does any further action. The verification process is actually the verification process of digital signature (Question 5) :

• As mentioned earlier, the certificate is actually composed of plaintext information (the applicant’s public key, organization information, personal information, and certification authority’s own information) and the digital signature of this plaintext information. (Corresponding to question 5, i.e. original text and digital signature)
• The client uses the Hash function to process the plaintext information to generate a summary of the information
• The CA’s public key built into the browser is then used to decrypt the digital signature in the certificate to get a summary of the information. Since we know that the certificate is actually issued to the server by the CA, and the digital signature inside is encrypted with the CA’s private key, only the CA’s public key can solve it.
• Finally, the two summaries are compared to ensure that the identity of the communicator is correct if they are the same.

In fact, the process of certificate verification is not only the verification of digital signature, but also the domain name information related to the certificate, the validity period, whether the certificate is in the CRL revocation list, and whether its upper level is valid, etc.

If the interviewer asks you if the previous level is valid, you should say: “This is a recursive process until you get to the Root certificate, which is either the operating system’s built-in Root certificate or the browser’s built-in Root certificate.”

As mentioned earlier, only authenticated certificates with digital signatures that can be decrypted using the CA’s public key are valid because the CA issued the certificate. This ensures that the public key that the client receives from the server is actually available (because the public key is in the clear text of the certificate).

Since the browser itself does not have the ability to determine whether the certificate is valid, it leaves the job to the CA, which is a trusted authority. It simply inserts its own public key into the browser, which then uses the PUBLIC key to decode the signature in the certificate. The signature of the certificate is encrypted by the CA’s private key, and only the CA’s public key can be solved, but its public key is not available to anyone, only major browser manufacturers have, so this is the verification process of the digital certificate.

5. SSL/TLS

5.1 Basic Concepts

Secure Sockets Layer

TSL Transport Layer Security

Version:

SSL has been released in three major versions, with the third version being standardized as TLS and considered as the first version of TLS, namely:

Indicate = TLSCopy the code

TLS1.0 and TLS1.1 were both considered unsafe. The current mainstream version is TLS1.2 and the better TLSL1.3 was released in 2018.

5.2 Different Handshake Versions

In HTTPS encrypted transport, which actually involves the SSL/TLS protocol, there is a TSL handshake. It is mainly divided into two parts:

• The traditional TLS handshake is the RSA handshake;
• Now the mainstream TLS1.2 version of the handshake, also known as the ECDHE handshake.

In the interview, I can say that I know both types of handshake, but if I have to choose one, I think I can introduce the mainstream TLS1.2 version of handshake, please see the following 4.2.1.

5.2.1 Mainstream TLS1.2 handshake, namely the ECDHE handshake

Difficulty: 🌟 🌟 🌟 🌟

It goes something like this:

1. When the client sends the HTTPS request for the first time, it sends the client_random, TSL version number, and encryption suite list to the server

2. After receiving the TSL, the server confirms the version number of TSL and sends server_random, server_Params, the encryption suite to be used, and its certificate to the client

3. Upon receiving this information, the client first validates the server’s certificate (subject 7), passing a client_params to the server if successful

4. At the same time, the client calculates a PRE_RANDOM through the ECDHE algorithm, passing in two parameters, one client_params and one server_params. ECDHE(client_params, server_params) = per_random

5. At this time, the client has client_RANDOM, server_RANDOM, and pre_RANDOM at the same time. It calculates these three parameters through a pseudo-random function to obtain the final secret, which is the symmetric key used for their subsequent communication.

6. After the client generates secret, it will send an ending message to the server, telling the server to use symmetric encryption after that, and the algorithm of symmetric encryption is agreed with the first time.

7. The server generates secret in the same manner as the client when it receives the client_params just passed in, and also sends a closing message to the client.

8. When both parties have received the closing message and verified it successfully, the handshake ends. The secret symmetric key is then used to encrypt the packets for transmission.

(ECDHE is based on the discrete logarithm of the elliptic curve, and the two parameters passed in are also called the public keys of the elliptic curve.)

If the interviewer asks you for details about the RSA handshake, refer to 4.2.2 and 4.2.3. If not, you may be asked about the difference between the RSA handshake and the ECDHE handshake. See 4.2.4.)

5.2.2 But I just want you to describe the RSA handshake

(This is in case the interviewer wants to ask you to describe the RSA handshake again. You can also use this simple version to describe the handshake. See 4.2.3 for details.)

Difficulty: 🌟 🌟 🌟

1. The client first sends an HTTPS request to the server
2. The server returns the pre-configured public key certificate to the client along with other information
3. After receiving the certificate from the server, the client authenticates the certificate by referring to the process of digital certificate authentication to obtain the information about the server and its public key
4. After the verification is successful, the pseudo-random function is used to calculate a symmetric key (secret) needed for encryption, and the public key of the server is used to encrypt the symmetric key and send it to the server
5. The server then decrypts the message with its own private key to obtain the symmetric key inside. At this point, both the server and client have symmetric keys.
6. The subsequent transmission will use this secret for symmetric key encryption and decryption transmission

5.2.3 Can you describe the RSA handshake in detail?

(If I ask you for details… That’s it.)

Difficulty: 🌟 🌟 🌟 🌟

1. The client first sends client_RANDOM, TSL version number, and a list of cryptosuites to the server
2. After receiving the TSL version number, the server sends server_RANDOM, the encryption suite to be used, and its certificate to the client
3. After receiving the information, the client first verifies the certificate of the server (question 7). If the authentication succeeds, the client generates a PRE_RANDOM using RSA algorithm and sends the pre_RANDOM to the server encrypted with the public key of the server (in the certificate).
4. At this point, the client has client_RANDOM, server_random, and pre_random, and calculates these three parameters through a pseudo-random function to obtain the final secret, which is the symmetric key used for their subsequent communication.
5. After receiving the pre_RANDOM encrypted with its own public key, the server decrypts it with its own private key to obtain the pre_RANDOM inside and generates secret in the same way as the client.
6. The secret symmetric key is then used to encrypt the packet transmission.

(A comparison can be made with 4.2.1. You can easily see that step3, 4, and 5 are different.)

5.2.4 What is the difference between the ECDHE handshake and the RSA handshake?

Difficulty: 🌟 🌟 🌟

The main differences are:

1. The secret(symmetric key) generation process is different. In RSA, RSA algorithm is used to generate a PRE_RANDOM, and the public key of the server plus pre_RANDOM is sent to the server, and then pseudo-random functions are used to generate the same secret symmetric key. In the ECDHE handshake, it does not use RSA algorithm, but uses PRE_random generated by ECDHE algorithm, and in this process, there are more client_params and server_params parameters than RSA.
2. After secret is generated, the ECDHE handshake can be advanced after the client sends the closing messageJump start, saves an RTT by sending HTTP packets directly. You don’t have to wait for the end message to reach the server, and then wait for the server to return the end message to you and start sending requests directly. This is also calledTLS False Start.
3. Most important: RSA does not have forward security, ECDHE does

(Forward security: a crack does not affect the nature of historical information is forward security)

5.2.5 Forward Security

Difficulty: 🌟 🌟

In a word: one crack does not affect the history of information is the nature of forward security.

For example, during the RSA handshake, the client obtains the public key of the server and encrypts PRE_RANDOM to the server using the public key. If a third party has the private key of the server and intercepts all the previous messages, it can crack the ciphertext and obtain pre_RANDOM, client_random and server_random and generate secret according to the corresponding pseudo-random function, that is, obtain the symmetric key of the final communication. Each historical packet can be decrypted in this way. It has no forward security.

However, the ECDHE generates a zero-hour key pair (client_params and server_params) during each handshake. Even if a third party has a private key that can be decrypted, previous historical packets are not affected. It has forward security.

5.3 TSL1.3? What improvements does it make over TSL1.2

Difficulty: 🌟 🌟

TSL version 1.3 was released in 2018. It has the following major improvements over TSL1.2:

1. Strengthen the security

Many encryption algorithms have been abolished and only five encryption suites remain. The most important was the abandonment of RSA because of the discovery of PRAEK attacks in 2015, that is, RSA vulnerabilities had been discovered and could be cracked; RSA also has no forward security.

2. To improve performance

At the same time, session reuse is used to save the time of regenerating key, and 0-RTT connection is achieved by PSK.

6. Why don’t all sites use HTTPS?

Difficulty: 🌟 🌟

• The implementation of HTTPS requires a threshold, because the selection, purchase, and deployment of certificates in traditional mode are time-consuming and costly
• In addition, HTTPS is generally believed to be slower because its encrypted communication consumes more CPU and memory resources than HTTP’s plaintext transmission
  • (Users can solve this problem by deploying certificates to SLB(load balancing) or CDN through performance optimization.)
• Buying a certificate costs money
• Domestic security awareness may not be that strong

Refer to the article

• Illustrated HTTP

After the language

You wish the world, I wish you no bugs. So much for this article.

At the end of this series of articles, I would like to express my gratitude to you with a kind words:

"I was born in the South"

"Living in the South."

"Planted in your favorites."

"Well, I've been to a different place."

Those who like Lin’s stupidity also hope that they can follow Lin’s public account LinDaiDai

I will update some front-end knowledge content and my original article 🎉 from time to time.

Your encouragement is the main motivation for my continuous creation 😊.

Related recommendations:

The most detailed BPMN.js textbook in the whole Web

If you don’t understand Babel, I’ll send you a mask.

“[Suggested stars] To come to 45 Promise interview questions a cool end (1.1W words carefully arranged)”

“[suggestion 👍] 40 more this interview questions sour cool continue (1.2W word by hand)”

“[why not three even] more simple than inheritance of JS inheritance – packaging (small test)”

【 Why not three times 】 finish these 48 questions to thoroughly understand JS inheritance (1.7W words including hot finishing – back to nature)

The dull recent interview 128 summary (containing more detailed answer) | nuggets technical essay”