Why do YOU need HTTPS? What is the HTTPS?

We know that one of the big features of HTTP is plaintext transmission, although this is very convenient for developers. At the same time, plaintext data is despised by malicious hackers (although the data submitted by POST cannot be seen in the body of the packet, but can still be stolen through the packet capture tool). Obviously, transmission over plaintext is extremely insecure. And vulnerable to man-in-the-middle attacks.

To protect against such attacks, we had to introduce a new encryption scheme, HTTPS.

HTTPS is not a new protocol, but an enhanced version of HTTP. Specifically, the HTTP+TLS/SSL protocol.

Principle: Establish an intermediate layer between HTTP and TCP, when HTTP and TCP communication is not as direct as before, directly through a middle layer for encryption. The encrypted datagram is passed to TCP, and the responding TCP must decrypt the data before it can be sent to HTTP above. This middle layer is also called the security layer. The core of the security layer is data encryption and decryption. ,

Next, we will analyze how HTTPS encryption and decryption is implemented.

HTTPS is different from HTTP

  • HTTP is a plaintext transmission protocol. HTTPS is a network protocol that uses SSL and HTTP to encrypt transmission and authenticate identity. It is more secure than HTTP.
  • HTTPS is more friendly to search engines and conducive to SEO optimization.
  • HTTPS standard port 443,HTTP standard port 80.
  • HTTPS requires an SSL certificate, unlike HTTP.

The main functions of HTTPS:

  1. Encrypts data and establishes an information security channel to ensure data security during transmission.
  2. Real authentication to the web site server.

How HTTPS works

TLS/SSL relies on three basic algorithms: hash function, symmetric encryption and asymmetric encryption. The asymmetric encryption implements identity authentication and key negotiation. The symmetric encryption algorithm uses the negotiated key to encrypt data and verifies information integrity based on the hash function.

Symmetric and asymmetric encryption

concept

First, you need to understand the concepts of symmetric and asymmetric encryption, and then discuss how well both work when applied.

Encryption and decryption using the same secret key is called symmetric encryption. Client The Client and Server share a set of keys. The encryption process seems understandable, but some problems arise.

“Problem 1:” the WWW world Wide Web has many clients, it is impossible to use secret key A for information encryption, this is very unreasonable, so the solution is to use A client to use A key for encryption.

Question 2: “Since different clients use different keys, then” how to transfer symmetric encryption keys?” The only solution is ** “one end generates a secret key and sends it over HTTP to the other end” **, which creates new problems.

“Question 3:” How to ensure encryption during the process of transferring the key? “If the middleman intercepts the key, the key is also obtained,” so you would say to encrypt the key again, how do you save the process of encrypting the key, is the process of encryption?

Here, we seem to understand that the use of symmetric encryption, it does not work, so we need to use asymmetric encryption 👇

Asymmetric encryption

Based on the above analysis, symmetric encryption does not work, so let’s comb through asymmetric encryption. The TLS/1.2 handshake is a TLS/1.2 handshake process. The TLS/1.2 handshake process is a TLS/1.2 handshake process.

In asymmetric encryption, the point we need to make clear is 👇

  • There is a pair of secret keys, “public key” and “private key”.
  • Public key encryption content, only the private key can unlock, private key encryption content, all the public key can unlock, here said ** “public key can unlock, refers to a pair of secret keys” **.
  • The public key can be sent to all clients, while the private key is stored only on the server.

Main workflow

The TLS 1.2 handshake process can be divided into five main steps 👇

Image content fromSea line in the boat

Step (1)

The Client initiates an HTTPS request to connect to port 443. This process can be understood as “public key request process” **.

Step (2)

After receiving the request, the Server encrypts the digital certificate (also known as a public key certificate) with the private key of the third-party organization and sends the digital certificate to the Client.

Step (3)

  • After the browser is installed, it automatically carries some authoritative third-party public keys and uses the matching public keys to decrypt digital signatures.
  • According to the rules of signature generation, local signature generation is carried out for website information, and then the two are compared.
  • If the two signatures match, the authentication succeeds. If they do not match, the certificate fails to be obtained.

