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

This article introduces the relevant knowledge of "what are the means to optimize HTTPS". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

From the HTTP protocol of naked data transmission to the HTTPS protocol of encrypted data transmission, it provides a "protective umbrella" for application data, which not only improves security, but also brings performance consumption.

Because HTTPS has one more TLS handshake process than HTTP protocol, the purpose is to negotiate or exchange symmetric encryption keys through asymmetric encryption handshakes, which can cost up to 2 RTT, and then the subsequent transmission of application data must be encrypted / decrypted using symmetric encryption keys.

For the sake of data security, we have to use the HTTPS protocol. So far, most of the URLs have been migrated from HTTP to HTTPS protocol, so the optimization for HTTPS is very important.

This time, HTTPS is optimized from multiple angles.

Analysis of performance loss

Since you want to optimize HTTPS, you need to know which steps will lead to performance consumption, and then prescribe the right medicine.

There are two links that generate performance consumption:

The first step, the handshake process of TLS protocol

The second link is the symmetrical encrypted message transmission after the handshake.

For the second step, the performance of the mainstream symmetric encryption algorithms AES and ChaCha20 is good, and some CPU manufacturers have optimized them at the hardware level, so the performance consumption of this link can be said to be very small.

In the first step, the TLS handshake process not only increases the network latency (up to 2 RTT), but also results in performance loss in some steps of the handshake process, such as:

For ECDHE key agreement algorithm, both client and server need to generate elliptic curve public and private keys temporarily during handshake.

When the client verifies the certificate, it accesses CA to obtain CRL or OCSP to verify whether the server's certificate has been revoked

Both parties calculate the Pre-Master, that is, the session key

To better understand which stage of the TLS protocol handshake these steps are, I have drawn this picture:

Hardware optimization

When playing games, if we can't beat each other, then there is one of the most effective and fastest ways to become stronger, that is, "recharge". If it still doesn't work, it means you don't have enough money.

The same is true for computers, software runs on physical hardware, the more powerful the hardware, the faster the software runs, so if you want to optimize HTTPS optimization, the most direct way is to spend money on hardware with more powerful performance parameters.

But money should also be spent in the right direction. HTTPS protocol is computationally intensive, not Imax O-intensive, so money can't be spent on network cards, hard drives and other places, but should be spent on CPU.

A good CPU can improve computing performance, because there are a large number of processes that need to calculate the key during the HTTPS connection, so this can speed up the TLS handshake process.

In addition, if you can, you should choose a CPU that supports the AES-NI feature, because this style of CPU optimizes the AES algorithm at the instruction level, thus speeding up the data encryption and decryption transmission process.

If your server is a Linux system, you can use the following command to see if CPU supports the AES-NI instruction set:

If our CPU supports the AES-NI feature, then the AES algorithm should be chosen for symmetric encryption. Otherwise, you can choose the ChaCha20 symmetric encryption algorithm, because the operation instructions of the ChaCha20 algorithm are a little more friendly to CPU than the AES algorithm.

Software optimization

If the company has a sufficient budget, you can consider buying a better CPU for the new server, but for the server that is already in use, the way of hardware optimization may not be suitable, so you have to optimize it from the software direction.

There are two kinds of optimization directions of software, one is software upgrade, the other is protocol optimization.

Let's start with the first software upgrade, which is upgrading the software in use to the latest version, because the latest version not only provides the latest features, but also optimizes the problem or performance of the previous software. For example:

Upgrade the Linux kernel from 2.x to 4.x

Upgrade OpenSSL from 1.0.1 to 1.1.1

...

For companies with hundreds of servers, software upgrades are as thorny as hardware upgrades for companies with hundreds of servers, because software upgrades take time and manpower, and there are certain risks. It may also affect normal online services.

Such being the case, we focus on protocol optimization, that is, under the existing links, through minor changes, to optimize.

Protocol optimization

