HTTPS,

At present, most large websites have all switched to HTTPS service, so it is necessary to understand the principle of HTTPS, how to ensure information security. Here I hope you have some understanding of the following nouns:

  • A digital certificate is an identity identifier (mainly user identity information and public key) in Internet communication. It is generally issued by a CA authentication center or a third-party authority. Digital certificates usually include: CA signature, certificate owner’s public key, CA signature algorithm, fingerprint and fingerprint algorithm, certificate unique number, version, validity period, etc.
  • Digital signature and signature algorithm

    A summary of the informationThe hash algorithm/The algorithm/Fingerprint algorithmComputational informationAbstract/Hash valueEncrypted using the signature algorithm, the ciphertext is called a digital signature
  • Fingerprint, Fingerprint algorithm/Abstract Algorithm

    Using messagesHash algorithm/digest algorithmTo obtain a fixed length of information through one-way processingThe/hash value.
  • Asymmetric encryption can use public key and private key decomposition to encrypt and decrypt the corresponding algorithm, that is, encryption and decryption using a different set of secret keys.
  • Symmetric encryption An algorithm that uses the same secret key for encryption and decryption
  • Public key and private key A pair of secret keys used for asymmetric encryption and decryption.

HTTPS service deployment process and working principles

The best way to understand the PRINCIPLE of HTTPS is to go through the process. The theoretical process and principle are explained as follows:

  1. The certificate application
  2. Certificate trust
  3. The cipher text communication

Obtaining certificates

