Focus on three knowledge points: the essence of HTTPS, HTTPS encryption principle, HTTPS communication process.
What is the HTTPS
Problems that HTTP cannot solve
The HTTP protocol is too simple:
- Communications use plaintext without encryption, making content extremely vulnerable to hijacking and eavesdropping.
- Do not verify the identity of the communication party, can encounter camouflage.
- Failed to verify the integrity of the packet.
To solve the above problems, HTTPS came into being.
The essence of the HTTPS
HTTPS = HTTP + encryption + identity authentication + content integrity protection.
HTTPS is not a new layer 7 protocol. However, the HTTP communication interface uses SSL or TLS instead, so HTTPS is really HTTP wrapped in SSL.
What are SSL and TLS?
TSL is based on SSL3.0, followed by TSL1.0, TSL1.1 and TLS1.2. The current mainstream version is SSL3.0 TSL1.0.
TLS is a protocol developed based on SSL, sometimes referred to as SSL.
HTTPS encryption mechanism
In modern encryption algorithms, the encryption algorithm is open, but the key is secret. In this way the encryption method is kept secure.
Encryption and decryption use a key, without a key there is no way to decrypt the password. In other words, anyone with a key can decrypt the ciphertext.
HTTPS uses asymmetric encryption and symmetric encryption
Symmetric encryption algorithm
In the encryption mode of single-key cryptosystem, the same key can be used to encrypt and decrypt information at the same time. This encryption method is called symmetric encryption, also known as single-key encryption.
Symmetric encryption algorithms are referred to as shared key encryption algorithms.
Suppose SSL now uses symmetric encryption to communicate, meaning that both the client and the server share a key.
Therefore, in order to encrypt the shared key, the key must be sent to the other party. At this time, if the communication process is monitored, the key is obtained by the attacker, so this time also lost the meaning of encryption.
So, is there a way around this? The answer is yes, using two keys.
Let’s start with asymmetric encryption algorithms that use two keys.
Asymmetric encryption algorithm
In contrast to symmetric encryption algorithms, asymmetric encryption algorithms require two keys to encrypt and decrypt, which are paired, namely a public key (public key) and a private key (private key).
In general, public keys can be disclosed to encrypt plaintext. Correspondingly, the private key cannot be disclosed to decrypt the ciphertext encrypted by the public key.
Note that the ciphertext encrypted with a public key can be decrypted only by using the corresponding private key, whereas the ciphertext encrypted with a private key can be decrypted by using the corresponding public key.
Above, public key encryption private key decryption for encryption, private key encryption public key decryption for signature. Related uses will be covered later.
Asymmetric encryption algorithms are referred to as public-key encryption algorithms.
So now, suppose the server now generates a pair of public and private keys.
When the client negotiates with the server for the first time, the server generates a pair of public and private keys.
Then, the server sends the public key to the client (plaintext, without any encryption). After receiving it, the client randomly generates a key and encrypts it with the public key sent from the server.
The client then sends the public-encrypted key to the server, which receives it, decrypts it with the paired private key, and gets the randomly generated key.
At this point, both the client and the server hold the same key. At this point, the key exchange is complete.
The communication can then be encrypted in the shared key encryption mode described above.
At the same time use
Perhaps, some friends may ask, why bother to use asymmetric encryption, and then get the same key, shared key encryption communication?
Public key encryption is more complicated than shared key encryption, so it is inefficient to use public key encryption in communication.
Therefore, we need to use asymmetric encryption to ensure the security of the key in the process of key sharing, and then use symmetric encryption algorithm in the process of communication. This is the most reasonable design method, which ensures both security and performance.
Therefore, HTTPS uses a mixture of shared key encryption and public key encryption. The public key encryption method is used in the key exchange process, and the shared key encryption method is used in the communication exchange message phase.
The above is probably the process of using symmetric encryption and asymmetric encryption. The process seems to be perfect, but there is still a problem: how to ensure the correctness of the public key sent by the server. In other words, it can’t be intercepted or tampered with.
The HTTPS encryption process is as follows:
HTTPS is intercepted as shown in the following figure:
Use certificates to ensure the correctness of public keys
If you are trying to establish public-key communication with a server, how can you prove that the public key received by the client is the public key issued by the server as originally expected? Perhaps, during the public key transfer, the real public key may have been replaced by an attacker.
To solve this problem, public key certificates issued by digital certificate authorities and their associates can be used.
The following describes the business process of a digital certificate Authority (CA) :
First, the server operator applies for a public key from a digital certificate authority. After identifying the identity of the applicant, the digital certificate Authority will digitally sign the applied public key, allocate the signed public key, and bind the public key into the public key certificate. Let’s translate the above passage into plain Chinese:
- First, the CA issues a certificate to the applicant. The contents of the certificate include the issuer, the purpose of the certificate, the HASH algorithm used, the algorithm used for signing the certificate, and the expiration time of the certificate.
- Then, do a HASH evaluation of the above to get a HASH value.
- The CA’s private key is then used to encrypt the HASH value and the HASH algorithm used to complete the digital signature. Encrypting the CA’s private key creates a signature similar to a human fingerprint, and any attempt to tamper with the certificate will be detected by the digital signature.
- Finally, the digital signature, attached to the end of the digital certificate, is transmitted to the server.
The server then issues the public key certificate issued by the Digital Certificate Authority to the client. At this point, the client can authenticate it using the digital certificate authority’s public key. Once authenticated, the client can determine that the public key is trusted. Let’s translate it again in the vernacular:
- After obtaining the digital certificate, the client can decrypt the digital signature at the end of the certificate using the corresponding public key of the CA private key to obtain the HASH value and HASH algorithm.
- The client then hashes the contents of the certificate based on the decrypted HASH algorithm. If the HASH value decrypted through the CA public key is the same as the HASH value computed, the authentication succeeds. Otherwise, the authentication fails.
- If the authentication succeeds, the public key of the server can be obtained.
Where does the CA public key on the client come from?
In fact, in addition to issuing certificates to applicants, CA also has its own certificates. The CA’s own digital certificates (usually generated by the CA itself) are installed by Microsoft (or other operating system developers) in the operating system as soon as our operating system is installed. The CA’s public key is included. In this way, the CA can use its private key to sign the issued digital certificate, and the client can use the corresponding public key to decrypt it.
The specific process looks like this (the process of digital signature is simplified in the figure) :
This is where asymmetric encryption is used, only now the encryption algorithm is used to sign instead of encrypt.
Use private key encryption, public key decryption, used by the public key holder to verify whether the content encrypted by the private key has been tampered with, but not to ensure that the content is obtained by others.
The use of public key encryption, private key decryption, is the opposite, it does not guarantee that the information will be intercepted and tampered with by others, but ensure that the information can not be obtained by the middleman.
The problem
What happens if a hacker intercepts the server and sends the certificate to the client and maliciously modifies the certificate?
In the first case, if the hacker simply modifies the contents of the digital certificate, the client can easily determine whether the packet is tampered with due to the existence of the digital signature.
In the second case, the hacker not only modifies the content of the digital certificate, but also replaces the digital signature. Because the hacker cannot know the CA’s private key, when the client uses the CA’s public key for decryption, the client cannot obtain the correct information after decryption, and it is easy to determine whether the packet is modified.
In the third case, the hacker maliciously applies for a digital certificate from the same third-party CA. Since the CA is real, the client can decrypt it with the CA’s public key and get the public key in the digital certificate provided by the hacker. However, since the digital certificate is bound to a domain name at the time of application, when a client, such as a browser, detects that the domain name in the digital certificate is not the same as the domain name we are currently accessing, we can also know that the digital certificate has been replaced. Warning issued.
Reference links: segmentfault.com/a/119000001…