The optimization of the protocol is to optimize the "key exchange process".

Optimization of key exchange algorithm

If TLS 1.2 uses the RSA key exchange algorithm, it requires a 4-way handshake, that is, it takes 2 RTT to transfer application data, and the RSA key exchange algorithm does not have forward security.

In a word, the TLS handshake process using RSA key exchange algorithm is not only slow, but also not secure.

Therefore, if possible, try to choose the ECDHE key exchange algorithm to replace the RSA algorithm, because the algorithm supports "False Start", which means "snatch". The client can send encrypted application data after the third handshake of the TLS protocol and before the fourth handshake, so as to reduce the round-trip message of the TLS handshake from 2 RTT to 1 RTT, and has high security and forward security.

ECDHE algorithm is based on elliptic curve, and the performance of different elliptic curve is different. We should try to choose x25519 curve, which is the fastest elliptic curve at present.

On Nginx, for example, you can use the ssl_ecdh_curve directive to configure the elliptic curve you want to use, putting the priority first:

For symmetric encryption algorithms, if the security requirements are not particularly high, you can choose AES_128_GCM, which is faster than AES_256_GCM because the length of the key is shorter.

For example, on Nginx, you can use the ssl_ciphers instruction to configure the asymmetric encryption algorithm and symmetric encryption algorithm you want to use, that is, the key suite, and put the fastest and most secure algorithm first:

TLS upgrade

Of course, if you can, directly upgrade TLS 1.2 to TLS 1.3 TLS 1.3 greatly simplifies the handshake steps, complete TLS handshake only 1 RTT, and the security is higher.

In TLS 1.2 handshake, 4-way handshake is generally required. First, the subsequent encryption algorithm is negotiated through the Client Hello (1st handshake) and Server Hello (2nd handshake) messages, then the public keys are exchanged (3rd and 4th handshakes), and then the final session key is calculated. The left side of the following figure shows the handshake process of TLS 1.2:

On the right side of the image above is the handshake process of TLS 1.3. you can see that TLS 1.3 combines the Hello and public key exchange messages into one message, thus reducing it to only 1 RTT to complete the TLS handshake.

How did it merge? Specifically, the client brings the supported elliptic curves and the corresponding public keys in the Client Hello message.

After receiving it, the server selects a parameter such as an elliptic curve, and then returns the message with the public key on this side of the server. After this 1 RTT, both parties already have the material to generate the session key, so the client calculates the session key and can encrypt the application data.

Moreover, TLS1.3 has lost weight on cipher suites. For key exchange algorithms, it abolishes RSA and DH algorithms that do not support forward security, and only supports ECDHE algorithms.

For symmetric encryption and signature algorithms, only the most secure cipher suites are supported. For example, only the following five cipher suites are supported in openssl:

TLS_AES_256_GCM_SHA384

TLS_CHACHA20_POLY1305_SHA256

TLS_AES_128_GCM_SHA256

TLS_AES_128_CCM_8_SHA256

TLS_AES_128_CCM_SHA256

The reason why TLS1.3 only supports so few cipher suites is that TLS1.2 supports a variety of ancient and insecure cipher suites, and middlemen can use demotion attacks to forge client-side Client Hello messages and replace client-supported cipher suites with insecure cipher suites, forcing the server to use this cipher suite for HTTPS connections to crack the ciphertext.

Certificate optimization

In order to verify the identity of the server, the server will send its own certificate to the client during the TSL handshake to prove that its identity is credible.

For certificate optimization, there are two directions:

One is certificate transmission.

One is certificate verification.

Certificate transmission optimization

To make the certificate easier to transfer, it must be to reduce the size of the certificate, which can save bandwidth and reduce the amount of computation on the client. Therefore, for the server's certificate, you should choose the elliptic curve (ECDSA) certificate instead of the RSA certificate, because under the same security strength, the ECC key length is much shorter than the RSA.

Certificate verification optimization

