Shulou(Shulou.com)06/01 Report--

This article mainly introduces "the principle of encryption and decryption of HTTPS". In the daily operation, I believe that many people have doubts about the principle of encryption and decryption of HTTPS. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts of "the principle of encryption and decryption of HTTPS". Next, please follow the editor to study!

This article will discuss the encryption and decryption principle of HTTPS, many people know RSA, think that HTTPS=RSA, use RSA to encrypt and decrypt data, in fact, this is wrong.

HTTPS uses RSA to authenticate and exchange keys, and then uses the exchanged keys to encrypt and decrypt data.

Authentication is asymmetric encryption using RSA, while data transmission is symmetric encryption by both parties using the same key. So, what is symmetric encryption and asymmetric encryption?

Symmetric encryption and asymmetric encryption

Suppose Xiao Wang next door wants to ask Xiao Hong out, but he doesn't want Xiao Ming to know, so he wants to send Xiao Hong a small note with symmetrical encryption.

As shown in the following figure:

The data he wants to send is "Meet at 5:00 PM" (meet at 5 o'clock, if it is Chinese, you can use UTF-8 coding), and the encryption method is to move left or right directly in the ASCII table.

His key is 3, which means that if you move 3 bits back in the ASCII table, it will become "Phhw#dw#8=33#SP", so that people don't know what it means if they intercept it.

But we can think about it, if he can intercept your data, he can also intercept your key and decrypt it.

As shown in the following figure:

So Xiao Wang intends to use asymmetric encryption. The characteristic of asymmetric encryption is that both parties have their own public key and private key pairs, in which the public key is sent to each other, and the key is kept without exchange and disclosure.

As shown in the following figure:

The public key of Xiao Hong is:

Public_key = (N, e) = (3233, 17)

She sent the public key to Xiao Ming, and her own private key was:

Private_key = (N, e) = (3233, 2753)

Note here that both the public key and the private key are two numbers, N is usually a large integer, and e represents a power exponent. Now Xiao Wang wants to send a message to Xiao Hong, so he encrypts it with Xiao Hong's public key. How to encrypt it?

The first letter he wants to send is t = "M", and the ASCII code of "M" is calculated as follows:

T = 77 ^ e% N = 77 ^ 17% 3233 = 3123

Give 77 to the power of e and then modulo N, and you get Toner 3123, and then send this number to Xiao Hong (other letters are treated in the same way).

After receiving T, Xiao Hong decrypts it with her private key. The calculation is as follows:

T = T ^ e% N = 3123 ^ 2753 3233 = 77

The calculation method is the same, so T is reduced to t, as long as the public and private keys are matched, the above inference can be proved by some mathematical formulas. This is the encryption and decryption principle of RSA. If you can't know the private key, you can't decrypt it correctly.

Conversely, it is feasible to use the private key for encryption and the public key for decryption. So how does HTTPS use RSA for encryption and decryption? let's start with the process of establishing a HTTPS connection.

HTTPS connection establishment process

HTTPS has the following main functions:

Verify the identity of the server. For example, when I visit google.com, I am connected to a Google server.

Prevent data from being hijacked. For example, some operators will insert ads into http pages.

Prevent sensitive data from being stolen and tampered with, etc.

As openssl's notes say, this is the only way to prevent man-in-the-middle attacks:

Let's take MDN (https://developer.mozilla.org) 's website) as an example, and then grab the package with wireshark to observe the process of establishing a HTTPS connection.

As shown in the following figure:

First, the TCP three-way handshake, then the client (browser) initiates a HTTPS connection establishment request, the client first sends a Client Hello packet, and then the server responds to a Server Hello.

Then send its certificate to the client, then the two sides exchange keys, and finally use the exchanged keys to encrypt and decrypt the data.

In Client Hello, the client informs the server of its current information, as shown in the following figure:

Including the TLS version to be used by the client, the encryption package supported, the domain name to be accessed, a random number (Nonce) generated to the server, and so on.

You need to inform the server in advance of the domain name you want to access so that the server can send the certificate of the corresponding domain name, because there is no HTTP request at this time.

The server will make some responses in the Server Hello:

The encryption package selected by the server is called TLSECDHERSAWITHAES128GCM_SHA256, which means:

Key exchange using ECDHE

Certificate signature algorithm RSA

Data encryption using AES 128 GCM

Signature verification using SHA256

Then the service sends four certificates to the client:

The common name (common name) of the first certificate is the domain name we currently visit, developer.mozilla.org.

If the common name is *. Mozilla.org, then this certificate can be used by all secondary subdomains of mozilla.org.

The second certificate is the certificate of the issuing authority (CA) of the first certificate, which is Amazon, which means that Amazon signs developer.mozilla.org with its private key.

