This is the 5th day of my participation in the August More Text Challenge.

preface

Open your own web page only to see another weird page? Have a lot of weird pop-ups on your web page? I don’t know if you have encountered this kind of problem. You probably know that this is because the web page has been hijacked, so you need to have a certificate and use HTTPS, so what is HTTPS? As a front-end engineer, you need to deal with a lot of network requests in your daily work, and it is necessary to understand some knowledge about network. Today, SSH, SSL, and HTTPS are introduced.

The defect of HTTP

HTTP is an application layer protocol running on TOP of TCP, which is the basis of Web applications. HTTP protocol is essentially a process in which the client sends a request to the server and gets various data back from the server.

The HTTP protocol is flawed. Because it does not have encryption function, it is used to transport all kinds of data in plaintext and does not verify the integrity of packets. In the process of network request, many network routers will forward your request, and every device may be intercepted or tampered with data. And HTTP protocol does not verify the identity of the communication parties, may encounter camouflage.

If the communication process of HTTP protocol is compared to the process of sending A Courier, A person sends A Courier to B, this Courier will pass through many hands (network router). Each Courier can open the package to see what’s inside (plaintext shipping), take away or put in strange things (no verification of packet integrity). You can even replace your original delivery with something else (no verification of the identity of the communication partner, encounter camouflage).

In view of the defects of HTTP protocol, there are some schemes to solve them.

  • Plaintext transport: Uses the RSA algorithm to transmit data in asymmetric encryption.
  • Packet integrity: A digital signature is generated using a key. Data cannot be modified without disclosing the key.
  • Verify the identity of both parties: Verify the identity of both parties through digital certificates.

Symmetric encryption

At the beginning, symmetric encryption is used, that is, A uses the key S for encryption, and B decrypts the information through the same key S. So that only those who know the key S can know what message is being transmitted.

However, there is A big problem with this approach: how can A safely send the key S to B?

The answer is that A sends A key to B, and S goes through A separate secure message channel (i.e. no one can listen to the communication in that channel). But this brings more problems: first, there are separate secure channels, but the bandwidth of the secure channel is limited, and it cannot be used to send the original message directly. Second, A and B cannot be sure how long their key S can be kept secret (that is, hidden from others) and when to exchange A new key S.

Asymmetric encryption

In order to solve the problems of symmetric encryption, mathematicians designed an asymmetric encryption algorithm.

Asymmetric encryption algorithms consist of a pair of public and private keys. Public and private keys can encrypt and decrypt each other, and because encryption and decryption use two different keys, this algorithm is also called asymmetric encryption algorithm. Data encrypted with a public key can only be unlocked with the corresponding private key, and vice versa. Let’s look at how an asymmetric encryption algorithm solves the problem of how A can safely give S to B.

We treat A as the client and B as the server. Both A and B generate A key pair, and they publish their public keys on the Internet, making them available to everyone. So, A gets B’s public key B, and B gets A’s public key A. When user A wants to send A message to user B, user A uses USER B’s public key to encrypt the message and sends the encrypted ciphertext to user B. Because only private key B can unlock the information encrypted with public key B, other people on the Internet link cannot view and change the information. B gets the message and decrypts it with the private key B to ensure the security of the communication.

If USER B sends A message to user A, user A encrypts the message using user A’s public key, and user A decrypts the message using its private key.

So again, how do you know that public key B belongs to B? What if there’s a middleman on both sides pretending to intercept information?

As shown in the figure above, a middleman M replaces his own public key M when the client and server obtain the other’s public key, so that both sides can obtain information and then tamper with it. Because the client and server cannot verify that the public key is from each other, they cannot authenticate it if it is replaced. Therefore, a digital certificate mechanism was introduced.

SSH

Before we get to digital certificates, we’re going to have a problem proving that the public key really came from the source target, right? So if client A wants to send A message to server B, client A generates A key pair. If client A personally places its public key A on server B, then the public key A must be sure that it came from client A.

Familiar with? When we use Github, if we want to upload code, in addition to the account password login, there is also SSH. We need to generate a pair of key pairs on our computer, and then put our public key on Github, so that we can use SSH to log in to Github, and then we can use SSH to pull or push the code.