When the client verifies the certificate, it is a complex process, which will go through the certificate chain step by step. The verification process not only requires "decrypting the certificate with CA public key" and "verifying the integrity of the certificate with signature algorithm", but also in order to know whether the certificate has been revoked by CA, the client will sometimes visit CA and download CRL or OCSP data to confirm the validity of the certificate.

This access process is HTTP access, so it will generate a series of network communication overhead, such as DNS query, establishing connection, sending and receiving data and so on.

CRL

CRL is called Certificate revocation list (Certificate Revocation List). This list is updated periodically by CA. The contents of the list are all the serial numbers of certificates that have been revoked. If the server's certificate is in this list, the certificate is considered invalid and is not there, then the certificate is considered to be valid.

But there are two problems with CRL:

The first problem is that because the CRL list is maintained by CA and is updated regularly, if a certificate has just been revoked, the client will still trust the certificate before updating the CRL, resulting in poor real-time performance.

The second problem is that with the increase of certificate revocation, the list will become larger and larger, and the download speed will be slower. If the client has to traverse such a large list after downloading, it will cause the client to have a great delay in verifying the certificate, which in turn slows down the HTTPS connection.

OCSP

Therefore, OCSP, called online Certificate status Protocol (Online Certificate Status Protocol), is now used to query the validity of certificates. It works by sending a query request to CA and letting CA return the valid status of the certificate.

The client does not need to download a large list like CRL, but also needs to query from the list. At the same time, because it can query the validity of each certificate in real time, it solves the real-time problem of CRL.

OCSP needs to query CA, so it is also necessary to make a network request, and it also depends on the "face" of the CA server. If the network state is not good, or the CA server is busy, it will also cause the client to have a greater delay in verifying the certificate.

OCSP Stapling

So in order to solve this network overhead, OCSP Stapling appears. The principle is that the server periodically queries the CA for the certificate status, obtains a response result with a timestamp and signature, and caches it.

When a client initiates a connection request, the server sends the "response result" to the client during the TLS handshake. Because of the existence of the signature, the server cannot tamper with it, so the client can know whether the certificate has been revoked, so the client does not need to query.

Session multiplexing

The purpose of the TLS handshake is to negotiate the session key, that is, the symmetric encryption key, so if we cache the symmetric encryption key negotiated for the first time in the TLS handshake, then the next time we need to establish a HTTPS connection, we will directly "reuse" this key, which will reduce the performance loss of the TLS handshake.

This method is session multiplexing (TLS session resumption). There are two types of session multiplexing:

The first is called Session ID.

The second kind is called Session Ticket

Session ID

The principle of Session ID is that after the first TLS handshake connection between the client and the server, the session key is cached in memory and identified by a unique Session ID. Session ID and session key are equivalent to the relationship of key-value.

When the client connects again, the Session ID will be included in the hello message, and the server will look for it from memory after receiving it. If it is found, it will directly use the session key to restore the session state, skip the rest of the process, and use only one message round trip to establish secure communication. Of course, for the sake of security, session keys in memory expire periodically.

But it has two disadvantages:

The server must maintain the session key of each client, and as the number of clients increases, the memory pressure on the server will be greater.

At present, website service is generally provided by multiple servers through load balancing, and the client connection may not necessarily hit the server visited last time, so it is necessary to go through the complete TLS handshake process.

Session Ticket

In order to solve the problem of Session ID, there is Session Ticket, where the server no longer caches each client's session key, but leaves the caching work to the client, similar to HTTP's Cookie.

When the client establishes a connection with the server for the first time, the server encrypts the session key and sends it to the client as a Ticket and gives it to the client to cache the Ticket.

When the client connects to the server again, the client will send Ticket. After decryption, the server can obtain the last session key, and then verify the validity period. If there is no problem, you can resume the session and start encrypting the communication.

For clustered servers, make sure that each server encrypts the "session key" with the same key, so that when the client accesses any server with Ticket, the session can be resumed.

