Before THE advent of HTTPS, data interaction through HTTP is transmitted in plaintext. During the transmission of network data, when certain conditions are met, such as passing through gateways, routers, and wifi hotspots, data packets may be hijacked by middlemen, posing a great threat to data security. In order to solve this problem, HTTPS appears. HTTPS is the HTTP protocol that encrypts HTTP data for secure transmission by adding SSL/TLS, and at the same time, port 443 is enabled for data transmission by default. How does HTTPS ensure the security of data transmission? That starts with how data is encrypted.
Symmetric and asymmetric encryption
The process of data encryption is to convert the original plaintext data into an unreadable ciphertext according to a certain algorithm. The original content can be displayed only after the corresponding key is decrypted. Encryption algorithms can be classified into symmetric encryption and asymmetric encryption.
-
Symmetric encryption: Is one of the most simple encryption, encryption and decryption are using the same string keys, encryption efficiency is very high, the encryption intensity as the key size increasing, the key as easy to crack, the more difficult it is to crack conversely, encryption and decryption speed is proportional to the key size, symmetry using relatively small key, generally less than 256 bits, both to ensure a degree of safety, Efficiency should be taken into account.
-
Asymmetric encryption: The encryption speed is slow. Two different key pairs are required for encryption and decryption. The key pair contains a public key and a corresponding private key. A public key is the public part of a key pair, while a private key is the private part. A public key is usually used for session encryption, verifying digital signatures, or encrypting data that can be decrypted with the corresponding private key.
How HTTPS works
HTTPS Before data transmission, a handshake is required between the client and server. During the handshake, the password of the encrypted data is confirmed. In this process, TLS/SSL is used. TLS/SSL is a standard for encryption channels. SSL was developed by netscape in the past. The handshake process is as follows:
-
The client sends a connection request to the server and informs the server that an HTTPS connection will be established. In this case, the client also sends the encryption algorithm supported by the client to the server.
-
When the server receives this encryption algorithm, it compares it with its own encryption algorithm (that is, the server compares it with its own private key). If the algorithm does not match, the server disconnects. If the algorithm matches, the server selects a set of encryption algorithm and HASH algorithm, and sends its identity information to the browser in the form of a certificate. The certificate contains information such as the website address, encrypted public key, HASh algorithm of the signature, and certificate authority.
-
After the client has obtained the website certificate:
- First, use the root certificate to verify that the authority issuing the certificate is legitimate, that the website address contained in the certificate is the same as the address being accessed, and so on. If the certificate is trusted, the browser will display a lock icon on the left side of the address bar, otherwise it will give a warning that the certificate is not trusted.
- Second, if the certificate is trusted, which it may not be (it may be a homemade certificate or an integer issued by a non-authoritative authority), the browser generates a password (an RSA signature) of a random number and encrypts it with the public key provided in the certificate.
- Finally, the HASH algorithm is used to calculate the handshake message, and the generated password is used to encrypt the message to ensure that the handshake information returned to the server is not tampered, and all the previously generated information is sent to the server.
-
After receiving the data from the client, the server uses its private key to decrypt the information and retrieve the password, decrypts the handshake message from the browser with the password, and verifies whether the HASH is consistent with that from the client. If they are the same, use random strings to encrypt the handshake information and send the HASH value of the handshake information to the client.
-
After receiving the message, the client decrypts and computes the HASH of the handshake message. If the HASH is the same as that sent by the server, the handshake is complete.
The preceding procedure is used to verify the connection between the client and server for the first time. After the connection is successfully verified, the connection is secure.
Why not use simpler encryption
HTTPS uses symmetric encryption for data transmission and asymmetric encryption for certificate authentication. Why is this method adopted? Since symmetric encryption is more efficient, why not just use symmetric encryption?
First to assume the use of symmetric encryption server and client communication, to establish communication between the two sides, the server to generate a key, how to safely transmit the keys to a client is the most difficult problem, middlemen in the process of transmission could be hijacked to get the key, then the content of the follow-up to communicate with the server and the client will also be an intermediary to parse, There are always security issues. Of course, if the client has a pre-stored key for the web site and the key is not transmitted over the network, it is obviously safe in theory for the content to be transmitted, but it is obviously not practical.
The same, regardless of the server and client using asymmetric encryption and asymmetric encryption + asymmetric encryption scheme (this can be very time consuming), public key in the process of A transmission to the client, because is clear text transmission, there will be A lot of risk is to hijack the middleman, it is belong to the middle attack, middlemen to tamper with the public key, for example, The middleman transmits his public key B to the client, and the client cannot determine whether public key B is from the server. Data security problems still occur when the public key used by the client is transmitted to the client. Therefore, in the process of encrypted transmission, it is very important to ensure that the client receives the key from the server.
SSL certificate
During the handshake, the password for data encryption is determined. In this core process, the server sends an SSL certificate to the client. The SSL certificate is used for HTTP encryption and is the identity certificate of an HTTPS website. That ensure the client receives the public key and other information from the server, the server can secure the encryption algorithm, HASH algorithm, and their identity information sent to the browser in the form of a certificate, in addition, the certificate which contains the address of the server, the encryption public key, the certificate is valid and the certificate issuing authority. SSL certificates can be purchased from the CA or made by yourself.
Verify the SSL certificate
As mentioned above, SSL certificates can be purchased from THE CA or made by yourself. The certificates made by yourself are not trusted by the browser and will give a warning due to certificate verification failure when accessing. For example, when you visit some strange websites, do you need to install an unauthorized root certificate because the websites cannot be accessed? If the client considers the certificate authority of the site to be untrustworthy, you will have to manually download and install the root certificate of the authority, and there may be some risk. How are trust and untrust judged?
The operating system and browser of a computer pre-install some trusted root certificates. If there is a CA root certificate, you can determine whether the current certificate is trusted by judging the certificate returned by the server through the root certificate.
The authentication between certificates can also be organized in the form of A certificate chain. A can trust B, B trusts C, and so on, namely, the trust chain. That is, a series of digital certificates, starting from the root certificate, through layers of trust, so that the holder of the terminal entity certificate can be granted trust to prove identity.
The above is an HTTPS encryption process, many places did not carry out in-depth coverage, if there are omissions, welcome to correct.