SSH (Security Shell), developed by the Network Working Group of the IETF, is a reliable protocol designed to provide Security for remote login sessions and other Network services.

SSH began as a program on UNIX systems and quickly expanded to other operating platforms. SSH is a tunnel that protects data from leakage and tampering and provides a secure transmission and application environment for shell. Specifically, it allows you to securely execute instructions from another UNIX machine remotely.

Note: SSH is just a network application for host users to log in and securely share data. After SSH is used, a secure channel is established between the client and the server. In this channel, the client can use shell commands to operate the server securely.

SSL

SSL differs from SSH in that it is Secure Sockets Layer, a security protocol that Netscape introduced with the first version of the Web browser. When a browser accesses a URL that begins with https://, the browser uses HTTP over an SSL connection. SSL encrypts data before transmission, ensuring the security of user data on the transmission link.

SSL consists of two sub-protocols:

  • SSL Record Protocol (SSL Record Protocol) : describes how SSL packets are encapsulated. Located at the session layer of the OSI seven-tier model, it establishes and manages sessions for users on different machines.

  • SSL Handshake Protocol: Describes how the communication parties negotiate to determine the algorithm and the key used by the algorithm. It encrypts and decrypts network connections between them at the presentation layer, the next layer of the SESSION layer of the OSI seven-layer model.

The digital certificate

So the problem is again, we visit the page everyday, from the server to get the data, the server can not like SSH to each client personally issued a public key. So it’s back to square one: because the client and server cannot verify that the public key is from each other, they cannot verify that it is replaced either. So there’s this thing called digital certificates.

Here you can see ruan Yifeng’s digital certificate of this article

The public key of the server cannot be verified on the client. Therefore, a third-party organization is required to notarize the public key of the server. How to do notarization?

When the server applies for a certificate from the ca, the server sends its website information and the public key of the server to the CA. The CA generates a certificate based on the website information, certificate information, digital signature of the CA, and the public key of the server. It is important to note that the website information, certificate information, server public key and other information in the certificate are stored in clear text, so the problem comes, since the clear text is not secure in Internet transmission, then how to prove that these things have not been tampered with? That’s where digital signatures come in.

A digital signature

A digital signature is a string of values calculated using a specific hash algorithm. The plaintext information, such as website information, certificate information, and server public key information, can be calculated using a specific hash algorithm to obtain a hash value. The hash value is the fingerprint of the certificate, which is the unique identifier.

When the client obtains the certificate, it will use the same hash algorithm to calculate the plaintext information, so that it can also get a hash value. If the two are the same, it can prove that the certificate is secure and the information in the certificate is ok. But, again, a middleman intercepts the certificate and changes the plaintext to generate a hash value to replace the original signature. Isn’t that insecure? So, we also need to encrypt this digital signature, with what encryption? Use the CA’s private key for encryption. After encrypting the CA’s private key, only the CA’s public key can be used for decryption. The CA public key is pre-installed in the operating system, which solves the problem of the source of the public key. Even if a third party intercepts the certificate and has the CA’s public key, it can decrypt and tamper with the information, but the digital signature is secure because it cannot be encrypted without the CA’s private key.

Ok, when the client gets the certificate, it will first verify whether the certificate is from a trusted CA institution (whether the certificate is trusted is put in the computer Cert Store in advance, and users can manually add it), if not, it will throw an exception. If it is a trusted CA, the public key of the CA is used to decrypt the digital signature of the CA and obtain a hash value and hash algorithm. The client uses the hash algorithm to calculate the certificate and obtains a hash value. If the certificate is identical, the data integrity of the certificate can be verified. You can use the server public key directly to do things.

Digital Certificates:

HTTPS

HTTPS is Hypertext Transfer Protocol Secure, also known as HTTP over TLS. HTTP over SSL is used for HTTP communication between clients and servers.

In short: HTTPS = HTTP + SSL/TLS

After the server uses the digital certificate to ensure that the client can obtain the real server public key B, we can communicate with HTTP over SSL, namely HTTPS.

In my understanding of asymmetric encryption, there is a one-to-many relationship between the private key and the public key. Because the public key is distributed in large quantities publicly, and the private key is unique, the party with the public key can determine the identity of the party with the private key, while the party with the private key cannot determine the identity of the party with the public key. Therefore, HTTPS is classified into one-way authentication and two-way authentication.

