What is the principle of HTTPS communication?

HTTPS communication principle is: HTTPS is "HTTP over SSL/TLS". Compared with HTTP, HTTPS has one more layer of "SSL/TLS". HTTPS requires an exchange between the client and the server before transmitting data. Handshake. During the handshake process, the cryptographic information used by both parties to encrypt the transmitted data will be established.

Introduction:

HTTP protocol (HyperText Transfer Protocol, Hypertext Transfer Protocol): Is a client An application layer communication protocol between a browser or other program and a web server. HTTPS (full name: HyperText Transfer Protocol over Secure Socket Layer) can be understood as HTTP SSL/TLS, that is, an SSL layer is added to HTTP. The security foundation of HTTPS is SSL, so the details of encryption require SSL for secure HTTP data. transmission.

The difference between HTTPS and HTTP:

a. The https protocol requires you to apply for a certificate from ca. Generally, there are few free certificates and you need to pay a fee.

b. http is a hypertext transfer protocol, and information is transmitted in plain text; https is a secure SSL encrypted transmission protocol.

c. http and https use completely different connection methods and use different ports. The former is 80 and the latter is 443.

d. The http connection is very simple and stateless; the HTTPS protocol is a network protocol built from the SSL HTTP protocol that can perform encrypted transmission and identity authentication, and is more secure than the http protocol.

The role of HTTPS

Its main functions can be divided into two types: one is to establish an information security channel to ensure data transmission security; the other is to confirm the authenticity of the website.

　a． In the general sense, https means that the server has a certificate. The main purpose is to ensure that the server is the server it claims to be. This is the same as the first point; all communications between the server and the client are encrypted.

b. Specifically, the client generates a symmetric key and exchanges the key through the server's certificate, which is a handshake process in a general sense. This part will be introduced in detail below.

c. All subsequent information exchanges will be encrypted. Even if a third party intercepts it, it is meaningless because he does not have the key, and of course there is no point in tampering with it.

　d． In some cases where there are requirements for the client, the client must also have a certificate.

Why the HTTPS protocol is needed:

HTTP protocol is an unencrypted plain text transmission protocol. If the Client (APP, browser) uses HTTP transmission Data will be leaked and the transmission content may be hijacked by middlemen to modify the transmission content. As shown in the figure below, a typical APP HTTP communication is hijacked and modified by the operator, and advertisements are inserted:

##In order to protect users' information security, protect their business interests, and reduce the attack surface, we need to ensure the security of the communication channel. It is a better way to use HTTPS, which is easy to develop.

HTTPS Communication Principle

HTTPS is HTTP over SSL/TLS, HTTP is the application layer protocol, TCP is the transport layer protocol, between the application layer and the transport layer, Added a secure socket layer SSL/TLS:

As shown in the figure above, HTTPS has an additional layer of SSL compared to HTTP. /TLS, the SSL/TLS layer is responsible for encryption and decryption algorithm negotiation, key exchange, and establishment of communication connections between the client and the server.

HTTPS requires a handshake between the client (browser) and the server (website) before transmitting data. During the handshake process, the password information for both parties to encrypt the transmitted data will be established. The TLS/SSL protocol is not only a set of encrypted transmission protocols, but also a work of art carefully designed by an artist. TLS/SSL uses asymmetric encryption, symmetric encryption and HASH algorithms. The handshake process is as follows:

(1).client_hello

The client initiates a request and transmits the request information in clear text, including version information and cipher suite Candidate list, compression algorithm candidate list, random number, extension field and other information, the relevant information is as follows:

• The highest supported TSL protocol version, from low to high, SSLv2 SSLv3 TLSv1 TLSv1 .1 TLSv1.2, versions lower than TLSv1 are basically no longer used;

• List of cipher suites supported by the client, each cipher suite corresponds to the previous TLS principle A combination of four functions: authentication algorithm Au (identity verification), key exchange algorithm KeyExchange (key negotiation), symmetric encryption algorithm Enc (information encryption) and information digest Mac (integrity verification);

• List of supported compression methods compression methods, used for subsequent information compression and transmission;

• Random number random_C, used for subsequent key generation;

• Extensions field extensions support protocol and algorithm related parameters and other auxiliary information. Common SNI is an extension field, and the role of this field will be discussed separately later.

(2).server_hello server_certificate sever_hello_done

• server_hello, the server returns the negotiation information results, including the protocol version chosen to use, The selected cipher suite, the selected compression algorithm compression method, random number random_S, etc., where the random number is used for subsequent key negotiation;

• server_certificates, corresponding to the server-side configuration Certificate chain, used for authentication and key exchange;

• server_hello_done, notifies the client that the server_hello information sending is completed;

(3) .Certificate Verification

The client verifies the validity of the certificate. If the verification is passed, subsequent communication will be carried out. Otherwise, prompts and operations will be made according to different error conditions. Legality verification includes the following:

• The trusted certificate path of [certificate chain], the method is as mentioned above;

• Whether the certificate is revoked or revocation, there are two methods: offline CRL and online OCSP. Different clients will behave differently;

