preface

HTTPS (HTTP + SSL/TLS) : HTTP is used for plaintext transmission. Data may be leaked or tampered by middlemen during transmission. HTTPS prevents this problem.

When accessing an HTTPS site, the browser establishes an SSL handshake with port 443 on the server before encrypting and transmitting the data using the key negotiated during the handshake. The SSL handshake provides the following functions:

  • Verify that the server certificate is valid.
  • Negotiate the encryption algorithm and the key used for symmetric encryption (ensuring that this key is not leaked is key).

SSL Handshake Procedure

guess

So how to ensure that the key is not disclosed during the handshake?

First of all, asymmetric encryption can be thought of. The server generates a pair of public and private keys and sends the public key to the browser, which then encrypts the symmetric encryption key using the public key. Even if the middleman obtains the server public key and the information, the information cannot be obtained because the public key cannot unlock the encrypted ciphertext of the public key.

This method is insecure, because when the server delivers pub_key, the middleman can forge a new pair of public and private keys, and then send his forged public key to the browser. At this time, the information sent by the browser can be seen and tampered with by the middleman.

CA certification

The problem is that the public key issued by the server cannot be identified. The certificate issued by the CA can solve the problem.

In the CA authentication system, all certificates are issued by the authority, and the CA certificates of the authority are built-in in the operating system. These certificates are called CA root certificates.

Certificate issued by

Our application server if you want to use SSL, need the CA certificate issued by authoritative certification body, we will server to generate a public key and site information sent to the CA issued by institutions, issued by the CA again institutions through the relevant information with the CA server sends the signature of the issuing authority, thus we get the application server’s certificate, The certificate generates the signature of the corresponding certificate content, encrypts the signature with the private key of the CA authority to obtain the certificate fingerprint, and generates a relationship chain with the upper-layer certificate.

How do I verify the server certificate

So the client (browser) is how to verify the server certificate, first through the hierarchy to find the superior certificate, through the superior certificate public key to decrypt the server certificate fingerprint signature (SIGN1), and then through the signature algorithm to calculate the server certificate signature (SIGN2), by comparing sign1 and SIGN2, If it is equal, the certificate has not been tampered with or forged.

In the process

This prevents middlemen from tampering with or snooping on HTTP transmissions.