Shulou(Shulou.com)06/01 Report--

How to understand the working principle of HTTPS, in view of this problem, this article introduces the corresponding analysis and solution in detail, hoping to help more partners who want to solve this problem to find a more simple and feasible method.

When you open a browser and visit a website, if there is a small lock next to the URL, it means that the URL you visit is secure, and vice versa.

When we do not see the small icon of the small lock, we need to be vigilant not to enter personal important information at will. All banking and payment-related websites use HTTPS at 100%.

Why do I need HTTPS?

Why do we need HTTPS? There are three main reasons:

① Privacy Protection (Privacy): all information is encrypted and cannot be eavesdropped by third parties. If you use HTTP plaintext to transmit data, it is likely to be hijacked by a third party, then the entered passwords or other personal data will be exposed to others, and the consequences can be imagined.

② data integrity (Integraty): once a third party tampers with the data, the receiver will know that the data has been tampered with, thus ensuring that the data will not be tampered with during transmission-the integrity of the data.

③ authentication (Identification): it is impossible for a third party to participate in communication by pretending to be an identity, because the server is equipped with a security certificate issued by a certificate authority (Certificate Authority, referred to as CA), which can confirm the identity of the server and prevent a third party from impersonating an identity.

In a few cases, communication requires the client to provide a certificate, such as the banking system, which requires the user to insert the USB provided by the bank when logging in, that is, the client is required to provide a certificate to verify the customer's identity information.

What is HTTPS? what is SSL/TLS?

HTTP protocol (HyperText Transfer Protocol, Hypertext transfer Protocol) is the most familiar protocol. It is a protocol for transmitting hypermedia documents. It is located in the application layer of the OSI network protocol model.

But it is a plaintext transmission protocol, which is very insecure and easy to tamper with and steal data.

SSL (Secure Socket Layer)-- A secure transport protocol designed by Netscape for Web.

It is located between the TCP transport layer protocol and the application layer protocol. (it is not classified in the OSI network protocol model and is considered to be a sublayer of the application layer.)

As we all know, Netscape finally lost the competition with Microsoft in the 1990s, and then Netscape transferred the management of the SSL agreement to IETF (Internet Engineering Task Force, www.ietf.org).

So IETF standardized SSL and renamed it TLS (Transport Layer Security). In 1999, TLS 1.0 was born (actually SSL 3.1).

HTTPS (HyperText Transfer Protocol Secure) is based on the SSL/TLS protocol, information communication is encrypted through SSL/TLS, and the last S is the abbreviation of Secure, which stands for security, HTTPS = HTTP+SSL/TLS.

The history of SSL/TLS development

The history of SSL/TLS is shown in the figure above:

In fact, modern browsers basically do not use SSL, using TLS,SSL 3.0 died in 2015, and major browsers no longer support it.

But because the term SSL has been around for too long, it is still widely used in many places, but it should be clear that it actually refers to TLS.

A survey shows that the vast majority of browsers (> 99.5%) now use TLS 1.2 or TLS 1.3. Less than 1% of browsers still use TLS 1.0 or TLS 1.1.

TLS 1.2is still the mainstream protocol (this article was written in early 2020s), and it is believed that TLS 1.3will gradually become the mainstream protocol in the future.

Many browsers will start not to support TLS 1.0 and 1.1:

Google will not recommend TLS 1.0 and 1.1 in Chrome 72, while Chrome 81 will not support it at all.

Mozilla's Firefox, Microsoft's Edge and IE, and Apple's Safari will gradually remove support for TLS 1.0 and 1.1 in 2020, respectively.

Then some websites that are still using TLS 1.0 and 1.1 will be forced to upgrade to TLS 1.2 or TLS 1.3.

To turn off browser support for TLS 1.0 and 1.1, you can modify it in the Internet option:

How SSL/TLS works

We need to understand how SSL/TLS works, and we need to master encryption algorithms.

There are two encryption algorithms:

Symmetrical encryption

Asymmetric encryption

Symmetric encryption: both sides of the communication are encrypted using the same key. The characteristic is that the encryption speed is fast, but the disadvantage is that the key needs to be protected. If the key is compromised, then the encryption will be cracked by others. The common symmetric encryption is AES,DES algorithm.

Asymmetric encryption: it needs to generate two keys: the public key (Public Key) and the private key (Private Key).

As the name implies, the public key is public and can be obtained by anyone, while the private key is in private custody. I believe most programmers are already familiar with this algorithm.

When we submit the code to Github, we can use SSH key: generate the private key and public key locally, put the private key in the local .ssh directory, and the public key on the Github website.

In this way, every time you submit the code, you don't have to bother to enter the user name and password. Github will identify us according to the public key stored on the website. The public key is responsible for encryption and the private key is responsible for decrypting; or the private key is responsible for encryption and the public key is responsible for decrypting.

This encryption algorithm is more secure, but the amount of computation is much larger than symmetric encryption, and encryption and decryption are very slow.

A common asymmetric algorithm is RSA. SSL/TLS makes use of the characteristics of symmetric encryption and asymmetric encryption.

Let's take a look at the whole handshake process of SSL/TLS, and then we'll take a step-by-step interpretation of what has been done at each step.

① when the TCP establishes a connection, the first step of the TLS handshake is initiated by the client and sends the ClientHello message to the server.

The ClientHello message contains:

SSL/TLS versions supported by the client

Client supported cipher suite (Cipher Suites)

