Author: BestSwifter juejin.cn/post/684490…
Q1: What is HTTPS?
BS: HTTPS is a secure HTTP
The CONTENT in HTTP is transmitted in plain text. HTTPS encrypts the content to ensure the security of information transmission. The last letter S refers to SSL/TLS, which is located between HTTP and TCP/IP.
Q2: What do you mean by secure transmission of information
BS: The security of information transmission has three aspects:
1, client and server direct communication only
2, some can understand, even if a third party gets the data can not understand the true meaning of the information.
3, although the third party does not understand the data, but can XJB change, so the client and server must have the ability to determine whether the data has been modified.
4. Clients must avoid man-in-the-middle attacks, in which no third party can impersonate a server other than the real one.
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
Yeah, I’m not kidding, but you can ignore the third requirement for the moment, because it actually falls under the first requirement. We all know that encryption requires passwords, and passwords do not fall all over the world, but also need to be negotiated through communication. Therefore, a well-designed encryption mechanism will inevitably prevent interference and counterfeiting by third parties. Such as understand the specific principle of encryption, we can naturally check whether to meet: “no third party can impersonate the server” this requirement.
Q4: How do you encrypt messages
BS: Use symmetric encryption
Symmetric encryption can be understood as a reversible transformation of the original data. For example, Hello can be converted to Ifmmp, and the rule is that each letter becomes the letter after it in the alphabet. The secret key here is 1, and the other party can restore the original message Hello by taking Ifmmp.
With the introduction of symmetric encryption, the HTTPS handshake process has two more steps to pass the symmetric encryption secret key:
1. Client: Hello, I need to initiate an HTTPS request
Server: Ok, your secret key is 1.
Symmetric encryption is mentioned, then there is asymmetric encryption. The idea is simple. It’s easy to compute the product of two primes, but it’s hard to reverse it into a product of two primes. Asymmetric encryption has two secret keys, a public key and a private key. Only the private key can decrypt the contents encrypted by the public key, and only the public key can decrypt the contents encrypted by the private key. Generally, we keep the private key of the server and do not publish it to the public as private key, and the public key that can be obtained by all people is called public key. Click to see the details of the HTTPS authentication process illustrated.
Symmetric encryption is generally much faster and less computationally taxing on the server than asymmetric encryption.
# # #
Q5: How to transfer symmetric secret keys
Is it unsafe for the server to return plaintext symmetric encryption keys directly? If a listener gets hold of this key, doesn’t it tell the client and server about subsequent communication?
BS: Use asymmetric encryption
That’s right, so you can’t pass a symmetric key in plaintext, and you can’t use a new symmetric encryption algorithm to encrypt the original symmetric key, otherwise the new symmetric key also can’t be transmitted, which is the chicken-and-egg paradox.
Asymmetric encryption is introduced here. The feature of asymmetric encryption determines that the contents encrypted by the private key of the server are not really encrypted, because the public key is owned by all, so the ciphertext of the server can be parsed by all. But the private key is only in the hands of the server, which brings two huge advantages:
1. The content delivered by the server cannot be forged, because no one else has a private key, so it cannot 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 absolutely safe, because only the server has the private key, meaning that only the real server can see the text being encrypted.
So the problem of transferring symmetric keys is solved: instead of being delivered by the server, the key is generated by the client and told to the server.
So when asymmetric encryption is introduced, the HTTPS handshake is still a two-step process, but the details change slightly:
Client: Hello, I need to make an HTTPS request. This is my secret key.
Server: OK, I know your secret key, I will use it to transmit.
# # #
Q5: How does the public key transfer
You still don’t seem to have solved the chicken-and-egg problem. You said the client sends a request to encrypt the symmetric secret key with the public key. How does the public key transfer?
BS: Encrypt the public key…
Each server that uses HTTPS must register a certificate with a dedicated certificate authority that stores a public key encrypted with the authority’s private key. In this way, the client can decrypt it with the public key of the authority.
The HTTPS handshake is now a four-step process:
1, client: hello, I want to make an HTTPS request, please give me the public key
Server: Ok, here is my certificate with the encrypted public key inside
3, the client: after decryption success tell the server: this is my (encrypted with the public key) symmetric secret key.
4. Server: OK, I know your secret key, and I will use it for subsequent transmission.
# # #
Q6: Are you kidding me…
What about the public key of the authority?
BS: It’s in the computer
This public key does not need to be transmitted and is built directly into the factory Settings of every operating system (or browser). One reason you don’t have the public key of every server built into your computer is because there are too many servers to store. On the other hand, the operating system does not trust you, with what you say you this is baidu/Taobao certificate?
So each company has to go to the authority to authenticate and apply for 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, XJB issues a certificate and disqualifies him, like poor Vaughton…
Q7: How do I know if the certificate has been tampered with?
You say the server will return a certificate the first time, that is, an encrypted public key. How do I know the certificate is reliable?
BS: Passes the hash value along with the message
We all know that the hash algorithm can compress data, and if you look at it from a function point of view, no matter how complex the data is (the domain can be very large), the hash algorithm will get a value that is in a certain range (much smaller than the domain). The hash result of the same data must be the same, but the hash result of different data is generally different, but there is a small probability of repetition, which is called hash conflict.
To ensure that the original certificate has not been tampered with, we can pass the certificate hash at the same time as the certificate. Since the third party cannot parse the data, only XJB changes, then the modified data after decryption, it is impossible to pass the hash.
For example, the public key is the previous example Hello, we assume that the hash algorithm is to get the last character of the string, so the hash value of Hello is O, so the encrypted string is Ifmmpp. Although the public key is known and anyone can decrypt it and tamper with it, there is no private key, so it cannot be properly encrypted. Therefore, the data it returns to the client is invalid and garbled after being parsed with the public key. Even if an attacker happens to be able to parse through multiple attempts, it will not pass hash check.
# # #
Q8: This can prevent a third party posing as a server
BS: Maybe
First of all, the real server delivered content, can not be tampered with by others. They have the authority’s public key, so they can decrypt it, but because there is no private key, the decrypted information cannot be encrypted. If unencrypted or incorrectly encrypted information is decrypted by the client using the public key, it cannot pass hash verification. Click to see the details of the HTTPS authentication process illustrated.
However, if you’re not asking for a real server in the first place, but an attacker, he has every opportunity for a man-in-the-middle attack. We know that during the first handshake the server will issue a certificate to prove its identity, which will be decrypted using a public key preset on the device. So either the authenticated certificate is encrypted with the authority’s private key and decrypted with the authority, or it is encrypted with the non-authority’s private key and the public key cannot be found and decrypted.
Therefore, if the root certificate of a non-authoritative authority, such as a malicious certificate provided by a hacker, is installed by accident, then the device has a preset public key, and the certificate encrypted with the malicious private key can be resolved normally. So do not install a certificate, it is tantamount to leave a door open for those malicious certificates.
Of course, every coin has two sides. We know Charles can debug HTTPS communication. Its principle is that the user needs to install Charles root certificate, and then our request will be proxy to Charles server, so that the Charles certificate issued by Charles can be correctly parsed. Charles, on the other hand, acts as the client and gets the correct HTTPS certificate from the real server for subsequent communication. Fortunately, Charles is not a rogue software program, and the disclosure of its private key could have a significant impact on users. Click to see the details of the HTTPS authentication process illustrated.
As an example, there are many types of certificates. The most expensive one is Extended Validation (EV), which requires multiple documents such as the company’s business license to apply for manual review. The benefits are also obvious, as the company name can be accurately displayed on the left side of the browser address bar, such as the official website of Bitbucket:
Cannot be displayed in proxy mode
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 slower, and the time is spent between the two sets of SSL and the certificate reading and verification, while the encryption and decryption time of the symmetric algorithm is negligible.
And if it is not the initial handshake, subsequent requests do not require a full handshake. The e client can send the last encryption status directly to the server for quick recovery. For details, see the graphic HTTPS authentication process details.
In addition, the SSL handshake time is not only used to transmit encrypted information, but also to communicate HTTP2 compatibility between the client and server. So switching from HTTPS to HTTP2.0 has no performance cost, and instead benefits from technologies such as multiplexing of HTTP2.0, which can save a lot of time later on.
If HTTPS2.0 is the target, HTTPS’s performance loss is much smaller than the security gain it provides.
conclusion
The above nine questions should be enough to help newcomers understand HTTPS, but they are just basic concepts, and there is still a lot of experimentation and research to be done about HTTPS usage (for example, some specific issues on iOS).
Read more on my blog:
1.Java JVM, Collections, Multithreading, new features series tutorials
2.Spring MVC, Spring Boot, Spring Cloud series tutorials
3.Maven, Git, Eclipse, Intellij IDEA series tools tutorial
4.Java, backend, architecture, Alibaba and other big factory latest interview questions
Life is good. See you tomorrow