https encryption technology implementation principle

The difference between https and http

  • https guarantees that the data transmitted on the network is encrypted, not plaintext. It prevents middlemen from performing packet capture and analysis.
  • https can verify the identity of the server, ensure that the site visited is an official site rather than a fake site, and avoid man-in-the-middle attacks.

Therefore: The core difference between http and https is that https is a secure transmission protocol.

basic concepts

  • The digital signature compresses the source string to extract the information digest, which is often used to verify whether the source string has been tampered with after transmission.
  • Digital certificate contains the digital certificate 明文T, 数字签名Stwo important information, which 明文Tincludes 证书持有者(information such as domain name, domain name owners, etc.), 证书持有者的公钥and other information.
  • CA certificate authority website ID card production center.
  • The root certificate operating system and browser itself will pre-install some trusted certificates, which we call 根证书.
  • There can also be more than one level of certification between the chain of trust certificates. A can trust B, and B can trust C, and so on. We call it 信任链OR 数字证书链, which is a series of digital certificates, starting from the root certificate, through layers of trust , So that the holder of the end entity certificate can obtain the trust of the delegation to prove the identity.

https encryption problem

First of all, we must make it clear that by default, the encryption algorithm is known to both the hacker and the server/client, but the right to know the key is different.

Symmetric encryption

The server sends the key to the client, and both use this key for data encryption at the same time.

Client

key = 服务端通过tcp发送过来的密钥.
request_params = {...};
real_send = custom_encode(key,request_params);
send 到 服务端

Server

received_params
real_received = custom_decode(key,received_params);

Timing diagram using only symmetric encryption
Insert picture description here

As can be seen from the figure, if only symmetric encryption technology is used between the client and the server, it is always necessary to negotiate a secret key (key, such as a random string) for encryption.
During this negotiation process, hackers can intervene in interception. As long as the hacker obtains this key, the subsequent symmetric encryption will be completely invalid.

Asymmetric encryption

In public key cryptography

  • The encryption key PK (public key is public key) is open to the public, and the public key issued by the server received by the client is the same.
  • The decryption key (secret key is the private key or secret key) needs to be kept secret.
  • Encryption algorithm E (encryption) and decryption algorithm D (decrypt) are also public.

In view of the mechanism of asymmetric encryption, we may have this idea:

  1. After the TCP three-way handshake is successful, the server first transmits the public key directly to the browser in plaintext
  2. The browser uses public key encryption before transmitting data to the server, and only the server has the private key can decrypt it. Correspondingly, the browser needs to receive the data sent to it by the server (data encrypted by the server using the private key ), and the browser can use The public key of get is decrypted when the link is established.

However, there is a problem with this process.If the public key is hijacked during transmission, there are the following security risks.

Although the hijacker can intercept the data sent by the browser to the server, the hijacker cannot use the public key to reversely parse the original data sent by the browser. However, the hijacker can decrypt the encrypted data from the server with the public key to obtain some Sensitive information, such as contact information, address, etc. In
other words, through a set of public keys and private keys, the security of transmission in a single direction can be guaranteed .

Look at the timing diagram using only asymmetric encryption

Insert picture description here

To solve this problem, there is a transition plan 通过一组公钥私钥,可以保证单个方向传输的安全性, then we will use it 通过两组公钥私钥,可以保证两个方向传输的安全性.

  1. A website server have used asymmetric encryption 公钥A, 私钥ABrowser has for asymmetric encryption 公钥B, 私钥B.
  2. The browser initiates a request to the website server, and the server sends the public key A to the browser in plaintext.
  3. 公钥BSend the plaintext to the corresponding browser to the server.

at this time:

  • All data transmitted by the browser to the server are 公钥Aencrypted, and the server will 私钥Adecrypt it after receiving it . To ensure 浏览器->服务器the security of the direction.
  • All data transmitted by the server to the browser is 公钥Bencrypted, and the browser 私钥Bdecrypts it after receiving it . To ensure 服务器->浏览器the security of the direction.

It looks rigorous, but this scheme still has a hidden danger 非对称加密解密性能比较低,当传输大文件时,会严重拖慢性能, so https encryption does not use this scheme.

We know that symmetric encryption is fast, but there is no way to solve the problem of secure transmission of keys. Although asymmetric encryption is slow, it can guarantee the security of unidirectional transmission . We can use 对称加密 + 非对称加密the combination method
and minimize 非对称加密解密the number of uses, just taking into account the possible 安全性and 高效性the.

Take a look at this process:

  1. A website server have used asymmetric encryption 公钥A, 私钥A.
  2. The browser initiates a request to the website server, and the server sends the public key A to the browser in plaintext.
  3. A browser generates a random symmetric encryption 密钥X, encrypted with the public key A to the server. Note: !!! for symmetric encryption key is generated by the browser , because from 浏览器the 服务端data in this direction is safe .
  4. After the server gets it, 私钥Adecrypt it to get it 密钥X.
  5. 浏览器, 服务端Owned at the same time 密钥Xand cannot be obtained by a third party 密钥X. After that, all data of both parties are encrypted and decrypted with the key X.

