1. The HTTP is faulty
The traditional HTTP protocol, which does not use SSL/TLS, is unencrypted communication. Both the request body sent by the client to the server and the response body sent by the server to the client are transmitted in plain text, which causes several problems:
1. Communication content can be obtained after eavesdropping on third-party hijacking requests. For some sensitive data, this is not allowed.
2. Tamper With The communication content can be tampered with after the third-party hijacking request. For example, in the banking system, Zhang SAN was supposed to transfer money to Li Si, but the third party hijacked the request and tampered with the request data, changing the receiver to himself, resulting in the loss of user funds.
3. You can impersonate a third party and send data as a client. Since the transmission is in plain text, there is no “add/check” operation, and the server cannot guarantee the validity of the request source.
Because of these problems, HTTP traffic poses a huge security risk, hence HTTPS. This article takes a closer look at how HTTPS addresses these issues.
2. SSL/TLS
Before introducing HTTPS, you must first understand the SSL/TLS protocol, because HTTPS is built on this, understanding SSL/TLS will basically understand how HTTPS works.
Secure Sockets Layer (SSL) is translated as Secure Socket Protocol, and Transport Layer Security (TLS) is translated as Transport Layer Security Protocol.
A quick look at their history:
- Netscape designed version 1.0 of the Secure Sockets Layer (SSL) protocol in 1994, but it was not released.
- In 1995, Netscape released SSL 2.0, but it soon found serious vulnerabilities.
- In 1996, SSL 3.0 came out and became widely used.
- In 1999, The Internet Standardization Organization (ISOC) took over from Netscape and released an updated version of SSL, TLS 1.0.
- In 2006 and 2008, TLS was upgraded to TLS version 1.1 and TLS Version 1.2.
The SSL/TLS protocol is between the Transport layer and the application layer. It is used to encrypt and decrypt network connections, as shown in the following figure:
2.1 Anti-eavesdropping: encryption
Let’s start with the first problem: eavesdropping. Since the plaintext transmission can be wiretapped by a third party, why not change to encrypted transmission? It’s in the right direction, but how do you encrypt your data to keep it safe?
2.1.1 Symmetric encryption
Using a single key cryptosystem encryption method, the same key can be used for information encryption and decryption at the same time, this encryption method is called symmetric encryption, also known as single-key encryption.
For example, DES is a symmetric encryption algorithm. Party A and Party B agree on a Key. Both parties use the Key to encrypt and transmit data before sending it, and decrypt the data into plaintext after receiving it. In this way, as long as the key is not leaked, theoretically safe.
But this raises a new question: how do you keep the keys?
On the PC, the browser page is in plain text and certainly cannot store the key. For iOS/Android, even if the key is hidden somewhere in the installation package, it can be easily cracked by a third party unpacking it.
Since the client is unreliable to save, so the key is only saved on the server, is it feasible for the client to get the key from the server?
Still not feasible, how does the server give you the key? The plaintext certainly can’t. If you want to encrypt, you need to use key B, and the transmission of key B needs to use key C, and so on. There is no solution.
2.1.2 Asymmetric encryption
An asymmetric encryption algorithm requires two keys: a publickey and a privatekey. The public key and private key are a pair. If the public key is used to encrypt data, only the corresponding private key can be used to decrypt data. Because encryption and decryption use two different keys, this algorithm is called asymmetric encryption.
Party a and party b each has its own key pair, open each other’s public key, when party a wants to send data to party a, by party b’s public key encryption, so ciphertext only party b can be solved, even if the request is hijacked, third party got the data, without party b’s private key, is also unable to decrypt, so as to ensure the data to be tapped.
One-way asymmetric encryption Most Internet websites are completely open to the outside, and all people can access them. The server does not need to verify the legitimacy of all clients, but only the client needs to verify the legitimacy of the server. For example, when users visit e-commerce sites, they must ensure that they are not phishing sites to prevent loss of funds.
In this case, only one-way encryption is needed. Generally, there is no sensitive information sent by the server to the client. It can be transmitted in plaintext. However, the information sent by the client to the server is likely to be sensitive, such as a password change, which must be encrypted.
Sometimes, the server needs to verify the legitimacy of the client, such as a banking system. Because money is involved, the system must be designed to be secure. In addition to the data that the client sends to the server is encrypted, the data that the server sends to the client must also be encrypted.
How do you do that? Generally, the bank will give the user a USB flash drive, which stores a set of key pairs. The client tells the server its public key, and the server encrypts the key according to the public key before transmitting it to the client.
2.2 Tamper-proof: adding signatures
Asymmetrically encrypted ciphertext transmission can prevent the data from being eavesdropped, but what if this scenario exists?
Zhang SAN in the banking system, to transfer to a sum of money to li si, data through the server’s public key PubB encryption transmission, but the third party seized the request, tampering with the packet data, is written “pay fifty and turn”, because the server’s public key is open, anyone can get, so the third party can also normal encryption transmission, The server performed an incorrect operation after decrypting the data properly, resulting in loss of user funds.
For operations involving funds, the server must verify the validity of the data and ensure that the data has not been tampered with, which requires the client to sign the data.
In asymmetric encryption, public key encryption, private key decryption, and private key signing, public key checking are available.
The bank gives the user a USB flash drive with a set of key pairs inside. Before the client sends a transfer request for the signature of the request body, get the signature “sign”, and then use the server public key encryption, get the ciphertext “data”, the client will sign with cipher text sent to the server, the server after decryption, also need to use the client’s public key to attestation “sign”, only for subsequent attestation by the operation, Otherwise it’s an illegal request.
2.3 Anti-Counterfeiting: Certificate
Encryption to prevent eavesdropping and signature to prevent tampering may seem safe for now, but there is a precondition: the transmission of the public key is secure. Unfortunately, the secure transmission of public keys is difficult to guarantee.
Man-in-the-middle attackConsider a scenario where the client and the server want to exchange public keys, but the requests are hijacked by a middleman. The result is that the server and client think they are exchanging public keys with each other, and the result is that both the client and the server are exchanging public keys with the middleman.
The problem arises because the transmission of public keys is insecure. When a client and a server exchange a public key, how do you ensure that the public key is sent by the other side and has not been tampered with??
2.3.1 Digital Certificate and Authentication Authority
Introduce an intermediate role: the Certificate Authority (CA). When the server sends the public key to the client, it sends the public key to the CA instead of directly. The CA generates a certificate based on the public key to the server, and the server sends the certificate to the client. After obtaining the certificate, the client goes to the CA to verify the validity of the certificate and ensure that the certificate is delivered by the server.
A CA, like a notary office, is also a server with its own set of key pairs. Its job is to generate a certificate based on the server’s public key and then help the client verify the validity of the certificate.
2.3.2 What should I Do if the CA is Impersonated?
Introducing CA can ensure the transmission security of public key, but there is a premise that CA is trusted by client and server, that is to say, CA must be safe and trustworthy. If CA is impersonated, the above problems will appear again.
The CA faces the same problem in making the CA trusted by the client and the server: how to ensure that the CA’s public key is safe from tampering? The answer is the same, if the CA is also issued with a certificate, then who will issue the certificate? The CA above the CA, of course. How does the CA above the CA ensure security? So the level above the CA the level above the CA issues the certificate to it. Finally, a certificate credit chain is formed, as follows:
The following is the baidu official website certificate, click the browser address bar next to the lock logo can see.
2.4 SSL/TLS Four-way handshake
The SSL/TLS protocol is easy to understand after understanding the underlying implementation, encryption, signing, certificates, etc. SSL/TLS requires four handshake processes:
- The client sends all certificates to the server.
- The server sends the certificate.
- The client authenticates the certificate, extracts the public key, and sends the symmetric encryption key.
- The server receives the key and responds OK.
3. Look at the HTTPS
To understand SSL/TLS, it is easy to go back to HTTPS, HTTPS=HTTP+SSL/TLS.
When HTTPS is used for communication, a TCP connection at the transport layer is established and the three-way handshake is completed, followed by the four-way handshake of THE SSL/TLS protocol. The two parties negotiate a symmetric encryption key, and the communication data is encrypted and transmitted using the key.