Brother Song has recently been serializing gRPC with his friends, how to ensure the security of gRPC communication?  This involves TSL, but considering that some friends may be unfamiliar with the whole set of encrypted connections, we will use an article to clarify with these concepts you today. After understanding the concept, let's look at TSL+gRPC. It's easy.

1. Problems with HTTP

HTTP protocol is the abbreviation of Hyper Text Transfer Protocol (Hyper Text Transfer Protocol), which is a transmission protocol for transmitting Hypertext Markup Language HTML from a WEB server to a local browser. HTTP was originally designed to provide a  way to publish and receive HTML pages, but today it does much more than that.

For us Java engineers, HTTP should be very familiar. There are currently multiple versions of HTTP, and HTTP/1.1 is the most used version.

However, the HTTP protocol has a flaw that it transmits data in clear text. The content transmitted by the user through the HTTP protocol is easily intercepted maliciously, and hackers can pretend to be the server, send wrong information to the user, and easily obtain the user's information. Privacy information, and users of these operations are completely unaware.

Due to such security risks, most of the websites you see are gradually converting to HTTPS, and HTTP websites will become less and less.

2. HTTPS

HTTPS (HyperText Transfer Protocol Secure) is translated into Hypertext Transfer Protocol Secure in Chinese, which is a transmission protocol for secure communication through a computer network.

In essence, HTTPS still uses HTTP for communication, but an SSL secure transmission protocol is added between the HTTP protocol and the TCP layer. The encryption process of the entire transmission is implemented in the new security layer SSL/TLS, while the transmission process of the original HTTP layer remains unchanged, which is well compatible with the old HTTP protocol and also follows the TCP/IP protocol family. Think in layers.

Through HTTPS, the client can confirm the identity of the server and ensure that the data is not tampered with during transmission. When we establish an HTTPS connection with a certain website on our browser, the following conditions can be satisfied to indicate that the server can be trusted :

1. First we have a correct and trusted certificate installed in our operating system. We execute ​certmgr.msc​the command to view the list of certificates installed in the operating system.

2. The browser itself correctly implements HTTPS.
3. The visited website provides a certificate, which is issued by a certificate authority trusted by the operating system. The certificate authority trusted by the operating system is generally pre-installed in the operating system, and can be viewed through the first step .
4. The certificate presented by the visited website was successfully authenticated.

Some concepts of certificates and protocols are involved here. Next, Brother Song and everyone will go through the whole process.

3. TLS/SSL

As we mentioned earlier, HTTPS is the addition of TLS/SSL on the basis of HTTP, so how should these two things be understood?

SSL/TLS is a cryptographic communication scheme, which is currently the most widely used cryptographic communication scheme. The full name of SSL is Secure Socket Layer, which is translated into Chinese as Secure Socket Layer. It is a set of protocols designed by Netscape in 1994, and version 3.0 was released in 1995; the full name of TLS is Transport Layer Security, which is translated into Chinese as Transport Layer Security, which is IETF The protocol designed on the basis of SSL3.0 is actually equivalent to the subsequent version of SSL. At present, TLS has iterated ​TLS 1.0​​​​​,​, ​TLS 1.1​​​, ​TLS 1.2​and ​TLS 1.3​​​, and currently ​TLS 1.2​the version .

SSL/TLS involves symmetric encryption, asymmetric encryption, digital signature, etc. in cryptography, and can be regarded as a master in the field of cryptography.

3.1 TLS

Next, let's take a look at how TLS ensures HTTP security.

In order to ensure the data security between the client and the server, it is easy for us to think of a solution to encrypt the transmitted data. Yes, this is a way, and in fact it is the same.

There are two types of encryption:

1. Symmetric encryption
2. asymmetric encryption

So which one should you use?

Symmetric encryption, that is, the encryption key and the decryption key are the same. When the browser and the server need to communicate, agree on a key, and then use this key to encrypt the sent message, and the other party receives the message The message is then decrypted using the same key. However, in B/S architecture projects, this solution is obviously inappropriate. If a website tells all browsers in the world its key, is there any difference between encryption and non-encryption?

Some friends may think of asymmetric encryption again. Asymmetric encryption is a solution, because asymmetric encryption has a key pair of public key and private key. The public key can be published to tell everyone, and only you know the private key. When communicating, the client first encrypts the message with the public key, and after receiving it, the server decrypts the message with the private key, which seems to be perfect. but! ! ! A problem with asymmetric encryption is that asymmetric encryption and decryption are quite time-consuming, and the efficiency of processing encryption and decryption in this way is too low.

So what to do? We can combine the two.

