Introduction of HTTPS

HTTPS is based on SSL/TLS protocol. SSL was originally designed by NetScape in 1994 and has been updated for three versions. In 1999, IT was standardized to TLS by IETF, which implements a layer of secure protocols on the basis of TCP, including handshake, certificate delivery and key negotiation. It is the basis of Internet security, but also the basic means to solve the HTTP request being replayed, tampered with, transmission leakage.

TLS1.2 Handshake process

TLS1.2 Handshake process is as follows:

  1. The Client sends a Client Hello packet to initiate a handshake. The packet contains TLS versions supported by the Client, encryption algorithms supported by the Client, and Client Random. Encryption algorithms include key exchange algorithm, encryption algorithm, and hash algorithm. Generally, HTTP client implementations combine these three algorithms into a cipher suite (one key exchange algorithm, one encryption algorithm, and one hash algorithm) for the server to select.
  2. The Server sends A “Server Hello” packet containing the digital certificate of the Server, the encryption suite selected by the Server, and the Random string “Server Random”. The digital certificate contains the public key A used for key exchange.
  3. The client verifies and parses the certificate, obtains public key A, generates random string “premaster secret”, and encrypts random string with public key A.
  4. The client sends the random string “premaster secret” to the server.
  5. The client and Server use “Client Random”, “Server Random”, and “premaster Secret” to generate a shared key C, which is used to encrypt the plaintext of subsequent HTTP communications.
  6. The client sent a Finished packet encrypted with key C.
  7. The server sent a Finished packet encrypted with key C.
  8. The handshake is complete, and subsequent HTTP traffic is encrypted using key C.

Cipher specifications and cipher suites

The algorithms used by the communication parties in the secure connection must comply with the password security protocol.

CipherSpecs is a combination of authentication encryption algorithms and message digest algorithms that both parties must agree to in order to communicate. CipherSuites define the combination of encryption algorithms (CipherSuites) used in SSL/TLS secure connections.

A password combination contains three different algorithms:

  1. Key exchange and authentication algorithms used during the handshake (most commonly RSA)
  2. Encryption algorithm (used for symmetric encryption after handshake, AES, 3DES, etc.)
  3. Information digest algorithms (commonly used are SHA-256, SHA-1, MD5, etc.)

Here are some commonly used encryption suites

TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
 
Copy the code

The digital certificate

Digital certificates are used to authenticate public key holders and prevent third parties from impersonating them. The common certificate format is X.509. Certificate Authority (CA) is an organization that issues and manages digital certificates. Currently, popular CA organizations include DigiCert, Globalsign, Thawte, and GoDaddy.

CA organization is a tree structure, and there are two types of CA: root CA and intermediates CA. A root CA can contain multiple intermediates CAs, and an intermediates CA can contain multiple intermediates CAs. Both root CAs and intermediates CAs can issue certificates to users.

Let’s take Baidu’s certificate as an example to take a look at the composition of digital certificates.

The content of a digital certificate includes information about the certificate owner (subject information), information about the certificate issuing authority (issuer name), public key and digital signature of the certificate.

If we look at Baidu’s digital certificate, there are two levels of certificates above it, and the next level is issued by the next level. We call this structure certificate chain. Certificates fall into three categories:

  1. End-user certificate: Baidu.com certificate contains the key A mentioned above, which is also the certificate transferred from the server to the client in HTTPS protocol.
  2. Intermediates certificate: The GlobalSign Organization Validastion CA is the certificate used by the CA to authenticate the identity of the public key holder, that is, to confirm that the end-user certificate used by HTTPS belongs to Baidu.com.
  3. Root Certificate: The GlobalSign Root CA is the root certificate used to authenticate the intermediates certificate as a valid certificate.

Certificate verification on the client

The client verifies certificates as follows:

  1. Verify the certificate chain to ensure that the server certificate is issued by a CA trusted by the client.
  2. Check the digital signature to ensure that the certificate has not been tampered with in transit.
  3. Check the validity period of the certificate.
  4. Check the rollback status of the certificate.

Validation of the certificate chain

The verification of the certificate chain is actually a process of judging whether the CA certificate can be trusted step by step. In the browser or operating system, some Root Certificates, also known as Trusted Root Certificates, are built in. The client obtains a list of trusted certificates (usually system root certificates or user certificates) and checks whether the CA certificate of the server is in the credit list:

  1. If the certificate is in the credit list, it indicates that the certificate is trusted, and other verification is continued.
  2. If the certificate is not in the credit list, it indicates that the certificate is not trusted. The processing of the untrusted certificate depends on the implementation of the client.

Signature verification

The above picture briefly illustrates the certificate issuing and verification process, through which we can observe the generation and verification of digital signatures:

Generation of digital signature:

  1. In the Signing phase, write the meta-information of the certificate, including the Issuer, address, issue time, expiration date, etc. Of course, the information also contains basic information about the owner of the certificate, such as the OWNER’s DN(DNS Name, that is, the domain Name where the certificate takes effect) and the owner’s public key.
  2. Abstract information is extracted by the general Hash algorithm.
  3. The Hash digest is asymmetric encrypted using the Issuer(CA) private key to generate a signed ciphertext.
  4. Attach the signed ciphertext to the document certificate to make it a signed certificate.

Verification of digital signature:

  1. In the Verification phase, the client obtains a previously issued certificate.
  2. After decompression, metadata and signature ciphertext are obtained respectively.
  3. Apply the same Hash algorithm to the “metadata” to get the digest;
  4. The ciphertext is decrypted through the public key (asymmetric algorithm, private key encryption, and public key decryption) of Issuer(CA) to obtain the same digest value.
  5. If the two digests match, it indicates that the certificate is a valid certificate verified by the CA and the public key information in the certificate is trusted.

conclusion

  1. HTTPS is an SSL/TSL layer on top of HTTP.
  2. The ultimate purpose of TLS handshake is to determine the key used to encrypt HTTP communication content. RSA is the key exchange algorithm commonly used in HTTPS.
  3. The digital certificate protects the public key through digital signature and verifies the identity of the public key holder through the certificate chain.

reference

HTTPS: WORKING principle of SSL/TLS and detailed handshake process

Public key certificate

Certificate chain -Digital Certificates

Discussion on SSL handshake, certificate, certificate verification