One of the keys of HTTPS is SSL certificates. In order to ensure the security and validity of certificates, cooperation between various committees/vendors, through similar roundtable to form several authoritative certification bodies [the top certification body can have several affiliated secondary, tertiary… certification bodies]. You need to submit a CSR (Certificate Signing Request) to the CA. The process is as follows:

  1. Certificate applicants (usually companies, individual developers, etc.) need to use encryption algorithms (mostly RSA algorithms) to generate private keys, which are stored on the server and not made available to anyone.

  2. Using the private key to generate the Certificate Signing Request (CSR), the CSR needs to provide some information about the applicant (domain name, owner, etc.) and send it to the CA to Request their signature. After their signature, it can become a trusted Certificate.

  3. The CA authenticates the applicant. After the authentication succeeds, the CA adds some information (certificate authority, validity period, fingerprint /hash algorithm, and signature algorithm) to the certificate to form a new certificate. The CA also uses its own private key to sign other certificates.

  4. To sign the new certificate, do as follows:

    • The hash value of the new certificate is calculated based on the fingerprint /hash algorithm

    • The CA private key is used to encrypt the hash value calculated according to the signature algorithm. The ciphertext obtained is the digital signature.

    • Put the digital signature at the end of the certificate [signature completed], get the complete certificate, and return to the applicant;

    • Applicants obtain signature certificates to guarantee their ownHTTPSThe service is trusted.

      Therefore, the final certificate basically includes but is not limited to the following contents:

      • Validity of certificate
      • The public key
      • Certificate Owner (Subject)
      • The algorithm used for the signature
      • Fingerprint and fingerprint algorithm
      • Version Number: indicates the Version Number.
      • Serial Number
      • Issuing authority
      • A digital signature

      Client identification certificate

      After application to a trusted certificate, how do clients know this certificate is trustworthy, different browsers and system implementation is not the same, the same, but the basic way is prepared well in the system or browser authority CA institution information [public key, and all kinds of commonly used hash, signature and encryption algorithm]. The specific process is as follows:

      1. When a browser accesses an HTTPS service, it is equipped with a series of Cipher Suite (Cipher Suite) supported by the browser. [C1,C2,C3,… Send to the server [Algorithm suite includes asymmetric algorithm, symmetric algorithm and Hash algorithm];

      2. After receiving all ciphers from the browser, the server compares them with the ciphers supported by the server. If the server finds the ciphers supported by both sides (the algorithm with the highest priority supported by both sides), the server notifies the browser and returns its certificate.

      3. The browser confirms the encryption algorithm for subsequent ciphertext communication with the server and authenticates the certificate.

      4. Use the public key of a secondary or tertiary authority in the certificate (prepared in advance by the system or browser) to decrypt the ciphertext encrypted by the private key of an authentication authority to obtain the hash value.

      5. Using the certificateHash/digest algorithmThe hash value of certificate information (excluding certificate signature information [server public key, validity period, etc.]) is calculated and compared with the decrypted hash value in 4. If the hash value is the same, the certificate is trusted. [Through digital signature to ensure that the contents of the certificate have not been tampered with].

        HTTPS encrypted communication process

        After the above process [certificate trust, asymmetric algorithm required in client-server handshake, hash algorithm for handshake information verification, symmetric encryption of body transmission], the specific communication process is as follows:

        1. The client trusts the certificate of the server and confirms with the server the encryption algorithms of both sides (asymmetric algorithm required in handshake, hash algorithm for handshake information verification, symmetric encryption for text transmission).

        2. The client generates random numbers and encrypts the public key in the certificate according to the agreed asymmetric encryption algorithm to obtain the encrypted secret key of random numbers. Meanwhile, all previous communication information (secret key algorithm suite, certificate and other communication content) is obtained according to the agreed hash/ digest algorithm. And use random number and negotiated symmetric encryption algorithm for signature encryption, send the random number secret key and encryption signature to the server.

        3. After receiving the secret key and encryption signature, the server uses the private key to decrypt the random number according to the agreed asymmetric decryption algorithm to obtain the random number. At the same time, the server uses the random number according to the agreed symmetric decryption algorithm to obtain the hash value to be verified. Obtain the hash value of the previous communication message body (including all communication contents such as the secret key algorithm suite and certificate) according to the agreed hash/ digest algorithm, and compare it with the hash value obtained by decryption to verify whether the encryption is successful.

        4. After success, the server obtains hash value of all previous communication information (secret key algorithm suite, certificate and other communication contents) according to the agreed hash/ digest algorithm, uses random number and negotiated symmetric encryption algorithm for signature encryption, and sends the secret key of random number to the client.

        5. Clients use random Numbers in accordance with the contract of symmetric decryption decryption algorithm, obtaining authentication hash value, the communication message body before the secret key algorithm suites, all communication content such as certificate 】 the hash in accordance with the contract/algorithm to obtain the hash value, and just decryption access to verify the hash value of contrast, encryption authentication success,

        6. If successful, the whole link process is completed, and then the cipher text communication will be carried out using random numbers and the conventional symmetric encryption algorithm. [If any of the above steps fail, the whole handshake process will be ended, resulting in the establishment of a secure connection failure].

          There are a lot of details;

          Integrated solutions

          The whole process here is very detailed, but it is still very clear that the principle and process of HTTPS; Here’s a look at some of the confusion:

          1. The role of CA certification? Can be regarded as the global limited authority authentication, after its signature certificate can be regarded as trusted, so their private key must be guaranteed not to be leaked, if leaked need to be revoked in a timely manner.
          2. Why does the signature need to encrypt the hash value, which is a one-way and irreversible operation? Although the hash value is unidirectional, the algorithm and content for computing the hash are public. If no encryption is performed, other people can modify the contents of the certificate and re-compute the hash based on the hash algorithm, resulting in security vulnerabilities. Therefore, using encrypted ciphertext is secure.
          3. Why do we have random numbers, and why do we generate them on the client side? Random number is the key key for ciphertext encryption and decryption. Only the person who obtains this random number can see the content of communication and ensure the security of communication. The session is generated by the client because the initiator of the session is the client. To ensure the uniqueness of the client and prevent the session content between the server and the client from being tampered, if the session is generated by the server, a third party can decrypt the random number encrypted by the server through the public key, which is unsafe.
          4. After certificate verification is complete, why do the client and the server need to send signature information to each other? After the certificate authentication is complete, a random number needs to be transmitted, and the public key and private key are used for asymmetric encryption and decryption. After the content message is generated, the symmetric encryption and decryption using the random number is verified to ensure the correctness of data obtained by both parties.

          Openssl generates a certificate

          In most development and debugging processes, when we need to debug HTTPS pages locally, we need to have a local certificate, and OpenSSL is such an integration tool; Use OpenSSL to debug HTTPS requests locally.

          1. opensslIntroduction to the
          2. Self-signed certificate
          3. Local private CA certificate

          The summary of the openssl

          OpenSSL is an open source project consisting of the following three components:

          1. Openssl: multi-purpose command-line tool
          2. Libcrypto: library of cryptographic algorithms
          3. Libssl: encryption module application library that implements SSL and TLS

          Openssl supports key certificate management, symmetric encryption, and asymmetric encryption.

          Self-signed certificate

          In order to be able to get online HTTPS requests to local, need we have HTTPS local service, so the certificate is inevitable, but in general, we are not using the online certificate, because local need local service enabled, if the certificate to use online, then the local service requires online privacy information such as the private key, This can easily lead to private key disclosure, so it is not secure, so we need to generate a local certificate;

          As mentioned above, a certificate needs to be authenticated and signed by a CA organization, so do we need to apply for certification for the certificate used in our local test? But negative, because this is only our local use, so we only need to have a certificate, and manually add trust on the line, then self-signed certificate is a good solution to this problem.

          Self-signed certificates: The core of self-signed certificates is to sign their own applications [this is how CA root certificates are generated]. Use your own private key to apply for a CSR for the self-generated certificate and sign the certificate.

          Through the self-signed certificate, we obtain the certificate required by HTTPS service. According to different local environments, we need to trust the certificate, so that our local HTTPS service can be correctly identified by the browser. The whole process is as follows:

          1. To generate the secret key

            openssl genrsa -des3 -out cwj.key 2048
Copy the code

            Use the above command to generate a private key that we need locally, and then use the private key to generate a certificate to apply for a CSR and use the private key to self-sign the certificate

          2. Generate a certificate to apply for a CSR

            openssl req -new -key cwj.key -out cwj.csr
Copy the code

            You need to fill in a series of information, including location, unit, domain name, email, etc. The public key will be automatically generated to match the server private key. The public key is included in the CSR.

          3. Use the private key to complete the self-signing and generate a complete certificate

            openssl x509 -req -sha256 -days 3650 -in cwj.csr -signkey cwj.key -out cwj.crt
Copy the code

            Use the previously produced secret key to apply for CSR for trust signature and get the complete certificate;

          This does meet some requirements, only need to use the certificate and the private key to start the HTTPS service, and at the same time, the local trust of the certificate is complete, which has the following advantages:

          1. Local self-signature, CA root certificate is not required.
          2. Process is simple

          But there are some drawbacks:

          1. The certificate cannot be revoked and the private key needs to be saved, but it is harmless for local debugging only;
          2. Multiple domain names require multiple certificates. Multiple certificates need to be generated based on the domain name. The customer service needs to trust these certificates. 【 butopensslYou can also generate multiple domain name certificates. One certificate can be used by multiple domain namesopenssl.cnfConfiguration file to generate 】

          So there are other ways: In order to simulate the complete is HTTPS service, we can generate a similar in local CA root, through the CA private key to all the other local certificate to sign, only trust the local CA root, so his signature certificate can be trusted, that is the evolution of the below mentioned methods local private CA root certificate.

          Local private CA root Certificate Indicates the fake CA root certificate

          Overall process of this approach is that the local generates a CA certificate, analogous to the presence of CA institution, tentatively called pseudo CA root by pseudo 】 the private key of CA root certificate to all the other local certificate to sign, we trust in the local CA root, then through pseudo CA root certificate will be signed by trust. Avoid the complex behavior of generating multiple self-signed certificates and trusting each domain name separately.

          1. A pseudo CA root certificate is generated and trust is added

            openssl genrsa -des3 -out ca.key 2048
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -sha256 -days 3650 -in ca.csr -signkey ca.key -out ca.crt
Copy the code

            As you can see, the CA root certificate is an example of a self-signed certificate.

          2. Local single domain certificate key, apply for CSR

            openssl genrsa -des3 -out cwj.key 2048
openssl req -new -key cwj.key -out cwj.csr
Copy the code

            Generate a certificate request;

          3. The private key of the fake CA root certificate signs other CSR applications

            openssl x509 -req -sha256 -days 3650 -in cwj.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out cwj.crt
Copy the code

          Openssl; This solves the certificate problem, depending on which scheme the user uses to generate the certificate.

          The procedure varies depending on the operating system. For a MAC, you need to trust a certificate in a key string. For Windows, you need to import a certificate.

          Nginx deploys HTTPS practices

          There are many ways to start HTTPS services locally. Here’s a look at nginx. Nginx official website HTTPS module, the main use is private key and certificate; The certificate is generated using a different method and the server private key as mentioned earlier (local CA root certificate also requires local trust).

          server { listen 443 ssl; server_name cwj.cc; ssl_certificate /cwjhttps/cwj.crt; ssl_certificate_key /cwjhttps/cwj.key; ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; ssl_ciphers HIGH:! aNULL:! MD5; ssl_prefer_server_ciphers on; location / { root /cwjhttps; index home.html index.htm test.html; }}Copy the code

          In fact, this approach inchromeHigher versions are still considered unsafe; At the back of theopenssl“, or seeDetails on the self-signed certificate processandResolve chrome does not trust self-signed certificates,The digest /hash algorithm is not considered secure

          SSL Certificate signature The OpenSSL certificate trusts HTTPS

          Read update 9.1k on 2018-05-21