Session Idsession id (if there is a value, the server will reuse the corresponding handshake information to avoid repeated handshakes in a short period of time)

Random number client-random

Extended reading:

Encryption suite name such as: "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA256", such a long name looks a little dizzy, do not be afraid, in fact, its naming is very standard, the format is very fixed. The basic form is "key exchange algorithm-service authentication algorithm-symmetric encryption algorithm-handshake check algorithm".

In the process of handshake, the certificate signature uses the RSA algorithm. If the certificate is verified correctly, the ECDHE algorithm is used for key exchange. The communication after the handshake uses AES256's symmetric algorithm grouping mode is GCM.

To verify the validity of certificate signature, SHA256 is used to verify the hash algorithm. The usefulness of the related algorithms will be explained in detail later.

The ② then receives the ClientHello on the server, selects the version and suite supported by the server, and sends the ServerHello message:

The highest SSL/TLS version that the server can support

Cipher suite selected by the server

Random number server-random

Session Idsession id (used to reuse the current handshake information next time to avoid repeating the handshake in a short period of time.)

The server then sends the server's security certificate (including the public key). If the client is also required to provide a certificate, a client certificate request (Client Certificate Request) is also issued, and only a few financial institutions require the client to also provide a client certificate.

After that, the client sends a Server Hello Done message indicating that the Hello phase is complete.

When the ③ client receives the ServerHello, it validates the received certificate.

Let's take a look at why it is possible to confirm the identity of a website through a certificate issued by CA (Certificate Authority).

When we install the operating system or browser, we install a list of trusted CA (root certificate CA includes GlobalSign, GeoTrust, Verisign, etc.).

The root CA such as GlobalSign is in our trusted CA list, and your browser or operating system contains the public key of GlobalSign.

Let's first take a look at Google's certificate. When you visit Google, Google will issue you its certificate. The certificate contains the signature of the authority and the public key of the server.

The browser first uses the hash function to hash the summary of the plaintext information to get a hash value (using the signature hash algorithm SHA256 in the certificate), and then decrypts the signature of the root certificate with the public key of the root CA to get another hash value (the algorithm used is the RSA asymmetric algorithm).

If two hash values are equal, the certificate has not been tampered with. Of course, you also need to verify whether the server name in the certificate is legal and whether the certificate has expired.

This protects against man-in-the-middle attacks, because if a middleman modifies the contents of the certificate (such as replacing the public key in the certificate with its own public key), it will get different hash values, resulting in a mismatch between the two hash values, resulting in authentication failure.

If you want to bypass this mechanism, the middleman must also replace the signature so that the signature matches. To do this, you need to crack the key of the root certificate (which is impossible, and the middleman is bound to fail).

The following screen appears in the browser to tell you that you are being attacked by a man in the middle because the certificate has been tampered with:

It must have occurred to you that if you have developed a system that is still in the testing stage and have not formally applied for a certificate, you can sign a certificate for the server and import it into the client's CA trust list.

The trust chain mechanism is shown below:

You can see that the certificate path is:

GlobalSign Root CA-R2 → GTS CA 1O1 → * .google.com

Because our browser trusts GlobalSign Root CA, according to the trust chain mechanism, you should not only trust the certificate issued by the root CA, but also trust the certificate issued by the sub-CA that it signed, and also trust the certificate of the sub-CA signed by the sub-CA.

And we pass a level of verification, if the root certificate to the lowest certificate has not been tampered with, we believe that the lowest server certificate is legitimate. So in this mechanism, you need to trust the root certificate authority unconditionally.

If verified, the client generates a random number pre-master for use in the key exchange process.

④ key exchange process: the client gets the server's public key from the server's certificate in step 3, and uses this public key to encrypt (the algorithm is the key exchange algorithm in the encryption suite, such as the ECDHE algorithm) to generate ciphertext and send it to the server.

The ⑤ client calculates the symmetric key master secret together with server-random+client-random+pre-master.

After receiving the information of step 4, the ⑥ server decrypts the ciphertext with the server's private key to get the key pre-master.

Because only the server has the private key, it can decrypt the encrypted information sent by the client to get the pre-master, which ensures that only the server and the client know the pre-master.

The server side can also calculate the symmetric key master secret together with server-random+client-random+pre-master.

Now that both the client and server have a key master secret, you can use it for encryption and decryption.

Why can't only one pre-master be used as the symmetric key for later encryption?

Although only the server has a private key and can decrypt the pre-master, it is not secure to use it as a master secret alone, in case the client's pre-master is not a random number.

Add the other two random numbers client-random and server-random (and these two random numbers are related to time) to ensure that the final generated master secret must be random.

The ⑦ client encrypts a handshake message to the server with master secret.

The ⑧ server also sends back a message completed with a handshake encrypted with master secret.

⑨ when both parties receive the handshake message sent by the other and successfully decrypt it, you can happily start data encryption and decryption with master secret.

To sum up, the whole handshake process is mainly through a series of steps to exchange master secret through asymmetric encryption algorithms, which usually takes hundreds of milliseconds, but it is after this drastic operation that only the server and client know the master secret.

After that, the communication uses an efficient symmetric algorithm to encrypt and decrypt all the information, although encryption and decryption also take time and traffic, but the information can not be tampered with and cracked by others, which is worth the loss.

The answer to the question about how to understand the working principle of HTTPS is shared here. I hope the above content can be of some help to you. If you still have a lot of doubts to be solved, you can follow the industry information channel to learn more about it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.