ByteDance 2: How many methods do you know to optimize HTTPS?

The conversion from the HTTP protocol for naked data transmission to the HTTPS protocol for encrypted data transmission provides a "protection umbrella" for application data, which improves security while also incurring performance consumption.

Because HTTPS has an additional TLS protocol handshake process compared to HTTP protocol, the purpose is to negotiate or exchange symmetric encryption keys through asymmetric encryption handshake. This process can take up to 2 RTTs, and then the subsequent transmitted application data must be encrypted/decrypted using the symmetric encryption key.

[[378270]]

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

This time, we will optimize HTTPS from multiple angles.

Analyze performance loss Since we want to optimize HTTPS, we need to understand which steps will cause performance loss and then prescribe the right remedy.

There are two links that generate performance consumption:

• The first step is the TLS protocol handshake process;
• The second step is the transmission of symmetrically encrypted messages after the handshake.

For the second link, the current mainstream symmetric encryption algorithms AES and ChaCha20 have good performance, and some CPU manufacturers have also made hardware-level optimizations for them, so the performance consumption of this link can be said to be very small.

In the first link, the TLS protocol handshake process not only increases network latency (can take up to 2 RTTs), but also some steps in the handshake process will also cause performance loss, such as:

• For the ECDHE key negotiation algorithm, both the client and the server need to temporarily generate elliptic curve public and private keys during the handshake process;
• When the client verifies the certificate, it accesses the CA to obtain the CRL or OCSP in order to verify whether the server's certificate has been revoked;
• Both parties calculate the Pre-Master, which is the session key.

To make it clearer to everyone where these steps are in the TLS protocol handshake, I drew this picture:

Hardware Optimization

When playing games, if we can't defeat the opponent no matter what, then there is a most effective and fastest way to become stronger, which is to "recharge money". If it still doesn't work, it means that the money you recharged is not enough.

[[378271]]

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, the most direct way is to spend money to buy hardware with better performance parameters.

But money should be spent in the right place. The HTTPS protocol is compute-intensive, not I/O-intensive, so money should not be spent on network cards, hard drives, etc., but should be spent on the CPU.

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

In addition, if possible, you should choose a CPU that supports the AES-NI feature, because this type of CPU can optimize 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 check whether the CPU supports the AES-NI instruction set:

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

Software Optimization

If the company has sufficient budget, it can consider purchasing a better CPU for a new server. However, for servers already in use, hardware optimization may not be suitable, so it is necessary to optimize from the software direction.

Software optimization can be divided into two categories: software upgrade and protocol optimization.

Let's talk about the first software upgrade. Software upgrade means upgrading the software you are using to the latest version, because the latest version not only provides the latest features, but also optimizes the problems or performance of the previous software. For example:

• Upgrade the Linux kernel from 2.x to 4.x;
• Upgraded OpenSSL from 1.0.1 to 1.1.1;
• …

Software upgrades may seem simple, but for companies with hundreds or thousands of servers, software upgrades are just as thorny a problem as hardware upgrades. This is because software upgrades take time and manpower, and there are certain risks involved, which may also affect normal online services.

In this case, we turn our attention to protocol optimization, that is, to optimize the existing links through minor changes.

Protocol Optimization

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

(1) Key exchange algorithm optimization

If TLS 1.2 uses the RSA key exchange algorithm, four handshakes are required, which means it takes 2 RTTs to transmit application data, and the RSA key exchange algorithm does not have forward security.

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

Therefore, if possible, try to use the ECDHE key exchange algorithm instead of the RSA algorithm, because the algorithm supports "False Start", which means "preemptive start". The client can send encrypted application data after the third handshake of the TLS protocol and before the fourth handshake, thereby reducing the round-trip message of the TLS handshake from 2 RTTs to 1 RTT. It is also highly secure and has forward security.

The ECDHE algorithm is implemented based on elliptic curves. Different elliptic curves have different performances. You should try to choose the x25519 curve, which is currently the fastest elliptic curve.

For example, on Nginx, you can use the ssl_ecdh_curve directive to configure the elliptic curve you want to use, putting the preferred one 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 key length is shorter.

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

(2) TLS Upgrade

Of course, if possible, directly upgrade TLS 1.2 to TLS 1.3. TLS 1.3 greatly simplifies the handshake steps. It only takes 1 RTT to complete the TLS handshake, and it is more secure.

In the TLS 1.2 handshake, generally four handshakes are required. First, the encryption algorithm to be used later must be negotiated through the Client Hello (first handshake) and Server Hello (second handshake) messages, and then the public keys are exchanged (third and fourth handshakes), and then the final session key is calculated. The left part of the figure below is the handshake process of TLS 1.2:

The right part of the above picture is the handshake process of TLS 1.3. It can be found that TLS 1.3 combines the two messages of Hello and public key exchange into one message, so it only takes 1 RTT to complete the TLS handshake.

How is the merger done? Specifically, the client carries the supported elliptic curves and the public keys corresponding to these elliptic curves in the Client Hello message.

After receiving the message, the server selects an elliptic curve and other parameters, and then returns the message with the server's public key. After this RTT, both parties have the materials to generate the session key, so the client calculates the session key and can encrypt and transmit the application data.

Moreover, TLS1.3 has "slimmed down" the cipher suite. For the key exchange algorithm, the RSA and DH algorithms that do not support forward security have been abolished, and only the ECDHE algorithm is supported.

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

• 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 various old and insecure cipher suites. The middleman can use downgrade attacks to forge the client's Client Hello message and replace the cipher suite supported by the client with some insecure cipher suites, forcing the server to use this cipher suite for HTTPS connection, thereby cracking the ciphertext.

Certificate Optimization

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

There are two directions for optimizing certificates:

• One is certificate transmission
• One is certificate verification

