By the end of this article, my grandmother understands how HTTPS works

What are the risks that may exist when we get online at ordinary times?

• Disclosure, personal privacy, account passwords and other information may be stolen.

• Tampering, the received data may have been modified by a third party, or inserted into advertising, etc.

• Impersonation, the site visited is not the target server site. Such as domain name spoofing, domain name hijacking, phishing sites.

Maybe the flip-flops and shy little wang next door is spying on you in the dead of night!

Accompany you to see 91 some community film is good, in case stole each shopping website or other site login information…… Is not to think of some fear!

Why would anyone have access to your online data? The number of friends who have had a certain network foundation are some understanding of TCP/IP, all kinds of handshakes and waves have long been memorized, the HTTP protocol is also early in the heart.

HTTP is an application-layer protocol that sits at the top of the TCP/IP reference model. The user data is encapsulated by application layer, transmission layer, network layer and link layer and then sent to the target machine through physical layer.

In these layers, the data is not encrypted, so once someone gets hold of your packet, they can easily access the data.

In order to protect data privacy, let data no longer “streaking”. It is necessary to encrypt the data that needs to be transmitted.

At present, encryption algorithms can be divided into two categories, one is symmetric encryption algorithm, and one is asymmetric encryption algorithm.

Symmetric encryption algorithms use the same key for encryption and decryption. Symmetric encryption can solve the problem of data transmission security under certain conditions.

For example, when I log in to a website, I need to fill in the account name and password for login, and the client encrypts the login form information symmetrically before transmitting it. Even if Wang intercepts the data packet, he cannot get the content of the data, because the data has been encrypted.

But after the server received the data is also a face meng force, you sent the encrypted packet server does not know the decryption key!

Should the client and server negotiate the key before communicating? The client can inform the server to open the data transmission, and then the server tells the client, let’s use XXXX this key for encryption and decryption!

This content can be encrypted transmission, but the first step in the process of negotiating the key is also a security problem!

In case Wang intercepts the data of the negotiation key, the data transmitted by subsequent encryption is no less than unencrypted for Wang! Therefore, symmetric encryption has a key negotiation problem!

Based on the problems of symmetric encryption, there is asymmetric encryption. Asymmetric encryption algorithms require a set of key pairs, a public key and a private key, that come in pairs.

The contents encrypted with the public key need to be decrypted with the private key, and the contents encrypted with the private key need to be decrypted with the public key! The server saves the private key and sends the public key to the client.

After the client gets the public key, it can encrypt the request and send it to the server. Even if it is intercepted by Wang, wang cannot decrypt the content sent without the private key, thus ensuring the “security” of the data sent to the server by the client!

However, the public key can also be intercepted by Wang because it needs to be sent to the client over the network. In this way, the encrypted content of the server private key can still be intercepted and decrypted by Wang, and the asymmetric encryption efficiency is low.

Symmetric encryption and asymmetric encryption have key transmission problems, but at least asymmetric encryption can ensure that the client transmitted to the server can not be “cracked”, and symmetric encryption algorithm performance is better, then we can not do this.

During the first communication, the server sends a public key to the client. The client generates a symmetric key, encrypts the public key of the server, and sends the symmetric key to the server. The subsequent interactions are encrypted and transmitted using the symmetric key.

That is, the asymmetric key is used to encrypt the symmetric key, and the actual requested content is encrypted using the symmetric key.

The above scheme seems to be seamless, wang seems to have no way to start after getting the data, but is it really seamless?

Take a look at the picture below:

That is to say, Wang can pretend to be a server and communicate with the client. It’s like having a middleman between you and the server! That is to say, there is still a vulnerability in the process of negotiating the key!

A bit of a brain ache! Still can let me safety of the Internet! Isn’t there a more secure mechanism? How can a client be sure that the other party is the real target server during key negotiation? How do you prove the identity of the server? Let’s look at digital certificates first!

We have all kinds of certificates in our life, id cards that can prove that we are a person with status, and graduation certificates that can prove that we have studied for several years.

These certificates are the proof of one’s identity that cannot be forged and authenticated by some authoritative authority.

That server also can have a similar id card thing, in the communication with the server to prove that he is really the target server rather than Wang forged it?

