HTTPS principles and related knowledge

An overview of the

Http is a plaintext communication protocol with some risks:

  1. Eavesdropping: The contents of communications may be known to a third party
  2. Tampering: Third parties may modify communications
  3. Impersonation (pretending): A third party can impersonate another person to participate in communication

The SSL/TLS protocol is designed to address these three risks:

  1. All messages are encrypted, so third parties can’t eavesdrop.
  2. With a verification mechanism, once tampered, communication parties will immediately discover.
  3. Equipped with an identity certificate to prevent false identity.

The principle of SSL/TLS

The BASIC idea of SSL/TLS is asymmetric encryption. The client obtains the public key from the server and uses the public key to encrypt information. After receiving the ciphertext, the server uses the private key to decrypt it.

  1. How to ensure that the public key is not tampered with

Put the public key in the digital certificate. The public key is trusted as long as the certificate is trusted.

  1. If the amount of public key encryption calculation is too large, how to reduce the time

For each session, a session key is generated between the client and server. This is a symmetric encryption process, and the operation is fast. The server public key is only used to encrypt the session key, which reduces the time consumed in encryption operation.

Therefore, the SSL/TLS encryption process is basically as follows:

  1. The client requests and validates the public key from the server
  2. The two parties negotiate to generate a dialogue key
  3. Use the conversation key for encrypted communication.

The first two parts of the process are called “handshake”

Overview of the handshake phase

Basic running process

The BASIC idea of SSL/TLS is asymmetric encryption. The client obtains the public key from the server and uses the public key to encrypt information. After receiving the ciphertext, the server uses the private key to decrypt it.

  1. How to ensure that the public key is not tampered with

Put the public key in the digital certificate. The public key is trusted as long as the certificate is trusted.

  1. If the amount of public key encryption calculation is too large, how to reduce the time

For each session, a session key is generated between the client and server. This is a symmetric encryption process, and the operation is fast. The server public key is only used to encrypt the session key, which reduces the time consumed in encryption operation.

Therefore, the SSL/TLS encryption process is basically as follows:

  1. The client requests and validates the public key from the server
  2. The two parties negotiate to generate a dialogue key
  3. Use the conversation key for encrypted communication.

The first two parts of the process are called “handshake”

Details of the handshake phase

Client sends a request (ClientHello)

The client initiates a ClientHello request with the following information:

(1) Supported protocol version, such as TLS version 1.0. (2) A client-generated random number A, which is later used to generate the "conversation key". (3) Supported encryption methods, such as RSA public key encryption. (4) Supported compression methods.Copy the code

The information sent by the client does not include the domain name of the server, which means that the server can theoretically contain only one website, otherwise there is no way to know which website’s digital certificate should be provided to the client, which is why the server usually can only have one digital certificate.

For virtual host users, this is of course very inconvenient. In 2006, the TLS protocol added a Server Name Indication extension that allows a client to provide a requested domain Name to the Server.

In this case, the client has key A

Server response (SeverHello)

The server receives a client request and returns ServerHello:

(1) Confirm the version of the encrypted communication protocol, such as TLS 1.0. If the browser does not match the version supported by the server, the server turns off encrypted communication. (2) a random number B generated by a server, which is later used to generate the "conversation key ". (3) Confirm the encryption method used, such as RSA public key encryption. (4) Server certificate (containing the server's public key information).Copy the code

In addition to the above information, if the server needs to verify the client’s identity, it will include a request for a “client certificate”. For example, a financial institution will only allow r to authenticate the client’s connection to the network, and will provide the real client with a USB key that contains a client certificate.

In this case, the server has keys A and B

Client Response

After receiving the response from the server, the client verifies the validity of the certificate as follows:

  1. Verify the validity of the certificate (start and end time)
  2. Verify certificate domain name
  3. Verify the certificate revocation status
  4. Validates certificate authorities and, if an authority is an intermediate certificate, validates intermediate certificatesExpiry date/issuing authority/revocation status. Verify all the way to the last layer of certificate, if the last layer of certificate is built in the operating system or browser, then it is trusted, otherwise it is self-signed certificate (layer upon layer authentication mechanism)

All the preceding verification steps must be passed. Otherwise, a warning is displayed.

If there is no problem with the certificate, the public key is taken out for encryption and the following message is sent to the server:

(1) a random number C. The random number is encrypted with the server's public key to prevent eavesdropping. (2) Notification of encoding change, indicating that subsequent information will be sent using encryption methods and keys agreed by both parties. (3) Notification of the end of client handshake, indicating the end of client handshake. This item is also the hash value of all the previously sent content for the server to verify.Copy the code

At this point, the client has keys A, B, and A random number C

The random number of the first item is the third random number in the whole handshake phase, also known as the “pre-master key”. With this, the client and server have three random numbers at the same time, and each generates a “session key” for this time using the implementation-agreed encryption method.

Both the client and the server need random numbers so that the generated key is not the same every time. Because SSL certificates are static, it is necessary to introduce a randomness factor to ensure the randomness of the negotiated keys.

For the RSA key exchange algorithm, the pre-master-key itself is a random number, plus the randomization in the Hello message, three random numbers through a key exporter finally exported a symmetric key.

Pre Master exists because SSL protocol does not trust each host to generate completely random random numbers. If the random number is not random, pre Master Secret may be guessed, so it is not appropriate to only use Pre Master Secret as the key. Therefore, it is necessary to introduce a new random factor, so it is not easy to guess the key generated by the client and server together with the three random numbers pre Master secret. One pseudo-random may not be random at all, but three pseudo-random will be very close to random. Every increase of one degree of freedom, the randomness will not increase by one.

In addition, if the server requested a client certificate in the previous step, the client sends the certificate and related information in this step.

The server’s final response

The server receives the third random number from the client, decrypts it with its own private key, calculates and generates the session key used for this session, and then sends the following information to the client:

(1) Notification of encoding change, indicating that subsequent information will be sent using the encryption method and key agreed by both parties. (2) Notification indicating that the handshake phase of the server is over. This item is also the hash value of all the previously sent content for the client to verify.Copy the code

At this point, the whole handshake phase is over. Next, the client and server enter encrypted communication using the plain HTTP protocol, but with a “session key” to encrypt the content.

At this point, the server has the keys A, B, and the random number C. A, B is fixed, and the random number C is generated with the current request

Man-in-the-middle attack

The process of man-in-the-middle attack is as follows:

  1. The server sends the public key to the client.
  2. An attacker intercepts the public key and keeps it.
  3. The attacker then generates a forged public key and sends it to the client.
  4. After receiving the forged public key, the client generates an encrypted hash value and sends it to the server.
  5. The attacker obtains the encrypted hash value and decrypts it with its own private key to obtain the transmission key.
  6. Generates a fake encrypted hash value and sends it to the server.
  7. The server decrypts the private key to obtain the fake secret key.
  8. The server encrypts the transmission with a secret key

In this way, the browser is tricked and the key X is obtained without exception on both the server and client. More fundamentally, the browser cannot confirm that the public key it receives is the site’s own.

Prevention methods:

After the server adds a CA certificate to the public key of the browser, the browser can verify the validity of the CA certificate

The digital certificate

Before using HTTPS, a website needs to apply for a digital certificate from the CA. The digital certificate contains information about the certificate owner and public key. The server sends the certificate to the browser, which obtains the public key from the certificate, which is the server’s ID card. Prove that the public key pair should match the web site.

The key question here is: “How can the certificate itself be prevented from being tampered with during transmission?” How to prove the authenticity of the certificate itself? This is where digital signature technology comes into play.

A digital signature

The process for creating and verifying a digital signature is as follows:

Digital signature production process:

  1. The CA has private and public keys that are asymmetrically encrypted
  2. CS hashes the plaintext information of the certificate
  3. The hash value is signed with a private key to obtain a digital signature

The plaintext and digital signature together form a digital certificate, so that a digital certificate can be issued to a web site.

Browser verification process:

  1. Get the certificate, get the clear text T, the digital signature S
  2. Decrypt S with the public key of the CS mechanism (the mechanism the browser trusts, so the browser keeps its public key) and get S’.
  3. I’m going to hash plain T using the hash algorithm in the certificate to get T prime.
  4. Compares whether S’ is equal to T’, true to indicate that the certificate is trusted (not tampered with)

Revocation checking

At present, there are two kinds of revocation status check protocols written into international standards: 1.CRL, 2. OCSP

A CRL is a comprehensive file that records the serial numbers of all revoked certificates restricted by the CRL. By matching the serial number of the current certificate with the serial number in the CRL.

As long as one of the CRL certificates with this URL is revoked, the CRL will be matched in the next update. Can we assume that there is only one CRL list of certificates issued by an intermediate authority? Can’t be! Because the number may be too large, the manufacturer can divide the final certificate issued by the same intermediate certificate into different CRLS in different batches. OCSP is a TCP service. By requesting the certificate serial number, the server tells whether the current serial number is in the revoked list.

Some certificates have built-in CRL+OCSP, some have only built-in OCSP, and some early certificates have only built-in CRL. However, certificates with only built-in CRL are not trusted by modern browsers.

Revocation status check, synchronous or asynchronous?

Synchronous: If the check is performed asynchronously, the certificate may be revoked after the browser sends data to an unauthenticated host for a period of time. So, you have to synchronize

Issued to

The issuer of the certificate is obtained by following the steps

  1. If the server certificate contains a certificate chain, the browser will try to match (according to the “issuer public key” of the current certificate, the “public key” of the subsequent certificate in the chain). If the match fails, go to 2.

  2. If the certificate contains the issuer URL, the browser tries to download it. If the match fails, go to 3

  3. The public key of the built-in certificate of the operating system or client browser matches. If the match fails, ERR_CERT_AUTORITY_INVALID is displayed.

  4. Additional: If any level 1 certificate has an oID declared, it will be displayed by the browser as EV(green address bar with company name).

Refer to the link

  • Overview of the SSL/TLS protocol operation mechanism
  • A secure and reliable communication – HTTPS principle
  • Getting started with HTTPs, illustrating SSL from Carriage return to handshake
  • Understand HTTPS encryption thoroughly
  • The illustration of HTTP