1. Understand HTTPS

1, define,

A transport protocol for secure communication over a computer network. HTTPS is an SSL/TLS encryption layer over HTTP and encrypts transmitted data. In simple terms, HTTPS is the secure version of HTTP protocol.

2. Introduction to TLS/SSL protocol

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

3, encryption and decryption related knowledge introduction

3.1. Symmetric encryption

Encryption and decryption using the same key is called symmetric encryption, also known as Common key crypto system.

Common symmetric Encryption methods are Data Encryption Standard (DES), Advanced Encryption Standard (AES), RC4, and IDEA

3.2. Asymmetric encryption

Asymmetric encryption Encryption uses a pair of asymmetric keys. One is called a private key

(private key), and the other is called public key. As the name implies, a private key cannot be known to anyone else, while a public key can be distributed at will and available to anyone. Also known as public key encryption

(1) Party B generates two keys (public key and private key). The public key is public and accessible to anyone, while the private key is private. (2) Party A obtains Party B’s public key and uses it to encrypt the information. (3) Party B shall use the private key to decrypt the encrypted information after obtaining it.

Common asymmetric encryption algorithms are RSA algorithm and ECC algorithm

3.2. Digital signature

Digital signature, simply put, is a way of verifying one’s own identity by providing identifiable digital information. A set of digital signatures typically defines two complementary operations, one for signing and one for verification. The sender holds a private key that can represent his identity (the private key cannot be disclosed), and the receiver holds a public key corresponding to the private key, which can be used to verify the identity of the sender when receiving the information of the sender. Digital signature has new functions of verifying identity and ensuring information integrity.

3.2.1 Digital signature generation

A piece of text is hashed to generate a message digest, which is encrypted with a private key to generate a digital signature.

3.2.2 Digital signature verification

Assume that A communicates with B. A sends A message and A signature to B. After receiving the message,B can verify whether the message is sent by A and whether it has been tampered with.

Assume that B know A public key, through the public key can decrypt the message digest is encrypted, then use hash (hash) to receive the original produce A message digest, compared with previous step get message digest, if same, then receive the information is complete, has not been modified in the process of transmission, or that information has been modified, Therefore, digital signatures can verify the integrity of information.

3.2.3 Certificate Authorities

In the previous article, it is assumed that the public key is known when verifying the digital signature. The crux of the problem is that the public key itself is not directly sent over an insecure network, just like the message. At this point, the Certificate Authority (CA) is introduced. There are not many cas. Client B has built-in certificates of all trusted cas. After the CA digitally signs the public key (and other information) of A, A certificate is generated.

After user A sends the certificate to user B, user B verifies the certificate signature using the public key of the CA certificate.

B trusts CA, and CA trusts A causes Bob to Trust A. This is how the Chain Of Trust is formed. In fact, client B has a built-in Root Certificate of CA. In HTTPS, the server sends a Certificate Chain to the client.

3.2.4, certificate

Certificates include:

  • Name of the certificate authority
  • The digital signature of the certificate itself
  • Certificate Holder public key
  • Hash algorithm used for certificate signing

The business process of the digital Certificate Authority:

  • The server operator submits the public key, organization information, and personal information (domain name) to the third-party organization (CA) and applies for authentication.
  • CA verifies the authenticity of the information provided by the applicant through various online and offline means, such as whether the organization exists, whether the enterprise is legal, whether the ownership of the domain name, etc.
  • If the information is approved, CA will issue a certificate to the applicant. A certificate contains the following information: the public key of the applicant, the organization and personal information of the applicant, the information of the issuing authority (CA), the validity period, the serial number of the certificate, and a signature. The signature generation algorithm is as follows: firstly, the hash function is used to calculate the information digest of the open plaintext information, then the CA private key is used to encrypt the information digest, and the ciphertext is the signature.
  • When the Client sends a request to the Server, the Server returns a certificate file.
  • The Client reads the plaintext information in the certificate, uses the same hash function to calculate the information digest, decrypts the signature data with the public key of the corresponding CA, and compares the information digest of the certificate. If the information digest is consistent, the Client can verify the validity of the certificate, that is, the public key of the server is trustworthy.
  • The client also verifies the domain name and validity period related to the certificate. The client has built-in information about the trusted CA certificate (including the public key). If the CA is not trusted, the CA certificate cannot be found and the certificate is determined to be invalid.

Iv. HTTPS workflow

2. Differences between HTTPS and HTTP

1. HTTP information is transmitted in plaintext; HTTPS is the SECURE SSL/TLS encrypted transport protocol.

2. The default HTTP port is 80. 3, HTTPS is more friendly to search engines, conducive to SEO, Google, Baidu priority index HTTPS web pages;

3. HTTPS versus HTTP

HTTPS is not a new protocol at the application layer. It is only used for HTTP communication interface

The Secure Socket Layer (SSL) and Transport Layer Security (TLS) protocols are used instead.

  1. Content encryption: The content is symmetrically encrypted, and each connection generates a unique encryption key to ensure the data security during transmission;
  2. Identity authentication: Verify the authenticity of the website. A third party cannot forge the identity of the server (client)
  3. Data integrity: The integrity of the content is verified before transmission to prevent the content from being imitated or tampered with by third parties

Iv. HTTPS workflow

  1. Client has launched a HTTPS (HTTPS: / demo. Linianhui. Dev) request, according to the regulation of RFC2818, know the Client needs to connect Server port 443 (the default).
  2. The Server returns the configured public key certificate to the client.
  3. Client Verifies the public key certificate: For example, whether the certificate is within the validity period, whether the purpose of the certificate matches the site requested by the Client, whether it is in the CRL revocation list, and whether its upper-level certificate is valid. This is a recursive process until the Root certificate (the built-in Root certificate of the operating system or the built-in Root certificate of the Client) is verified. If the authentication succeeds, the system continues. If the authentication fails, a warning message is displayed.
  4. The Client uses a pseudorandom number generator to generate the session key for encryption, encrypts the session key with the public key of the certificate, and sends it to the Server.
  5. The Server uses its private key to decrypt the message and obtain the session key. At this point, both the Client and Server hold the same session key.
  6. The Server encrypts plaintext A using the session key and sends it to the Client.
  7. The Client uses the session key to decrypt the ciphertext of the response to obtain plaintext A.
  8. The Client sends an HTTPS request again and uses the session key to encrypt the plaintext B of the request. The Server then uses the session key to decrypt the ciphertext to obtain plaintext B.