In the life these certificates are real can see and touch, and the certificate in the computer is virtual, visible but can not touch, is the data form record, so call digital certificate!

When the client communicates with the server for the first time, the server needs to present its digital certificate to prove its identity and public key, which is similar to the following:

So how did this digital certificate come about? The server can’t build one, can it? It says that the certificates in our life are issued by the authority and cannot be forged.

For example, id card is issued by the police station, diploma issued by the Ministry of Education, if you need to verify true and false, only need to go up the relevant system input number query can be checked! Then our digital certificate should also have these two characteristics, issued by the authority, anti-counterfeiting!

CA is the authority that issues digital certificates and verifies the validity of certificates.

If the server needs to do a server with identity, you need to submit an application to CA institutions, of course, the money is good, pay money to you……

When the server submits an application to the CA, it needs to submit site information such as domain name, company name, public key, etc. After the CA approves the application correctly, it can issue a certificate to the server!

After obtaining the certificate of the server, the client needs to verify whether the certificate number can be found in the corresponding CA, and check the basic information of the certificate, such as whether the domain name on the certificate is consistent with the domain name currently accessed, etc., and obtain the public key information of the server in the certificate for negotiating symmetric keys!

The certificate is issued, but how to prevent forgery, how to ensure that the transmission process will not be tampered with? If Xiao Wang intercepted the digital certificate and changed the public key to his own, it would still be impossible to guarantee security, wouldn’t it? This requires a digital signature!

The friend that had signed labor contract with the company should know, fill in in contract information, cannot have alter, need to fill in afresh otherwise! And in the end, party A and Party B need to sign and seal.

Once signed and sealed, the contract has the legal effect and cannot be modified. Signature and seal operation is to prevent contract forgery, provisions can not be modified to prevent the contract was tampered with!

In real life, the operation of signature and seal is a real action, acting on a specific object!

But our digital certificate itself is virtual, how to sign and seal a virtual certificate? What is the mechanism of digital signature?

When we do the permission system, the user password will be stored after the MD5 calculation of the digest, in the login calculation of the password MD5 digest and the database storage of the digest, if the same password is correct, otherwise the login failed!

MD5 is irreversible, and the summary calculated by different data is not the same (of course, there is a very small probability of Hash collision), based on this feature, the idea of digital signature.

The server submits its basic information to the CA. When issuing a certificate to the server, the CA sends the digital certificate and the summary calculated based on the certificate to the server. The summary needs to be encrypted by the CA’s private key.

The application process is as follows:

What? Not intuitive? Then let’s have a straight one! As you can see from the following figure, the CA certificate issued to the server has its own “official seal”.

Which CA organizations are authoritative or approved by the client? We open IE browser can see the client built-in CA information, including CA public key, signature algorithm, validity period and so on…

When the server communicates with the client, it presents the digital certificate and digital signature to the client.

After obtaining the digital certificate and digital signature, the client uses the trusted CA in the operating system or browser to find the public key of the corresponding CA to decrypt the digital signature, and then uses the same digest algorithm to calculate the digest of the digital certificate.

If your calculated digest matches the digest sent by the server, the certificate has not been tampered with!

This prevents tampering! The third party can not get the CA organization’s private key, also cannot encrypt the abstract, if the third party forges the signature naturally in the client side also cannot decrypt, this prevents forgery!

Therefore, digital signature ensures that the digital certificate is tampered and forged through this mechanism. The specific process is as follows:

What? Not intuitive, right? So let’s move on…

One is the CA’s public key, built into the client, used to decrypt digital signatures! The other is the target server’s public key, in the digital certificate content, used to negotiate symmetric keys!

The title of this article is HTTPS, but so far HTTPS is not mentioned at all! HTTPS=HTTP+SSL, adding an SSL/TLS layer between the HTTP layer and TCP layer.

The diagram below:

SSL (Secure Sockets Layer) is called “Secure Sockets Layer” in Chinese. Later, due to the widespread use of SSL, it was changed to TLS (Transport Layer Security) after SSL standardization.

HTTPS is used to solve the problem of data leakage, tampering, and counterfeiting on the network.

See here, you understand the principle of HTTPS, anyway, my grandmother already understand! Manual dog head (*￣)