1. Introduction

HTTPS is a common and inevitable question in the interview process. But when asked why HTTPS is secure, many people simply reply: It’s encrypted! And then it was over! You didn’t answer anything at all!

2. Why am I writing this article?

1. Some articles on the Internet are not comprehensive or easy to understand, and some even have deviation in understanding, which may cause more confusion for learners

1. 2. How to Lose weight

All right, let’s cut to the chase

3. Before I say HTTPS, let me first explain why HTTP is not secure. How do you show that?

HTTP is in clear text, but I don’t have any security issues, so I don’t need HTTPS!

I can only offer the following explanations

1. You’re lucky you weren’t targeted

2. Your site doesn’t have much traffic, so you’re not worth it

3. Your account, password and other private information has been stolen, and you still don’t know it

So let me show you why HTTP is not secure

Everyone has connected to the public wifi, here I use the computer to open a hotspot, and then use the mobile phone to connect to the hotspot, and then use the mobile phone to access an HTTP login interface, and enter the account password to log in, I use wireshark on the computer to capture packets

Step 1: Open the hotspot and wireshark to capture packets

Step 2: Connect your phone to a hotspot

Step 3: Mobile phone access the login page and log in

Step 4: Check the bag caught by the computer

Is the problem quite clear? Your account and password are all transmitted in plain text (the password is transmitted after front-end MD5), and the wifi in the middle (to be exact, router) can be intercepted and checked directly. If you can intercept and check, can you tamper with it? The answer, of course, is yes

Now imagine if your wifi connection or even your local carrier has problems (for profit), he can do whatever he wants

Such as:

1. Stealing your private information

2. Modify the message returned by the server, add a JS AD file, and the ads will fly everywhere

3. Modify the return message of the server to redirect you directly to a phishing or advertising site. Think about it if you have ever encountered a similar situation: you opened Baidu, but redirected to a “you know” site

4. Modify the information returned by the server and suddenly find a “beautiful woman” in the corner of the website you normally visit.

Suffice it to say that HTTP itself does have security issues. If your answer is still no, read the above a few times and refresh your mind!

4. Why is HTTPS secure? How did he keep it safe?

Think of security, we will first think of, that encryption bai! So this leads to the first question, how to encrypt before introducing how to encrypt the problem, let’s briefly introduce the general types of encryption

General types of encryption:

  1. Irreversible encryption. Such as MD5, SHA, and HMAC

    Typical use: the total password can not be saved to the database, so the general encryption stored, as long as the user’s input through the same encryption algorithm to compare it will know whether the password is correct, so there is no need to reverse

  2. Reversible encryption
    • Symmetric encryption. For example, AES, DES, 3DES, IDEA, RC4, RC5, and RC6

      Typical use: encrypt and decrypt with the same password, too common, I use the password to encrypt the file to send you, you can only use my password to unlock

    • Asymmetric encryption (that is, public and private keys). For example, RSA, DSA, and ECC

      Typical usage: 1. Encryption (to ensure data security) Use a public key to encrypt data and a private key to decrypt data. 2. Authentication (for identity verification) uses a private key to sign the signature, and a public key to verify the signature.

After introducing the types of encryption, how to encrypt

Is it possible to use irreversible encryption?

First of all irreversible encryption can be directly excluded, do not know why, you can think about their purpose is what, if you do not know, you can hit 120

Is symmetric encryption possible?

If both parties hold the same key and no one else knows it, the communication security of the two parties can be guaranteed of course. However, the biggest problem is how to make the key known to both parties while not being known by others. Think about it: Is it possible that no matter how it is transmitted, it can be intercepted in the middle, and if the key is intercepted, other security is out of the question. It seems that pure symmetric encryption cannot solve HTTP security problems

Is asymmetric encryption (RSA) possible?

Imagine: if the server to generate public and private key, and then give the client public key clear (there is a problem, said below), the client after data transfer with the public key encryption, the server with the private key to decrypt the line, it seems can guarantee the browser to the server channel is safe, the server to the browser channel how to ensure safety?

Since a pair of public and private keys can be guaranteed, if the browser itself also generates a pair of public and private keys, and then send the public key in plaintext to the server, regardless of the plaintext transfer public key problem, then can not secure communication, indeed can! However, HTTPS itself does not work that way. The main reason is that asymmetric encryption is time-consuming, especially when encrypting and decrypting large data, but there are other reasons. Since asymmetric encryption is time consuming, symmetric encryption should be considered

