My girlfriend is also a software engineering major, because she is going to graduate soon, so she recently studied programming while doing graduation projects. The other day she asked me about HTTPS, and I was going to throw her an online tutorial. After thinking about it, most of those articles introduced the concept directly, which was not very friendly to the novice, so I simply explained it to her in person and arranged a question-and-answer record by the way.

Q1: What is HTTPS?

BS: HTTPS is secure HTTP

The content in HTTP is transmitted in plaintext. HTTPS encrypts the content to ensure information transmission security. The last letter, S, refers to the SSL/TLS protocol, which is midway between HTTP and TCP/IP.

Q2: What do you mean by information transmission security

BS: The security of information transmission has three aspects:

  1. The direct communication between the client and the server can only be understood by the client. Even if the third party gets the data, it can not understand the true meaning of the information.
  2. A third party may not understand the data, but it can XJB change, so the client and server must be able to determine whether the data has been changed.
  3. Clients must avoid man-in-betweenattacks, in which no third party can impersonate a server other than a real server.

Unfortunately, the current HTTP protocol does not meet any of these three requirements.

Q3: Is it tiring to meet so many requirements one by one?

BS: No, the third requirement can be ignored

Yes, I’m not kidding. You can leave the third requirement alone for now, because it’s actually part of the first requirement. We all know that encryption requires a password, a password is not just a simple thing, but also needs to be negotiated through communication between two parties. Therefore, a well-designed encryption mechanism will inevitably prevent third party interference and forgery. When we understand the specific principle of encryption, we can naturally check whether it meets: “any third party can not pretend to be a server” this requirement.

Q4: How do you encrypt information

BS: Symmetric encryption is used

Symmetric encryption can be understood as a reversible transformation of the original data. For example, Hello can be converted to Ifmmp. The rule is that each letter is changed to its last letter in the alphabet. The secret key here is 1.

With the introduction of symmetric encryption, there are two additional steps in the HTTPS handshake process to pass the symmetric encryption key:

  1. Client: Hello, I need to initiate an HTTPS request
  2. Server: Ok, your secret key is1.

Having mentioned symmetric encryption, there is also asymmetric encryption. The idea is very simple, it’s very easy to compute the product of two primes, but it’s very difficult to decompose it into a product of two primes, it’s very complicated. Asymmetric encryption has two secret keys, a public key and a private key. Only the private key can decrypt what is encrypted by the public key, and only the public key can decrypt what is encrypted by the private key. Generally, we keep the server to ourselves. The private key that is not published is called private key, and the key that is available to all is called public key.

Using symmetric encryption is generally much faster and less stressful on the server than using asymmetric encryption.

Q5: How is the symmetric secret key transmitted

The server directly returns the plaintext symmetric encryption key is not secure. If a listener gets hold of the key, doesn’t that tell you what the client and server are talking about?

BS: Uses asymmetric encryption

Therefore, the symmetric secret key cannot be transferred in plain text, and a new symmetric encryption algorithm cannot be used to encrypt the original symmetric secret key. Otherwise, the new symmetric secret key cannot be transferred either. This is the chicken and egg paradox.

Asymmetric encryption is introduced here. The characteristics of asymmetric encryption determine that the contents encrypted by the server with the private key are not real encryption, because the public key is owned by everyone, so the ciphertext of the server can be parsed by everyone. But the private key is only in the server’s hands, which provides two huge advantages:

  1. The content sent from the server can’t be forged, because no one else has a private key, so it can’t be encrypted. The consequence of forced encryption is that the client cannot unlock it with the public key.
  2. Anything that anyone encrypts with a public key is perfectly secure because only the server has the private key, which means only the real server can see the encrypted text.

So the problem of transferring a symmetric secret key is solved: instead of being sent by the server, the secret key is generated by the client and proactively told to the server.

So when asymmetric encryption is introduced, the HTTPS handshake process remains a two-step process, with slightly different details:

  1. Client: Hello, I need to make an HTTPS request. Here is my secret key.
  2. Server: Ok, I know your key. I’ll use it for transmission.

Q5: How is the public key transmitted

You still don’t seem to have solved the chicken-and-egg problem. You said the client uses the public key to encrypt the symmetric key when sending the request, how does the public key get transmitted?

BS: Just encrypt the public key…

Every server that uses HTTPS must register a certificate with a specialized certificate authority that stores the public key encrypted with the authority’s private key. The client decrypts it using the public key of the authority.

The HTTPS handshake phase now has four steps:

  1. Client: Hello, I want to make an HTTPS request, please give me the public key
  2. Server: Ok, here is my certificate with the encrypted public key inside
  3. Client: after successful decryption, tell server: here is my symmetric secret key (encrypted with public key).
  4. Server: Ok, I know your key. I’ll use it for transmission.

Q6: Are you kidding me…