Most HTTPS transfers pages and basically obtains page data from the server. Therefore, the client only needs to confirm the uniqueness of the server. That is, the client verifies the identity of the server to ensure that the page is not hijacked or modified. The problem of middleman hijacking, as described in asymmetric encryption above, is solved by digital certificates.

But does HTTPS only have asymmetric encryption?

Because asymmetric encryption requires encryption and decryption of information, which is very time consuming, symmetric encryption algorithm is about 1500 times faster than asymmetric encryption algorithm! So, after HTTPS authenticates through asymmetric encryption, subsequent communication is carried out through symmetric encryption. Let’s see how this works.

HTTPS unidirectional authentication

Let’s take a look at the HTTPS one-way authentication process:

  1. The client sends information such as the SSL protocol version number, encryption algorithm type, and random number to the server.

  2. The server sends the certificate (including the server public key B and digital signature), SSL protocol version number, encryption algorithm type, and random number to the client.

  3. The client obtains the certificate returned by the server to verify the validity of the server, including:

    • Whether the certificate expires
    • Whether the CA organization is reliable
    • Whether the returned public key can unlock the digital signature in the returned certificate correctly
    • Check whether the domain name in the server certificate matches the actual domain name of the server

    After the authentication passes, the communication continues. Otherwise, the communication is terminated

  4. The client sends the supported symmetric encryption scheme to the server for the server to select.

  5. The server selects the encryption mode with the highest degree of encryption among the encryption schemes provided by the client.

  6. The server returns the selected encryption scheme to the client in plaintext.

  7. After receiving the encryption mode returned by the server, the client uses the encryption mode to generate a random code, which is used as the symmetric encryption key during communication. The client uses the public key B returned by the server to encrypt the random code and sends the encrypted code to the server.

  8. After receiving the encryption information returned by the client, the server uses its private key B to decrypt the information and obtain the symmetric encryption key. In subsequent sessions, the server and client use the symmetric encryption key for symmetric encryption to ensure information security during communication.

HTTPS bidirectional authentication

In addition to HTTPS unidirectional authentication, there is ALSO HTTPS bidirectional authentication, because in some scenarios, the server needs to confirm the identity of the client. The client also needs to generate a client certificate and send it to the server to verify its identity.

HTTPS bidirectional authentication process:

  1. The client sends information such as the SSL protocol version number, encryption algorithm type, and random number to the server.

  2. The server sends the certificate (including the server public key B and digital signature), SSL protocol version number, encryption algorithm type, and random number to the client.

  3. The client obtains the certificate returned by the server to verify the validity of the server, including:

    • Whether the certificate expires
    • Whether the CA organization is reliable
    • Whether the returned public key can unlock the digital signature in the returned certificate correctly
    • Check whether the domain name in the server certificate matches the actual domain name of the server

    After the authentication passes, the communication continues. Otherwise, the communication is terminated

  4. The server asks the client to send its certificate, and the client sends its certificate to the server.

  5. The server authenticates the certificate of the client and obtains the public key A of the client.

  6. The client sends the supported symmetric encryption scheme to the server for the server to select.

  7. The server selects the encryption mode with the highest degree of encryption among the encryption schemes provided by the client.

  8. The server encrypts the selected encryption scheme using public key A of the client and returns the selected encryption scheme to the client.

  9. After receiving the information returned by the server, the client decrypts the information using the private key A of the client and obtains the symmetric encryption mode. Then, the client uses the symmetric encryption mode to generate A random code, which is used as the symmetric encryption key during communication. The client encrypts the information using the public key B returned by the server and sends the encrypted random code to the server.

  10. After receiving the encryption information returned by the client, the server uses its private key B to decrypt the information and obtain the symmetric encryption key. In subsequent sessions, the server and client use the symmetric encryption key for symmetric encryption to ensure information security during communication.

PS: One-way authentication or two-way authentication is determined by the server (default one-way authentication)

conclusion

Don’t be afraid of network hijacking, HTTPS will kill it.

If after reading this article, if it is helpful to you, please click on it and pay attention to it. I wish you a happy life.