And so on, the third certificate signs the second certificate, the fourth certificate signs the third certificate, and we can see that the fourth certificate is a Root certificate.

What will be in a certificate? we can expand the first certificate to have a look, as shown in the following figure:

The certificate consists of three parts:

TbsCertificate (to be signed certificate) content of certificate to be signed

Certificate signature algorithm

Signature given by CA

That is, CA will sign the tbsCertificate with its private key and put it in the signature section. Why should the certificate be signed? The signature is to verify the identity.

Authentication

Let's first take a look at what is in tbsCertificate, as shown in the following figure:

It includes information such as the public key of the certificate, the applicable public name of the certificate, the validity period of the certificate and its issuer.

The Amazon certificate also has the above structure. We can copy out the public key of the Amazon certificate, as shown below:

There are some filled numbers in the middle, expressed in gray. You can see that N is usually a large integer (binary 2048 bits), while e is usually 65537.

Then we use the public key of the CA to decrypt the mozilla.org certificate signature, similar to the one above:

Take the last 64 bits of the decrypted digital decrypted in hexadecimal, which is the binary 256bit SHA hash signature.

Next, let's manually calculate the SHA256 hash value of tbsCertificate by exporting tbsCertificate to an original binary file in wireshark:

Then use openssl to calculate its hash, as follows:

Liyinchengs-MBP:https liyincheng$ openssl dgst-sha256 ~ / tbsCertificate.binSHA256 (/ Users/liyincheng/tbsCertificate.bin) = 5e300091593a10b944051512d39114d56909dc9a504e55cfa2e2984a883a827d

We found that the manually calculated hash value is consistent with the hash value in the encrypted certificate! Indicates that only people who know the Amazon private key can sign the mozilla.org certificate correctly, because the public and private keys are the only match.

So we verify that the first certificate mozilla.org is indeed issued by the second certificate Amazon, and in the same way, we can verify that the Amazon is issued by the third certificate and the third certificate by the fourth root certificate.