Do you want to sigh for perfection? httpsBasically, this scheme is adopted.

The cracking of the key encryption mechanism is logically possible, but it is impossible at the current computing speed, so we call it-computationally safe.
If quantum computers do appear in the future, then these algorithms will It's time to reshuffle. As a programmer, we must firmly believe that there is no absolutely safe system in the world.

Mastering the stick, but aiming for the yard

Nothing in the world is perfect. The above 对称加密 + 非对称加密combination is arranged.

By using the above combination, the interceptor does not get the browser generated 密钥X. However, the middleman 密钥Xcan arrange you without getting it.
(Because the signal is transmitted in the hardware, the information we transmit can be used by other hosts. Intercept, just like we send a letter to a postman, will the content of the letter reveal the quality of sending hope to the postman.)

  1. It has a website for asymmetric encryption 公钥A, 私钥A.
  2. The browser requests the server, and the server sends the 公钥Aplaintext to the browser.
  3. The middleman hijacks the public key A, saves it, and replaces the public key A in the data packet with its own forgery 公钥B(of course, it also forged the 公钥Bcorresponding one 私钥B, so just do a complete set).
  4. The browser randomly generates one for symmetric encryption 密钥X, encrypts it with 公钥B(the browser does not know that the public key is replaced) and sends it to the server. The middleman continues to hijack the request, 私钥Bdecrypt it 密钥X, and then 公钥Aencrypt it and send it to the server.
  5. After the server gets it, 私钥Adecrypt it to get it 密钥X.

In this way, in the case that neither side will find the abnormality, the middleman gets it 密钥B. This is as disgusting as the ice cream in the refrigerator has been licked.
The root cause of this phenomenon is that the browser cannot confirm that it has received it. the public key is from official or from a third party .
Measures cause of the problem is to solve the problem: 客户端需要具有辨认自己请求的服务器是否为官方服务器,而不是第三方伪造的服务器的能力.

Contact our real life, how can we prove 我是我it? This requires an ID card issued by an authoritative public security residence to prove that it is 真的你.
A public trust agency is needed on the Internet to issue one to the website 身份证. The next deduction: How to prove that the public key received by the browser must be the public key of the website?

Browser verification process:

  1. The server CA机构applies for a certificate and stores CA机构the made for the website 数字证书on the website server.
  2. After establishing a TCP connection, the browser sent from the server to get the certificate, the certificate include: 明文T, 数字签名Sin two parts (. 明文TContains 服务器公钥other important information)
  3. Use the public key of the CA organization to Sdecrypt it S’(because it is an organization trusted by the browser, the browser comes with the public key of the CA organization, and the operating system will also pre-install some trusted root certificates).
  4. Use the hashalgorithm used when the CA organization produces the certificate 明文Tto hashget the information summary T’.
  5. If the comparison S’is equal T’, it means that the certificate is credible, the browser has directly established a connection with the official, and no third party makes the difference.

Replay the scenario of a man-in-the-middle attack:

  • Suppose that the middleman has tampered with the original text of the certificate. Since he does not have the private key of the CA, he cannot get the encrypted signature at this time.
  • The middleman dropped the certificate as a whole, because the certificate contains website information, including domain name operations, which is equivalent to the above tampered certificate, and operations are prohibited.

Several common questions are clear:

  • question.1 Is the asymmetric public key in the certificate content different for the certificate issued by the server to different client browsers?
  • answer: all the same

In fact, this is not absolutely safe. You must maintain the security of the entire link if you want to ensure the security of the system, but if you want to infiltrate the system, you only need to find a loophole.

such as:

The certificate returned by the server can be tuned, but the client must trust the tuned certificate. This is the principle of Charles grabbing https requests.

hash encryption

Hash can be used to extract information digest. Based on the hash value and the source file, we can verify whether the file we downloaded is the same as the source file.

  • eg.1 When we download the operating system image on the centos official website, the official website generally provides one 源码包 + md5的哈希值. After
    we download the source code, use md5 to extract the source code package, and then compare it with the abstract provided by g to verify us Whether the downloaded installation package has been tampered with.

  • eg.2 When uploading files, we can perform md5 extraction and abstraction of the files, and only need to save one file with the same abstract to reduce the waste of space. (The same principle is also used in the network disk).

Original link

cnblogs https://www.cnblogs.com/Leo_wl/p/13047692.html

Know https://zhuanlan.zhihu.com/p/43789231

Guess you like

Origin blog.csdn.net/qq_30549099/article/details/107476150