Specifically, it is like this: first, the server will generate an asymmetric encryption key pair, the private key will be saved by itself, and the public key will be sent to the client. After the client gets the public key, it will generate a symmetric encryption key , and then encrypt the symmetric encryption key with the public key, and send it to the server after encryption, and the server decrypts it with the private key, so that the client and the server can communicate through symmetric encryption.

In fact, the general idea of ​​TLS is like this.

However, there is still a loophole in the above solution, that is, the server needs to send the public key to the client through plain text transmission. This process is still unsafe and may be maliciously intercepted. So how to solve this problem?

This involves another concept called digital certificate.

3.2 CAs

A digital certificate is a file that contains various information of the target website, such as the domain name of the website, the validity period of the certificate, the issuing authority, the public key used to generate the symmetric key, the signature issued by the superior certificate, etc. Through the digital certificate, we can confirm a user or service The identity of the site.

There are a series of digital certificates in the actual scene, forming a chain of trust, and the top of the chain of trust is the CA.

CA is the abbreviation of Certificate Authority, which is a third-party authority responsible for issuing and managing digital certificates. The workflow of the CA is as follows:

1. The certificate signed by the CA itself with its own private key is called the root certificate. The security of the private key of the root certificate is very important. The private key of the root certificate is stored in an offline computer, and there are strict operating regulations. Every time it needs to be used, someone will copy the data via USB, and after the operation is completed, the data will be brought out (this refers to the private key of the CA root certificate).
2. A user who wants to obtain a certificate must first have a key pair, keep the private key for himself, send the public key and other information to the CA, and apply to the CA. After the CA determines the identity of the user, it will share the public key with the The user's identity information is bound, and the bound information is signed (the signature is performed through the private key of the CA root certificate), and finally the signed certificate is sent to the applicant.
3. When a user wants to verify the authenticity of a certificate, he uses the CA's public key to verify the digital signature on the certificate. If the verification passes, the certificate is considered valid.

An important premise in the above process is that the CA is trusted by all of us.

However, in actual operation, we cannot directly apply for a digital certificate with the CA, because there are too many content to be certified in the world, and the CA cannot handle it. Moreover, frequently applying to the CA may lead to the leakage of the private key. But it is a big disaster.

then what should we do? In practice, we can build a trust chain based on CA. Specifically, the steps are as follows:

1. First of all, the root certificates issued by CAs are pre-installed in our mobile phones, notebooks and other operating systems. They are the cornerstone of all trust building. Brother Song has taken screenshots to show you the root certificates pre-installed in Windows.
2. Suppose CA issues a certificate A, in this process, CA is called Issuer, and A is called Subject, assuming that A is a trusted intermediate certificate, which has been pre-installed in our operating system. Now A uses its own private key to issue a certificate B to a certain website.
3. Now when our computer needs to access the website, the website will send us a certificate B. Since our browser does not know whether the certificate B is legal, but the certificate A is pre-installed on our computer, we A's public key can be extracted from the A certificate, and then use A's public key to verify the signature of B certificate (because the signature of B certificate is signed by A's private key), if the verification passes, it means that B is legal of.
4. In the same way, B can also continue to issue C certificates, and C can continue to issue D certificates, thus forming a chain of trust.
5. If the signature of the server is a D certificate, generally speaking, the server will return to the browser three certificates including B, C, and D (because the A certificate is already on our computer), even if only the D certificate is returned, browse The device can also automatically download the two certificates of B and C according to the information in D book and then verify them.

Brother Song remembers that when he was in college, he bought a train ticket on the 12306 website. When he visited for the first time, he had to manually install a root certificate into the system before he could access it. This is because the issuing authority of the certificate used by 12306 was not recognized by the browser at that time, similar to step 3 above, 12306 sent me back a digital certificate B, but the browser did not have a suitable public key pair for this B certificate To verify, when I install the certificate given by 12306 on my system, it means that I have a certificate A on my computer, and now I can verify the certificate B.

in conclusion:

1. CA is an authoritative organization and a certificate issuing authority. The certificate issued by CA can prove the identity of a person or organization.
2. Anyone can get the CA's certificate (including the public key) to verify the certificate issued by the CA.
3. Each digital certificate is issued by the private key of the superior certificate. The root certificate issued by the CA is at the top. This root certificate has no superior certificate, so the root certificate is actually issued by the private key of the CA itself. This is also called self-signed, that is, Self-Signed.

When we have a digital signature, we can solve the problem raised at the end of section 3.1. The server sends the digital signature to the browser, and the browser uses the built-in public key of the system to verify the signature to confirm that the signature is correct, then extracts the public key in the digital signature, and begins to negotiate the private key for symmetric encryption~

Well, with this knowledge reserve, the next article, Brother Song, will talk to you about how to play TLS+gRPC!