TLS, SSL, CA certificate, public key, private key...let’s take a look at them today!

Song Ge has been serializing gRPC with his friends recently. 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 connection solutions, we will use an article today to clarify these concepts with you. Once the concepts are understood, it will be easy to look at TSL+gRPC.

1. HTTP Issues

HTTP is the abbreviation of 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 method for publishing and receiving HTML pages, but today, its role is more than that.

For us Java engineers, HTTP should be something very familiar. Currently, there are multiple versions of HTTP, and the most commonly used one is HTTP/1.1.

However, the HTTP protocol has a flaw in that it transmits data in plain text. The content transmitted by users through the HTTP protocol can be easily intercepted by malicious parties, and hackers can disguise themselves as servers to send wrong information to users and easily obtain users' private information, and users are completely unaware of these operations.

Due to such security risks, most of the websites you see are gradually switching to HTTPS, and there will be fewer and fewer HTTP websites.

2. HTTPS

HTTPS (HyperText Transfer Protocol Secure) is translated into Chinese as Hypertext Transfer Protocol Secure, which is a transmission protocol for secure communication over computer networks.

HTTPS is essentially still based on HTTP for communication, but adds an SSL secure transmission protocol between the HTTP protocol and the TCP layer. The entire transmission encryption process is implemented in the new security layer SSL/TLS, while the original HTTP layer transmission process remains unchanged, which is very compatible with the old HTTP protocol and follows the layered concept of the TCP/IP protocol family.

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 website on our browser, the following conditions can indicate that the server can be trusted:

1. First, we have installed the correct and trusted certificate in our operating system. We can view the list of certificates installed in the operating system by executing the ​certmgr.msc​​​ command in the cmd command line.

2. The browser itself implements HTTPS correctly.
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.

This involves some concepts of certificates and protocols. Next, Brother Song will go through the whole process with you.

3. TLS/SSL

We mentioned earlier that HTTPS adds TLS/SSL on top of HTTP, so how should we understand these two things?

SSL/TLS is a cryptographic communication scheme, which is currently the most widely used cryptographic communication scheme. SSL stands for Secure Socket Layer, which is a set of protocols designed by Netscape in 1994 and released version 3.0 in 1995; TLS stands for Transport Layer Security, which is a protocol designed by IETF based on SSL3.0. It is actually equivalent to the subsequent version of SSL. Currently, TLS has successively iterated ​TLS 1.0​​​ ​​, ​TLS 1.1​​​ ​​, ​TLS 1.2​​​​​ and ​TLS 1.3​​​ ​​, and the most widely used version is ​TLS 1.2​ ​​​​.

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

3.1 TLS

Next, let's 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 which is to encrypt the transmitted data. Yes, this is one way, and in fact it is done this way.

There are two types of encryption:

1. Symmetric encryption
2. Asymmetric encryption

So which one should you use?

Symmetric encryption means that the encryption key and decryption key are the same. When the browser and the server need to communicate, they agree on a key and use it to encrypt the message. After receiving the message, the other party uses the same key to decrypt the message. However, in B/S architecture projects, this solution is obviously not suitable. 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. 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 everyone, and the private key is known only to the user. When communicating, the client first encrypts the message with the public key. After the server receives it, it decrypts the message with the private key. This seems perfect. But!!! There is a problem with asymmetric encryption, which is that asymmetric encryption and decryption are quite time-consuming. The efficiency of encryption and decryption in this way is too low.

So what? We can combine the two.

Specifically, it is like this: first, the server will generate an asymmetric encryption key pair, keep the private key by itself, and send the public key to the client. After the client obtains the public key, it will generate a symmetric encryption key, and then encrypt the symmetric encryption key with the public key. After encryption, it will be sent to the server, and the server will decrypt it with the private key. In this way, the client and server can communicate through symmetric encryption.

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

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

This involves another concept called digital certificate.

3.2 CA

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

In actual scenarios, digital certificates are a series that form a trust chain, with the CA at the top of the trust chain.

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

1. The certificate that a CA issues to itself and signs with its own private key is called a root certificate. The security of the private key of the root certificate is extremely important. The private key of the root certificate is stored in an offline computer and has strict operating regulations. Every time it needs to be used, a dedicated person will copy the data via USB and take the data out after the operation is completed (this refers specifically to the private key of the CA root certificate).
2. If a user wants to obtain a certificate, he must first have a key pair. He should keep the private key and send the public key and other information to the CA. Then he should apply to the CA. After the CA determines the identity of the user, it will bind the public key to the user's identity information and sign the bound information (the signature is performed using the private key of the CA root certificate). Finally, the signed certificate will be sent to the applicant.
3. If a user wants to verify the authenticity of a certificate, he or she can verify the digital signature on the certificate using the CA's public key. If the verification is successful, the certificate is considered valid.

There is an important premise in the above process, that is, CA is trusted by everyone.

However, in actual operation, we cannot directly apply for a digital certificate from CA, because there are too many contents that need to be certified in the world, and CA cannot handle it. In addition, frequent applications to CA may lead to private key leakage, which is a big disaster.

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

1. First of all, our mobile phones, laptops and other operating systems are pre-installed with root certificates issued by CA. They are the cornerstone of all trust construction. Earlier, Brother Song has taken a screenshot to show you the root certificates pre-installed in Windows.
2. Assume that CA issues a certificate A. In this process, CA is called Issuer and A is called Subject. Assume that A is a trusted intermediate certificate that has been pre-installed in our operating system. Now A uses its own private key to issue a certificate B to a 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 B certificate is legal, but the A certificate is pre-installed on our computer, we can extract A's public key from the A certificate, and then use A's public key to verify the signature of the B certificate (because the signature of the B certificate is signed by A's private key). If the verification passes, it means that B is legal.
4. By the same token, B can continue to issue C certificates, and C can continue to issue D certificates, thus forming a chain of trust.
5. If the server's signature is the D certificate, then generally speaking, the server will return three certificates, B, C, and D, to the browser (because the A certificate is already on our computer). Even if only the D certificate is returned, the browser can automatically download the B and C certificates based on the information in the D certificate and then verify them.

Song Ge remembers that when he was in college, he bought train tickets on the 12306 website. When he visited for the first time, he had to manually install a root certificate to the system before he could access it. This was 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 a digital certificate B, but the browser did not have a suitable public key to verify this B certificate. After I installed the certificate given by 12306 on my system, it was equivalent to having a certificate A on my computer, and now I could verify the B certificate.

To summarize:

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 obtain a CA's certificate (including the public key) to verify the certificates issued by the CA.
3. Each digital certificate is signed by the private key of the superior certificate. The top-level one is the root certificate issued by the CA. This root certificate has no superior certificate, so the root certificate is actually signed by the CA's own private key, which is also called self-signed.

Once 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 verifies the signature using the public key built into the system. After confirming that the signature is correct, it extracts the public key from the digital signature and starts negotiating the private key for symmetric encryption.

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