• Validity date, whether the certificate is in Valid time range;

• Domain name domain, check whether the certificate domain name matches the current access domain name, and subsequent analysis of the matching rules;

(4 ).client_key_exchange change_cipher_spec encrypted_handshake_message

(a) client_key_exchange, after the legality verification is passed, the client calculates and generates a random number Pre-master, encrypts it with the certificate public key, and sends it to the server;

(b) At this time, the client has obtained all the information needed to calculate the negotiation key: two plaintext random numbers random_C and random_S and the Pre-master generated by its own calculation, and the negotiation key is calculated Key;

enc_key=Fuc(random_C, random_S, Pre-Master)

(c) change_cipher_spec, the client notifies the server of subsequent communications The negotiated communication key and encryption algorithm are used for encrypted communication;

(d) encrypted_handshake_message, combines the hash value of all previous communication parameters and other related information to generate a piece of data, using the negotiated encryption The key session secret is encrypted with the algorithm and then sent to the server for data and handshake verification;

(5).change_cipher_spec encrypted_handshake_message

( a) The server decrypts the encrypted Pre-master data with the private key, and calculates the negotiation key based on the two plaintext random numbers random_C and random_S previously exchanged: enc_key=Fuc(random_C, random_S, Pre-Master);

(b) Calculate the hash value of all previously received messages, then decrypt the encrypted_handshake_message sent by the client, and verify the correctness of the data and key;

(c ) change_cipher_spec, after the verification is passed, the server also sends change_cipher_spec to inform the client that subsequent communications will use the negotiated key and algorithm for encrypted communication;

(d) encrypted_handshake_message, the server also combines All current communication parameter information generates a piece of data and is encrypted using the negotiated key enc_key and algorithm and sent to the client;

(6). The handshake ends

The client calculates the hash value of all received messages, uses the negotiated key to decrypt the encrypted_handshake_message, and verifies the data and key sent by the server. If the verification passes, the handshake is completed;

( 7). Encrypted communication

Start using the negotiated key and algorithm for encrypted communication. The timing diagram is as follows:

Verification certificate

In (3) certificate verification, the client will verify the certificate sent by the server. Let’s take a look at the process in detail. What work has been done

1. Verify the issuer and validity period

2. Verify whether it is in the trust list

2. Verify legitimacy

When verifying the certificate, the client reads the relevant plaintext information in the certificate and uses the same hash function to calculate the information. digest, and then use the public key of the corresponding CA (retrieved locally) to decrypt the signature data and compare it with the information digest of the certificate. If they are consistent, the legitimacy of the certificate can be confirmed, that is, the public key is legitimate;

Certificate content:

Applicant’s public key, applicant’s organizational information and personal information, issuing authority CA information, validity time, certificate serial number and other information in plain text, at the same time Contains a signature;

Signature generation: use a hash function to calculate the information digest of the public plaintext information, and then use the CA's private key to encrypt the information digest, and the ciphertext is the signature .

​

#Tips;

1. The Client uses the public key sent by the Server to encrypt the data, and sends the encrypted data to the Server. The Server uses the private key to decrypt, which is asymmetric encryption

2. When both Client and Server have mastered the negotiation key enc_key, both parties will use the key to encrypt and decrypt. This is symmetric encryption

Overview of encryption algorithms

The function implementation of TLS/SSL mainly relies on three types of basic algorithms: hash function Hash, symmetric encryption and asymmetric encryption, which uses asymmetric encryption to achieve identity authentication and Key negotiation, symmetric encryption algorithm uses the negotiated key to encrypt data, and verifies the integrity of the information based on the hash function.

##1. Symmetric encryption

There are two types: streaming and grouping. The same key is used for encryption and decryption.

For example: DES, AES-GCM, ChaCha20-Poly1305, etc.

2. Asymmetric encryption

The key used for encryption and the key used for decryption are different, respectively called: public key, private key, public key The key and algorithm are public, and the private key is kept secret. The asymmetric encryption algorithm has low performance, but is highly secure. Due to its encryption characteristics, the length of data that the asymmetric encryption algorithm can encrypt is also limited.

For example: RSA, DSA, ECDSA, DH, ECDHE

3, Hash algorithm

Convert information of any length into a shorter fixed-length value, usually its length is much smaller than the information, and the algorithm is irreversible.

For example: MD5, SHA-1, SHA-2, SHA-256, etc.

4, digital signature

The signature is to add a piece of content after the information (the value of the information after hashing), which can prove that the information has not been modified. The hash value is usually encrypted (that is, signed) and then sent together with the message to ensure that the hash value is not modified.

Two-way authentication:

The server can also require verification of the client, that is, two-way authentication. The client can send client_certificate_request information in process 2. In process 4, client_certificate and certificate_verify_message information are sent first. The verification method of the certificate is basically the same. The certificate_verify_message is a piece of data based on the negotiated communication information encrypted with the client's private key. The server can use the corresponding public key to decrypt and verify it.

The above is the detailed content of What is the principle of HTTPS communication?. For more information, please follow other related articles on the PHP Chinese website!