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

What this article shares with you is about the optimization of HTTPS based on protocol and configuration. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Optimization based on protocol and configuration

Preface

I talked about the impact of HTTPS on user access speed.

This article introduces the optimization of HTTPS based on protocol and configuration in terms of access speed, computing performance, security and so on.

Optimization of HTTPS access speed

Tcp fast open

HTTPS and HTTP use the TCP protocol for transmission, which means that a TCP connection must be established through a three-way handshake, but is it too wasteful to transmit only one syn packet in a RTT? Can I send data from the application layer with the syn packet? In fact, it is possible, this is also the idea of tcp fast open, referred to as TFO. The specific principle can refer to rfc7413.

Unfortunately, TFO needs the support of a higher version of the kernel, and linux supports TFO since 3.7. but the current windows system does not support TFO, so it can only play a role between the company's internal servers.

HSTS

As mentioned earlier, redirecting user HTTP request 302 to HTTPS has two effects:

Insecure, 302 redirects not only expose users' access to the site, but are also easily supported by middlemen.

Slow down the access speed, 302 jump not only requires a RTT, the browser to perform the jump also takes time to perform.

Because the 302 jump is actually triggered by the browser and the server has no complete control, this requirement led to the birth of HSTS:

HSTS (HTTP Strict Transport Security). The server returns a http header of HSTS. After the browser gets the HSTS header, for a period of time, whether the user enters baidu.com or http://www.baidu.com, the request will be transferred to https://www.baidu.com by default.

