• notice
  • Congratulations on the launch of the Sought Tech site

HTTPS encryption process and TLS certificate verification

foreword

As we all know, Apple announced at WWDC 2016 regulations that apps need to be mandatory HTTPSThis is also good news. Although developers may need to adapt HTTPS, our application can be regarded as a safe protective cover. This article is HTTPSa record of the author's learning process.

HTTPS encryption process

Recently, I have re-understood Xiahe: First of HTTPall HTTPS, both are network transmission protocols; HTTPSduring the transmission process, data security can be protected by encryption, so as to prevent sensitive user information from being obtained by third parties. It can be said that it HTTPSis HTTPan upgraded version and a safe version. Let's take a brief look at the encryption process of HTTPS, first look at the figure below.

 

HTTPS encryption process

  1. The client initiates a HTTPSrequest
    This is nothing to say, that is, the user enters a URL in the browser HTTPS, and then connects to port 443 of the server.

  2. Server Configuration The server that
    adopts HTTPSthe protocol must have a set of digital certificates, which can be made by yourself or applied to the organization. The difference is that the certificate issued by yourself needs to be verified by the client before you can continue to access, while the certificate applied by a trusted company will not pop up a prompt page. This certificate is actually a pair of public key and private key. If you don’t understand the public key, you can imagine it as a key and a lock, but you are the only one in the world who has this key. You can give the lock to others, and others can use this lock to lock important things. Then send it to you, because only you have the key, so only you can see what is locked by this lock.

  3. Sending a certificate
    This certificate is actually a public key, but contains a lot of information, such as the certificate authority, expiration time, and so on.

  4. The client
    's part of the work of parsing the certificate is done by the client's SSL/TLS. First, it will verify whether the public key is valid, such as the issuing authority, expiration time, etc. If an abnormality is found, a warning box will pop up, indicating that the certificate exists. question. If there is no problem with the certificate, then a random value is generated . This random value is then encrypted with the certificate (that is, the public key). As mentioned above, lock the random value with a lock, so that unless there is a key, you cannot see the locked content.

  5. Transmission of encrypted information
    This part of the transmission is the random value encrypted with the certificate, the purpose is to let the server get this random value, and then the communication between the client and the server can be encrypted and decrypted through this random value.

  6. The server decrypts the information
    . After the server decrypts with the private key, it obtains the random value sent by the client, and then encrypts the content symmetrically through the random value, and mixes the information and private key together through some algorithm, so that unless the private key is known. Otherwise, the content cannot be obtained, but both the client and the server know the private key, so as long as the encryption algorithm is strong enough and the private key is complex enough, the data is safe enough.

  7. Transmission of encrypted information
    This part of the information is the information encrypted by the private key on the server side, which can be decrypted and restored by random values on the client side.

  8. Client decryption information
    The client decrypts the information sent by the server with the previously produced private key, and thus obtains the decrypted content. In the whole process, even if the third party monitors the data, there is nothing they can do.

At this point, HTTPSthe entire encryption process is almost completed, but there are still some concepts in this process that are still unclear, such as SSLwhat TLSis it, what is it, and how do they verify whether our certificate is valid? Their verification What is the strategy? Don't worry, we'll discuss it below TLS.

TLS

When you first hear TLSit, you may not be familiar with it, but when you talk about SSLit, it may sound familiar to you. In fact, it TLSwas SSLdeveloped from the development, but SSLit was changed after the development to version 3.0 TLS.

TLSMainly provide three basic services

  • encryption

  • Identity verification, also known as certificate verification~

  • message integrity check

The third one is a checksum mechanism commonly used in network protocols. I will not list it first.

encryption

Let's look again at the encryption mechanism between the client and the server:

 

TLS handshake

TLSThe protocol is based on TCPthe protocol. The first blue round trip in the figure is TCPthe handshake process, and the next two orange round trips are what we can call TLSthe handshake. The handshake process is as follows:

  1. client1TLSversion number + list of supported cipher suites + desired TLSoptions

  2. Server1: select a client's cipher suite + own public key + own certificate + the TLSoption you want to use + (requires client certificate);

  3. Client2: (own certificate) + use the server public key and the negotiated encryption suite to encrypt a symmetric key (a random value generated by yourself);

  4. Server2: After decrypting the symmetric key (random value) using the private key, send an encrypted Finish message to indicate that the handshake is completed

It may be mentioned here what is symmetric encryption and asymmetric encryption:
general symmetric encryption is like this:

encrypt(plaintext, key) = ciphertext
decrypt(ciphertext, key) = plaintext

That is to say, the same key is used for encryption and decryption. Asymmetric encryption is like this:

encrypt(plaintext, public key) = ciphertext
decrypt(ciphertext, private key) = plaintext

Encryption and decryption require different keys.

After these handshakes are successful, the encryption algorithm and the required key for the communication between the client and the server are determined, and then the interaction between the two parties can be encrypted using the symmetric encryption algorithm.

Certificate Mechanism/Certificate Verification

In TLS, we need certificates to guarantee that the server you are accessing is real and trusted.
Looking at this picture, let's discuss the verification process of the certificate.

 

certificate chain

  1. The client obtains the site certificate and the public key of the site;

  2. To verify that the site is trusted, its public key can be used, so the client finds the information of the issuer of its site certificate;

  3. The issuer of the site certificate verifies that the server site is trusted, but the client still does not know whether the issuer is trusted;

  4. Going back further, I found the source certificate issuer who certified the intermediate certificate provider. Since there are very few certificate issuers at the source, our browsers have known each other before, so we can consider the root certificate issuer to be trusted;

  5. All the way back, the certificate issuer is credible, then all the sites it issues are also credible, and it is finally determined that the server we visit is credible;

  6. Using the public key in the certificate, the client continues TLSthe completed handshake process.

So, how does the client verify the validity of a certain certificate, or what is the verification strategy?

Certificate issuers generally provide two ways to verify the validity of the certificate: CRL and OCSP .

CRL

CRL(Certificate Revocation List)The certificate revocation list . The certificate issuer will provide a list of expired certificates for the browser to use to verify the certificate. Of course, this list is extremely long, and it is impossible for browsers to download TLS every time. Therefore, the common practice is that the browser will cache this list and periodically update it in the background. In this way, although there is a time interval in the background update, and the certificate invalidation is not real-time, it is generally OK.

OCSP

OCSP(Online Certificate StatusProtocol)The Online Certificate Status Protocol . In addition to offline files, certificate issuers also provide a real-time query interface to query whether a specific certificate is currently valid. The problem with real-time queries is that the browser needs to wait for the end of the query to continue the TLS handshake, and the delay will be greater.

The above are the two judgment methods provided by the site from the perspective of the certificate issuer. In fact, which method will the browser choose to judge, each browser will have its own implementation. The following is the certificate information for viewing the GitHub website through Chrome:

 

Certificate example

It's almost here, if there is anything wrong, please leave a message and point out, let's learn and progress together!

The author is not talented, and I still do not understand in some places. If there are any inaccuracies, please be patient and point out.


Tags

Technical otaku

Sought technology together

Related Topic

1 Comments

author

lipitor 80mg ca & lt;a href="https://lipiws.top/"& gt;atorvastatin 80mg drug& lt;/a& gt; order atorvastatin 10mg pill

Dqismg

2024-03-07

Leave a Reply

+