Step (4)

After obtaining the “Server public key”, the Client randomly generates a “symmetric key”, encrypts the “symmetric key” with the “Server public key” (the public key of the certificate), and sends the “symmetric key” to the Server.

Step (5)

The Server decrypts the message using its private key, and thus obtains a symmetric key. Both servers have the same symmetric key.

The symmetric key can then be used to encrypt/decrypt the transmitted information, as shown in the figure above 👇

  • The Client user uses this “symmetric key” to encrypt ‘plaintext B’ and send it to the Server.
  • The Server uses the ** symmetric key ** to decrypt the message and get the plaintext B.

Then consider the question, “What if the public key is obtained by an intermediary?”

The following image is from LeoCoder

Middleman acquisition of public key“The public key that the client might get is fake. What’s the solution?”

Third Party authentication

The client cannot tell whether the public key returned is from a middleman or from the server. This is the root of the problem. Is there some specification that can make both the client and the server follow some convention? That is through ** “third party authentication” **

In HTTPS, this problem is solved by “certificate” + ** “digital signature” **.

The only difference here is that if the encryption algorithm for website information is MD5, after MD5 encryption,“It is then encrypted again using the private key of a third party to generate a digital signature.”.

In this case, the digital certificate contains two particularly important pieces of information 👉** “public key of a website + digital signature” **

Once again, we assume that the middleman intercepts the server’s public key and replaces it with his own public key. Because of the existence of digital signatures, the client verifies that the digital signatures do not match, thus preventing the problem of the middleman replacing the public key.

So how does the client compare the two digital signatures?

  • Browsers install public keys from authoritative third-party certification bodies such as VeriSign, Symantec, and GlobalSign.
  • When verifying a digital signature, the system directly obtains the local public key of the third party and decrypts the encrypted digital signature of the private key to obtain the real signature.
  • Then, the client generates the signature using the signature generation rule to check whether the two signatures match. If the two signatures are authenticated, the certificate fails to be obtained if they do not match.

Function of digital signature

Digital signature: Encrypts web site information using a specific algorithm, such as MD5, and then encrypts it using the server’s private key to form an “encrypted digital signature”.

A third-party certification body is an open platform that a middleman can access.

If there is no digital signature, this can have the following situation 👇

As we know from the above, if ** “just encrypt the website information with a third-party private key” **, it will still be spooked.

Since there is no authentication, the middleman also applies to the third-party authentication authority and then intercepts and replaces all the information with its own. The client can still decrypt the information and cannot determine whether it is the server’s or the middleman’s, resulting in data leakage.

“Summary”

  • HTTPS uses THE SSL/TLS protocol for encrypted transmission
  • General process:
  • The client to the server’s public key (right), then the client randomly generated a * * “secret key” symmetric encryption, use “the public key encryption, transmission to the server, the server by decrypting again to get the” symmetrical secret key “, following all the information through the symmetrical secret key “* *” encrypt decrypt, complete the whole process of HTTPS.
  • “Third party authentication”, and most importantly “digital signature” **, avoids obtaining a public key that is a man in the middle.

How do I recover an SSL connection?

You can use the session ID or session ticket to restore the disconnected SSL connection.

Through the session ID

In the form of session ID, each session has a number. When the conversation is interrupted and the next time the connection is reconnected, as long as the client gives this number and the server has the record of this number, the two parties can continue to use the previous key without generating a new one. All browsers currently support this approach. However, the disadvantage of this approach is that the session ID can only exist on one server, and if our request is load balanced to another server, the session cannot be resumed.

Through the session ticket

Session ticket is sent by the server to the client in the last session. The session ticket is encrypted and can only be decrypted by the server. The ticket contains the session information, such as the key and encryption method. In this way, regardless of whether our request is transferred to another server, when the server decrypts the ticket, it will be able to retrieve the information of the last conversation without regenerating the conversation secret key.