HTTPS encryption process and TLS certificate verification
foreword
As we all know, Apple announced at WWDC 2016 regulations that apps need to be mandatory HTTPS
. This is also good news. Although developers may need to adapt HTTPS
, our application can be regarded as a safe protective cover. This article is HTTPS
a record of the author's learning process.
HTTPS encryption process
Recently, I have re-understood Xiahe: First of HTTP
all HTTPS
, both are network transmission protocols; HTTPS
during 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 HTTPS
is HTTP
an 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
The client initiates a
HTTPS
request
This is nothing to say, that is, the user enters a URL in the browserHTTPS
, and then connects to port 443 of the server.Server Configuration The server that
adoptsHTTPS
the 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.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.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.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.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.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.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, HTTPS
the entire encryption process is almost completed, but there are still some concepts in this process that are still unclear, such as SSL
what TLS
is 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 TLS
it, you may not be familiar with it, but when you talk about SSL
it, it may sound familiar to you. In fact, it TLS
was SSL
developed from the development, but SSL
it was changed after the development to version 3.0 TLS
.
TLS
Mainly 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
TLS
The protocol is based on TCP
the protocol. The first blue round trip in the figure is TCP
the handshake process, and the next two orange round trips are what we can call TLS
the handshake. The handshake process is as follows:
client1
:TLS
version number + list of supported cipher suites + desiredTLS
optionsServer1
: select a client's cipher suite + own public key + own certificate + theTLS
option you want to use + (requires client certificate);Client2
: (own certificate) + use the server public key and the negotiated encryption suite to encrypt a symmetric key (a random value generated by yourself);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
The client obtains the site certificate and the public key of the site;
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;
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;
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;
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;
Using the public key in the certificate, the client continues
TLS
the 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.
lipitor 80mg ca & lt;a href="https://lipiws.top/"& gt;atorvastatin 80mg drug& lt;/a& gt; order atorvastatin 10mg pill
Dqismg
2024-03-07