Chrome, firefox, and ie all support HSTS (http://caniuse.com/#feat=stricttransportsecurity).

Session resume

As the name implies, Session resume is to reuse session to simplify the handshake. There are two benefits of reusing session:

The CPU consumption is reduced because the calculation of asymmetric key exchange is not required.

Improve the access speed without the need for a full handshake phase II, saving a RTT and computing time.

TLS protocol currently provides two mechanisms to implement session resume, which are introduced respectively.

Session cache

The principle of Session cache is to use the session id in client hello to query the session cache of the server. If the server has the corresponding cache, it directly uses the existing session information to complete the handshake in advance, which is called the simplified handshake.

Session cache has two disadvantages:

Server-side memory is consumed to store session content.

At present, open source software including nginx,apache only supports shared cache among single machines and multiple processes, but does not support distributed cache between multiple machines. For Baidu or other large Internet companies, stand-alone session cache has little effect.

Session cache also has a very big advantage:

Session id is the standard field of TLS protocol, and all browsers on the market support session cache.

Through the optimization of TLS handshake protocol and server side, Baidu has supported global session cache, which can significantly improve the access speed of users and save server computing resources.

Session ticket

The previous section mentioned two shortcomings of session cache, which session ticket can make up for.

The principle of Session ticket refers to RFC4507. A brief description is as follows:

Server encrypts the session information into ticket and sends it to the browser, and the browser will send the ticket,server to the subsequent handshake request. If the ticket,server side can successfully decrypt and process the ticket, the handshake can be simplified.

Obviously, the advantage of session ticket is that there is no need for the server to consume a lot of resources to store session content.

Disadvantages of Session ticket:

Session ticket is only an extended feature of the TLS protocol, and the current support rate is not very wide, only about 60%.

Session ticket needs to maintain a global key for encryption and decryption, and the security and deployment efficiency of KEY need to be considered.

Generally speaking, the functional features of session ticket are significantly better than those of session cache. It is hoped that the client implementation will give priority to supporting session ticket.

Ocsp stapling

Ocsp, the full name of online Certificate status check Protocol (rfc6960), is used to query CA sites for certificate status, such as whether to revoke. In general, the browser uses the OCSP protocol to initiate a query request, CA returns the certificate status content, and then the browser accepts the status of whether the certificate is trusted.

This process is very time-consuming, because the CA site may be abroad, the network is unstable, and the RTT is relatively large. Is there any way not to request OCSP content directly from the CA site? Ocsp stapling can achieve this function.

Refer to section 8 of RFC6066 for a detailed description. The principle is that the browser initiates client hello with an extension of certificate status request. When the server sees this extension, it returns the OCSP content directly to the browser to complete the certificate status check.

Since browsers do not need to query the certificate status directly from the CA site, this feature has a significant improvement in access speed.

Nginx currently supports this ocsp stapling file. You only need to configure the ocsp stapling file command to enable this feature:

False start

In general, application layer data cannot be transmitted until the complete handshake is over. This is actually a waste of time, so can you send out the application data together in the second stage of a complete handshake, just like TFO? Google proposed false start to implement this function. For more information, please refer to https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00.

A simple summary of the principle of False start is to send the application layer data together when the client_key_exchange is issued, which can save a RTT.

False start relies on PFS (perfect forward secrecy perfect forward encryption), while PFS relies on a series of DHE key exchange algorithms (DHE_RSA, ECDHE_RSA, DHE_DSS, ECDHE_ECDSA), so try to give priority to supporting ECDHE key exchange algorithm to implement false start.

Use SPDY or HTTP2

SPDY is a protocol (https://www.chromium.org/spdy) introduced by google to optimize the transmission efficiency of HTTP. It basically follows the semantics of HTTP protocol, but it realizes many features through the use of frame control, which significantly improves the transmission efficiency of HTTP protocol.

The most important feature of SPDY is multiplexing, which can send multiple HTTP requests together on the same connection, unlike the current HTTP protocol, which can only send requests one by one in series. Although Pipeline supports multiple requests to be sent together, it still has to be received sequentially when receiving, which essentially can not solve the concurrency problem.

HTTP2 is the next generation protocol of HTTP adopted by IETF in February 2015. It is based on SPDY and is finally determined after more than two years of discussion and improvement.

This article will not cover too much of the benefits of SPDY and HTTP2, and need to explain two points:

The current implementation of SPDY and HTTP2 uses the HTTPS protocol by default.

Both SPDY and HTTP2 support the existing HTTP semantics and API, and are almost transparent to WEB applications.

Google announced that chrome browsers will abandon the SPDY protocol and fully support HTTP2 in 2016, but at present, the progress of some domestic browser manufacturers is very slow, not only does not support HTTP2, not even SPDY.

Both Baidu server and Baidu mobile browser now support the 1 protocol.

Optimization of HTTPS Computing performance

Give priority to ECC

Compared with ordinary discrete logarithm, ECC elliptical cryptography has much better computing speed. The following table is the key length comparison table recommended by NIST.

Symmetric key size | RSA and DH key size | ECC key size

|-80 | 1024 | 160,112 | 2048 | 224128 | 3072 | 256192 | 7680 | 384,256 | 15360 | the recommended key length for NIST.

For RSA algorithm, at least a key length of more than 2048 bits is used to ensure security. ECC only needs to use a 224-bit key to achieve the security strength of the RSA2048 bit length. It is obviously much faster to do the same modular index operation.

Use the latest version of openssl

Generally speaking, the new version of openssl will improve the computing speed and security compared with the old version. For example, openssl1.0.2 adopts the latest optimization results of intel, and the computing performance of elliptic curve p256 is improved by 4 times. (https://eprint.iacr.org/2013/816.pdf)

Openssl was upgraded five times in 2014, mostly to fix BUG or algorithmic vulnerabilities in the implementation. So try to use the latest version to avoid security risks.

Hardware acceleration scheme

There are two kinds of TLS hardware acceleration schemes commonly used today:

SSL special accelerator card.

GPU SSL acceleration. The mainstream use of the above two schemes is to insert the hardware into the PCI slot of the server, and the hardware performs the most performance-consuming calculations. However, such a scheme has the following disadvantages:

The supporting algorithm is limited. For example, do not support ECC, do not support GCM and so on.

The cost of upgrading is high.

When a new encryption algorithm or protocol appears, the hardware acceleration scheme cannot be upgraded in time.

When there are relatively large security vulnerabilities, some hardware solutions can not be upgraded in a short period of time. Such as the heartbleed vulnerability exposed in 2014.

Unable to take full advantage of hardware acceleration performance. Hardware accelerators generally run in kernel state, so it takes IO and memory copy overhead to transfer the computing results to the application layer. Even if the hardware computing performance is very good, the synchronization wait and IO overhead of the upper layer will lead to the overall performance falling short of expectations and unable to make full use of the computing power of the hardware accelerator card.

Poor maintainability. Most of the hardware driver and application layer API are provided by security manufacturers, and manufacturers need to follow up when there are problems. Users can not grasp the core code, more passive. Unlike open source openssl, users can master both algorithms and protocols.

TLS remote agent computing

It is precisely for the above reasons that Baidu has implemented a dedicated SSL hardware acceleration cluster. The basic idea is:

Optimizing the TLS protocol stack and stripping off the calculations that consume the most CPU resources mainly include the following parts:

Encryption and decryption calculation in RSA.

Public and private key generation in ECC algorithm.

Shared key generation in ECC algorithm.

Optimize the hardware calculation part. Hardware computing does not involve protocol and state interaction, but only needs to deal with large number operations.

Tasks between Web server and TLS computing clusters are asynchronous. That is, after web server sends the computing content to the accelerated cluster, it can still continue to process other requests, and the whole process is asynchronous and non-blocking.

HTTPS security configuration

Protocol version selection

SSL2.0 has long been proved to be an insecure protocol. Statistics show that no client supports SSL2.0, so you can safely disable the SSL2.0 protocol on the server side.

The POODLE attack broke out in 2014, and SSL3.0 proved to be insecure. However, statistics show that 0.5% of the traffic only supports SSL3.0. So SSL3.0 can only be supported selectively.

TLS1.1 and 1.2 so far no security vulnerabilities have been found, so it is recommended to give priority to support.

Cipher suite selection

The cipher suite consists of four parts:

Asymmetric key exchange algorithm. It is recommended to give priority to the use of ECDHE, disable DHE, and choose RSA as the second priority.

Certificate signature algorithm. Since some browsers and operating systems do not support ECDSA signature, the default is to use RSA signature, in which SHA1 signature is no longer secure. Chrome and Microsoft no longer support SHA1-signed certificates (http://googleonlinesecurity.blogspot.jp/2014/09/gradually-sunsetting-sha-1.html)) since 2016.

Symmetrical encryption and decryption algorithm. The AES-GCM algorithm is preferred, and RC4 (rfc7465) is disabled for protocols above 0.

Content consistency checking algorithm. Both Md5 and sha1 are no longer secure, so it is recommended to use secure hash functions above sha2.

HTTPS anti-attack

Prevent protocol degradation attacks

There are generally two kinds of degradation attacks: cipher suite degradation attack (cipher suite rollback) and protocol degradation attack (version rollback). The principle of the degradation attack is that the attacker forges or modifies the client hello message so that the client and the server use a weak encryption suite or protocol to complete the communication.

In order to deal with degraded attacks, the SCSV function is now implemented between the server side and the browser. The principle is referred to https://tools.ietf.org/html/draft-ietf-tls-downgrade-scsv-00.

In a word, if the client wants to downgrade, it must send a signal of TLS_SCSV. If the server sees TLS_SCSV, it will not accept a protocol lower than the highest version of the server.

Prevent renegotiation attacks

There are two types of renegotiation (tls renegotiation): cipher suite renegotiation (cipher suite renegotiation) and protocol renegotiation (protocol renegotiation).

There are two hidden dangers of renegotiation:

Use a weak security algorithm after renegotiation. The consequence is that the content of the transmission can be easily leaked.

In the process of renegotiation, complete handshake requests are continuously initiated, which triggers the server to carry out high-intensity calculation and cause a denial of service. For renegotiation, the most direct protection measure is to prohibit the client from actively renegotiating. Of course, for the needs of special scenarios, the server should be allowed to initiate renegotiation actively.

The above is what the optimization of HTTPS based on protocol and configuration is, and the editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

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.