Neither Session ID nor Session Ticket has forward security, because once the encrypted "session key" is cracked or the server leaks the "session key", the previously hijacked communication ciphertext will be cracked.

At the same time, it is also difficult to deal with replay attacks. Here is a brief introduction to the working principle of replay attacks.

Suppose Alice wants to prove his identity to Bob. Bob requires Alice's password as proof of identity, and Alice should do her best to provide it (probably after conversion such as a hash function). At the same time, Eve eavesdropped on the conversation and kept the password (or hash).

After the exchange, Eve (posing as Alice) connects to the Bob. When asked to provide proof of identity, Eve sends the password (or hash) of the Alice read from the last session accepted by Bob, thereby granting Eve access.

The danger of the replay attack is that if the middleman intercepts the Session ID or Session Ticket and POST packets of a client, and the general POST request will change the data of the database, the middleman can use the intercepted message to send the message to the server continuously, which will cause the data of the database to be changed by the middleman without the customer's knowledge.

The way to avoid replay attacks is to set a reasonable expiration time for the session key.

Pre-shared Key

The previous Session ID and Session Ticket methods both require 1 RTT to resume the session.

On the other hand, TLS1.3 is even more powerful. For reconnecting TLS1.3, it only requires 0 RTT, which is similar to Ticket, except that when reconnecting, the client sends Ticket and HTTP requests to the server together, which is called Pre-shared Key.

Similarly, Pre-shared Key is in danger of replaying attacks.

As shown in the figure above, suppose that the middleman intercepts the POST request of the client using session reuse technology in some way. Usually, the POST request will change the data of the database, and then the middleman can send the intercepted message to the server. After receiving it, the server thinks it is legitimate, so the session is resumed and the data of the database is changed again, but the user is not aware of it at this time.

Therefore, in response to replay attacks, you can set a reasonable expiration time for session keys and use session reuse only for secure HTTP requests such as GET/HEAD.

Summary

For the direction of hardware optimization, because HTTPS is computing-intensive, you should choose CPU with more computing power, and it is best to choose CPU that supports AES-NI feature, which can optimize AES symmetric encryption algorithm at the hardware level and speed up the encryption and decryption of application data.

For the direction of software optimization, if possible, upgrade the software to a newer version, such as Linux kernel 2.x to 4.X and openssl 1.0.1 to 1.1.1, because the new version of the software will not only provide new features, but also fix the problems of the old version.

For the direction of protocol optimization:

The key exchange algorithm should choose the ECDHE algorithm instead of the RSA algorithm, because the ECDHE algorithm has forward security, and the client can send encrypted application data after the third handshake, saving 1 RTT.

Upgrade TSL1.2 to TSL1.3 because TSL1.3 's handshake requires only 1 RTT and is more secure.

For the direction of certificate optimization:

The server should choose ECDSA certificate instead of RSA certificate, because at the same security level, the key length of ECC is much shorter than that of RSA, which can improve the efficiency of certificate transmission.

The server should enable the OCSP Stapling function, and the server should obtain the OCSP response in advance and cache the response result, so that when TLS shakes hands, there is no need to access the CA server, which reduces the overhead of network communication and improves the efficiency of certificate verification.

When reconnecting to the HTTPS, we can use some techniques to let the client and server use the session key used in the last HTTPS connection to resume the session directly without having to go back to the full TLS handshake process.

The common session reuse technologies are Session ID and Session Ticket, which use the session reuse technology. When you reconnect the HTTPS, it only takes 1 RTT to resume the session. With TLS1.3 using Pre-shared Key session reuse, it only takes 0 RTT to resume the session.

Although these session reuse technologies are easy to use, they have certain security risks. They not only do not have forward security, but also have the risk of replay attacks, so a reasonable expiration time should be set for the session key.

This is the end of the content of "what are the means to optimize HTTPS". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.