1. Certificate transmission optimization

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

2. Certificate verification optimization

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

This access process is HTTP access, which will incur a series of network communication overheads, such as DNS query, connection establishment, data sending and receiving, etc.

(1) CRL

CRL is called Certificate Revocation List. This list is updated regularly by CA. The list contains the serial numbers of revoked certificates. If the server's certificate is in this list, it is considered to be expired. If not, the certificate is considered to be valid.

However, there are two problems with CRL:

• The first problem is that since the CRL list is maintained by the CA and updated regularly, if a certificate has just been revoked, the client will still trust the certificate before the CRL is updated, which is less timely.
• The second problem is that as the number of revoked certificates increases, the list will become larger and larger, and the download speed will become slower. After downloading, the client has to traverse such a large list, which will cause a large delay in the client's certificate verification process, thereby slowing down the HTTPS connection.

(2) OCSP

Therefore, OCSP, also known as the Online Certificate Status Protocol, is now basically used to query the validity of the certificate. It works by sending a query request to the CA and asking the CA to return the validity status of the certificate.

Unlike the CRL method, the client does not need to download a large list and query it from the list. At the same time, because the validity of each certificate can be queried in real time, the real-time problem of CRL is solved.

OCSP needs to query the CA, so a network request is required, and it also depends on the CA server's "face". If the network status is not good or the CA server is busy, it will also cause the client to have a longer delay in verifying the certificate.

(3) OCSP Stapling

In order to solve this network overhead, OCSP Stapling came into being. Its principle is: 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 will send this "response result" to the client during the TLS handshake process. Due to 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 again.

Session reuse

The purpose of TLS handshake is to negotiate the session key, which is the symmetric encryption key. If we cache the symmetric encryption key negotiated in the first TLS handshake, and then reuse the key the next time we need to establish an HTTPS connection, wouldn't that reduce the performance loss of TLS handshake?

This method is called TLS session resumption. There are two types of session resumption:

• The first one is called Session ID
• The second type is called Session Ticket

(1) Session ID

The working principle of Session ID is that after the initial TLS handshake connection between the client and the server, both parties will cache the session key in memory and identify it with a unique Session ID. The Session ID and session key are equivalent to a key-value relationship.

When the client connects again, the hello message will carry the Session ID. After receiving it, the server will look for it in the memory. If it is found, it will directly use the session key to restore the session state, skipping the rest of the process, and only using one message round trip to establish secure communication. Of course, for security reasons, the session key in the memory will expire periodically.

But it has two disadvantages:

• The server must maintain the session key of each client. As the number of clients increases, the memory pressure on the server will also increase.
• Nowadays, website services are generally provided by multiple servers through load balancing. When the client connects again, it may not hit the server it visited last time, so it has to go through the complete TLS handshake process.

(2) Session Ticket

In order to solve the Session ID problem, Session Ticket came into being. The server no longer caches the session key of each client, but instead leaves the caching work to the client, similar to HTTP Cookie.

When the client and server establish a connection for the first time, the server will encrypt the "session key" and send it to the client as a Ticket, and the client will cache the Ticket.

When the client connects to the server again, it sends a Ticket. After the server decrypts it, it can obtain the previous session key and then verify the validity period. If there is no problem, the session can be resumed and encrypted communication can begin.

For clustered servers, ensure that the key used to encrypt the "session key" of each server is consistent, so that when the client carries the ticket to access any server, the session can be restored.

Neither Session ID nor Session Ticket has forward security, because once the key that encrypts the "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 her identity to Bob. Bob asks for Alice's password as proof of identity, which Alice does her best to provide (possibly after transformation such as through a hash function). Meanwhile, Eve eavesdrops on the conversation and keeps the password (or hash).

After the exchange is complete, Eve (posing as Alice) connects to Bob. When asked for proof of identity, Eve sends Alice's password (or hash) read from the last session which Bob accepts, granting Eve access.

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

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

(3) Pre-shared Key

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

TLS1.3 is even more powerful. For reconnection, TLS1.3 only needs 0 RTT. The principle is similar to Ticket, but when reconnecting, the client will send the Ticket and HTTP request together to the server. This method is called Pre-shared Key.

Similarly, Pre-shared Key is also at risk of replay attacks.

As shown in the figure above, suppose the middleman somehow intercepts the client's POST request using session reuse technology. Usually, the POST request will change the database data. Then the middleman can send the intercepted message to the server. After receiving it, the server also considers it to be legal, so it restores the session, causing the database data to be changed again, but the user is unaware of it at this time.

Therefore, to counter replay attacks, you can set a reasonable expiration time for the session key and use session reuse only for safe HTTP requests such as GET/HEAD.

Summarize

As for hardware optimization, since HTTPS is computationally intensive, a CPU with stronger computing power should be selected, and it is best to choose a CPU that supports the AES-NI feature. This feature can optimize the AES symmetric encryption algorithm at the hardware level and speed up the encryption and decryption of application data.

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

Regarding 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 the handshake process of TSL1.3 only requires 1 RTT and is more secure.

For certificate optimization direction:

• The server should use ECDSA certificates instead of RSA certificates, 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, obtain the OCSP response in advance, and cache the response result. In this way, the CA server does not need to be accessed during the TLS handshake, which reduces the network communication overhead and improves the efficiency of certificate verification.

When reconnecting to HTTPS, we can use some technologies to allow the client and server to use the session key used in the previous HTTPS connection to directly resume the session without going through the entire TLS handshake process again.

Common session reuse technologies include Session ID and Session Ticket. With session reuse technology, when reconnecting to HTTPS, only 1 RTT is needed to resume the session. For TLS1.3, Pre-shared Key session reuse technology is used, and only 0 RTT is needed to resume the session.

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