Is it possible to use asymmetric encryption + symmetric encryption? (Yes, yes, no, because there is no other way.)

As mentioned above, the browser has the public key of the server, so the browser generates a key, and encrypts it to the server with the public key of the server, and then the server and the browser take this key to communicate in a symmetric encryption way. Perfect!

The public key of the server is passed in plain English. What is the possible problem?

If the service side when convey clear public key to the browser by hackers to intercept down, then the public key substitution in the packets into their spurious public key (of course he has its own private key), the browser itself is don’t know the public key of true and false, so the browser or silly according to the previous step, generated symmetric key, then use false public key encryption is passed to the server, At this time, the hacker intercepted the message, and then decrypted it with his private key, got the symmetric key, and then passed it to the server, so undetected, the symmetric key was intercepted by the hacker, and then the subsequent communication is actually all exposed to the hacker.

God, we can’t do this, we can’t do that. What do we do?

How to ensure that the public key received by the browser is the public key of the website

In real life, if you want to prove that some ID number must be Xiaoming, how to do? Look at your ID card. Here the state agency plays the role of “public trust”, the identity card is issued by it, its own authority can prove a person’s identity information. Can the Internet make such a public trust organization? Give websites an “ID card”? Of course, this is usually referred to as a digital certificate

What is a digital certificate? What does a certificate contain?

The identity card can be trusted because the country behind it, but how can a digital certificate be trusted? In this case, apply for the Certificate Authority (CA). Do id needs to fill in his all sorts of information, what does CA orgnaization apply for certificate to need? There should be at least the following items

  1. Website domain name
  2. Certificate holder
  3. Validity of certificate
  4. Certification Authority
  5. Server public key (primary)
  6. The hash algorithm for signing

So how do certificates get safely to the browser, and how do they prevent tampering? Just stamp the certificate, which brings up another concept: digital signature

What is a digital signature? What is the signing process

The signing process is actually quite simple

  1. The CA has private and public keys with asymmetric encryption
  2. The CA hashes the plaintext information of the certificate
  3. The hash value is encrypted with a private key to obtain a digital signature

So, to sum up: a certificate issued by a CA contains (the plaintext of the certificate content + the signature)

After the browser receives the certificate from the service, it gets the plaintext and signature of the certificate. How can it verify whether the certificate has been tampered with?

As you know, private key signature, public key check. The signature in the certificate is signed by the CA authority with the private key, so I just need to use the PUBLIC key of the CA authority to verify the signature.

Remember what’s in the clear text of the certificate, but if you don’t remember, look up there.

  1. Get the plaintext hash algorithm in the certificate and hash the plaintext to get A
  2. Decrypt the signature with the CA’s public key to obtain B
  3. Compare A and B. If they are the same, the certificate is not tampered with. Otherwise, the browser displays A message indicating that the certificate is not trusted
Do you see a problem? Where do YOU get the CA’s public key

This is simple, CA authority is not many, so the browser is built into the public key information of the major CA bodies

Just to summarize

1. If the certificate is tampered with, the browser displays an untrusted message and terminates communication. If the verification succeeds, the public key is ok and has not been tampered with

2. If the public key is not tampered, the symmetric encryption key generated by the browser is encrypted with the public key and sent to the server, and only the private key of the server can be unlocked. Therefore, it is impossible to intercept the symmetric key

3. A hacker could still intercept packets, but they were all encrypted with symmetric keys, and he could tamper with them, but there was no point in doing the dirty work

conclusion

Of course, the HTTPS encryption process itself is a bit more complicated than that, but the main process is basically the same. Next time you’re asked why HTTPS is secure, don’t simply say “because it’s encrypted.” This is a very powerful question, so don’t waste it. The above are some personal interpretations: I can justify myself, but I don’t guarantee that I am right. Please diagnose for yourself

A few questions

  1. Why do Charles and other packet capture tools or browser consoles see HTTPS returns in clear text?
  2. Why do I need to hash a digital signature once?

Leave a comment if you know about it, or search for it if you don’t, and of course, you can follow the details of HTTPS handshakes in my next series of in-depth articles. Bye-bye!