And the fourth certificate is the root certificate, which is built into the operating system (which can be seen through Mac's keychain tool):

Suppose Hacker points the domain name you visit to his machine through DNS spoofing, and then he forges a certificate.

However, because the root certificate is built into the operating system, it can not change the signed public key, and it does not have the correct private key, so it can only use its own private key. Because the public and private keys are not matched, it is difficult to guarantee the consistency of the encrypted and decrypted information.

Or simply move the certificate obtained by the browser to his own server? In this way, the certificate issued to the browser is exactly the same, but it is meaningless because he does not know the private key of the certificate, so he cannot carry out subsequent operations.

This is how HTTPS can verify identity. Another example is SSH, which requires manual verification of the signature.

For example, inform the server by phone or email whether the signature of the certificate is consistent with that of the certificate calculated by yourself, and if the agreement indicates that the certificate has not been tampered with (for example, the public key of the certificate has not been changed to the public key of Hacker):

The value shown above is the value calculated manually by yourself. Compare this value with the previous value to see if the certificate sent has been modified.

So why not just use RSA's key pair to encrypt the data? Because the key pair value of RSA is too large to encrypt and decrypt data frequently, a smaller key is needed.

Another reason is that the server does not have a browser or client key and cannot send encrypted data to the browser (it cannot be encrypted with its own private key because the public key is public). So key exchange is needed.

Key exchange

There are two ways to exchange keys: RSA and ECDHE,RSA are relatively simple. The browser generates a key, then uses the public key of the certificate RSA to encrypt and sends it to the server, and the service uses its key for decryption to get the key, so the key can be shared.

Its disadvantage is that although the attacker cannot crack it during the sending process, if it saves all the encrypted data and causes the private key to be disclosed for reasons such as the expiration of the certificate and not being maintained, then it can use the private key to decrypt all previously transmitted data.

Using ECDHE is a more secure key exchange algorithm. As shown in the following figure, the two parties exchange keys through ECDHE:

The full name of ECDHE is Elliptic Curve Diffie-Hellman key Exchange elliptic curve Diffie-Herman key exchange, which is an improvement of Diffie-Herman key exchange algorithm.

The idea of this algorithm is shown in the following figure:

In order to get the shared secret key K, A calculates a number g ^ a with its private key, which is sent to B. if the private key of B is b, B gets K = g ^ a ^ b, and when g ^ b is sent to A, An also gets K = g ^ b ^ a.

This should be easier to understand, and the introduction of elliptic curve encryption can make it more difficult to crack.

Elliptic curve encryption

Now there are two kinds of certificate signing algorithms: RSA and the new EC. As shown in the following figure, google.com is the ECC certificate used:

What we discussed above is RSA. The difficulty of cracking RSA is that it is impossible to decompose the N of the public key.

If you can multiply the N of the certificate into two primes, you can calculate the private key of the certificate, but it is impossible at the current computing power. The difficulty of cracking ECC is to find the coefficient of the specified point.

As shown in the following figure, there is an elliptic curve equation:

Y ^ 3 = x ^ 2 + ax + b:

Given a starting point G (x _ ray y), now we need to calculate the coordinates of the point 2G. The process is to make a line tangent to the curve at the G point at-2G, and then do the reflection of the 2G relative to the x axis to get the 2G point.

To calculate the coordinates of 3G, as shown in the following figure:

Connect 2G and G with the curve in the suburb of-3G, and then do reflection to get 3G, similarly, 4G is to connect G and 3G to do reflection. If the line between the last point and the starting point is perpendicular to the x-axis, all the points have been used up.

The difficulty of EC lies in the given starting point G and point K:

K = kG

It is very difficult to get K (K is big enough). This K is the private key and K=kG is the public key. How does ECC encrypt and decrypt data?

Assuming that the data to be encrypted is m, take this point as an x coordinate to get a point M on the curve, determine a random number r, and calculate the point C1cm rGMagic C2cm rk.

Send the encrypted data to the other party. After receiving it, the other party uses the private key K to decrypt it. The process is as follows:

M = C2-rK = C2-rkG = C2-rkG = C2-kC1

M can be restored through the above calculation, and people who do not know the private key K cannot decrypt it. More details can be found in Medium's article "ECC elliptic curve encryption". So we understand the principle of ECC, so how to use ECC for key exchange?

ECC key exchange

The principle is simple, as shown in the following figure:

The number that was exchanged before is the number of two powers, but now it becomes the point on the two curves.

The curve equation is defined, for example, the curve equation used by Curve X25519 is:

Y ^ 2 = x ^ 3 + 486662x ^ 2 + x

The curve equation to be used is specified in the key exchange, as shown in the following figure:

The curve equation used by mozilla.org is secp256r1, which is also popular, and its parameter is much larger than that of Curve X25519.

The key exchange also uses the private key of the certificate for signature to ensure that the exchanged key will not be tampered with, but the private key here is mozilla's own private key.

In other words, it is transmitted in clear text from the establishment of the connection to the present. Next, both parties send a packet notification for Change Cipher Spec, and the following packets are encrypted in the manner previously agreed upon. At this point, the entire secure connection is established.

Application of HTTPS Certificate

So who's doing HTTPS encryption? The server is usually done by reverse proxy servers such as Nginx and Apache, but the specific business server does not need to be processed, and the client is usually encrypted and decrypted by browsers. Chrome uses the library boringSSL and fork from openssl.

We can apply for a free TLS certificate through let's encrypt, which needs to be renewed manually every 3 months.

There are three types of certificates: DV, OV, EV,DV for individuals, OV and EV require identity verification, and EV is the most high-end.

The EV certificate displays the enterprise name of the certificate in the browser's address bar:

But the new version of Chrome seems to have removed this, so we can open the console of medium and see a prompt:

As part of an experiment, Chrome temporarily shows only the lock icon in the address bar. Your SSL certificate with Extended Validation is still valid.

In addition, we can use openssl to generate a self-signed certificate and execute the following command:

Openssl req-x509-nodes-sha256-days 365-newkey rsa:2048-keyout test.com.key-out test.com.crt

You will get two files, test.com.crt is the certificate and test.com.key is the private key of the certificate, as shown in the following figure:

Then give these two files to Nginx and you can access them using HTTPS, as shown in the following code:

Server {listen 443; server_name test.com; ssl on; ssl_certificate test.com.crt; ssl_certificate_key test.com.key;}

You can add this certificate to the system certificate so that browsers and others can trust it, or directly use the mkcert tool in one step.

Client certificate

There is another kind of certificate called the client certificate, which also needs to apply for a client certificate from the CA institution. Unlike the server TLS certificate, the server certificate is usually bound to the domain name, while the client certificate can sign any local executable file.

The signature verification algorithm is consistent with the TLS certificate discussed above. Why does the executable need to be signed, because if it is not signed, the system will block the installation or run, such as the prompt for Mac to double-click an unsigned dmg package:

Just don't let you run it, and Windows has a similar prompt, Windows will give you a warning:

When we run a signed exe file, it will be a normal prompt, such as the one from Chrome:

In summary, this paper mainly discusses the principles of symmetric encryption and asymmetric encryption, and introduces how to use RSA to verify the identity of the connection server, how to use ECC for data encryption and key exchange, how to generate and use HTTPS certificate, and the client certificate.

At this point, the study of "the principle of encryption and decryption of HTTPS" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.