How does the public key of the authority transmit?

BS: In the computer

The public key doesn’t need to be transmitted, but is built directly into the factory Settings of each operating system (or browser). One reason why we don’t build the public key of each server into the computer is because there are too many servers to store it. On the other hand, the operating system does not trust you, why do you say you this is Baidu/Taobao certificate?

So companies have to go to an authority first, get a certificate, and then the operating system will only store the public key of the authority. Because of the limited number of authorities, operating system vendors are relatively easy to manage. If this authority is not authoritative enough and XJB issues certificates, it will disqualify him like poor Votong…

Q7: How do I know if the certificate has been tampered with?

You said the server returns a certificate the first time, the encrypted public key, so how do I know the certificate is reliable?

BS: Passes the hash value of the information along with the information

We all know what hashing is, it compresses data, and if you look at it from a functional point of view, no matter how complex the data is (the domain can be very large), the hash algorithm will give you a value, and the value will be in some particular range (much smaller than the domain). The same data will have the same hash result, different data will have different hash result, but there is a small probability of repeated, this is called hash conflict.

To ensure that the original certificate has not been tampered with, we can pass the certificate hash along with the certificate. Since the third party cannot parse the data, it can only be changed by XJB, so the modified data cannot pass the hash after decrypting.

For example, the public key would be the previous example Hello, and let’s assume that the hash algorithm is to get the last character of the string, so the hash value of Hello would be O, so the encrypted string would be Ifmmpp. Although the public key is known, everyone can decrypt it and change it, but because there is no private key, it cannot be encrypted correctly. Therefore, the data it returns to the client is invalid data, which will be garbled when parsed with the public key. Even if the attacker happens to be able to parse through multiple attempts, the hash check will not pass.

Q8: Does this prevent third parties from posing as servers

BS: Maybe

First of all, the content delivered by the real server cannot be tampered with by others. They have an authoritative public key, so they can decrypt it, but they don’t have a private key, so they can’t encrypt the decrypted information. The unencrypted or incorrectly encrypted information cannot pass the hash verification after being decrypted by the client using the public key.

However, if you are not asking for a real server in the first place, but an attacker, there is every opportunity for a man-in-the-middle attack. We know that at the first handshake the server will issue a certificate to prove its identity, which will be decrypted using the public key preset on the device. So either an authenticated certificate is encrypted with an authority’s private key and decrypted by the authority, or it is encrypted with a non-authority’s private key and decrypted without a public key.

Therefore, if a root certificate from an authority is accidentally installed, such as a malicious certificate provided by a hacker, a preset public key is added to the device. In this case, the certificate encrypted with the malicious private key can be parsed. So do not casually install root certificates, this is tantamount to those malicious certificates left a door.

Of course, every coin has two sides. We know that Charles can debug HTTPS communication. Its principle is that the user needs to install the root certificate of Charles, and then our requests will be broached to the Charles server, and the Charles certificate issued by it can be parsed correctly. Charles, on the other hand, acts as a client, getting the correct HTTPS certificate from the real server and using it for subsequent communication. Fortunately, Charles is not rogue software, or its private key once leaked, will have a big impact on users.

As an example, there are multiple types of certificates. The most expensive one is EV (Extended Validation), which requires multiple documents such as the company’s business license to apply for human review. The obvious benefit is that the company name can be accurately displayed on the left side of the browser address bar, such as the Bitbucket website:

This is normal when the client is directly connected. But if you use a Charles agent, the client gets a Charles certificate, so it becomes:

Q9: Does HTTPS handshake affect performance

Does TCP’s three-way handshake and HTTPS’s four-way handshake affect performance?

BS: Definitely, but it’s acceptable

First of all, HTTPS is definitely a bit slower, with time spent between the two SSL sets and certificate reading and verification, and the encryption and decryption time of the symmetric algorithm is almost negligible.

And if not the first handshake, subsequent requests do not require a full handshake. The client can send the last encryption directly to the server for quick recovery. For details, see the SSL/TLS protocol diagram.

In addition, the SSL handshake time is not only used to transmit encrypted information, but also to communicate HTTP2 compatibility between the client and the server. Therefore, there is no performance overhead to switch from HTTPS to HTTP2.0, and it can save a lot of time down the road thanks to HTTP2.0’s multiplexing and other technologies.

If HTTPS2.0 is the goal, the performance cost of HTTPS is much smaller than the security improvements it provides.

conclusion

I believe the above nine questions should be enough to help newcomers understand HTTPS, but this is just the basic concept, and the use of HTTPS (such as some specific issues on iOS) needs to be tried and studied.

I have a solid computer foundation, but I have little project experience. I can work as an intern for more than 6 months. If there is any company in Beijing that wants to hire interns, please feel free to contact me. The direction is not limited, and the front and back ends can be trained. IOS is better (I will teach it by myself).