How do you easily determine the cost of switching from HTTP to HTTPS? Mainly look at the following points:

  • The computing power of the machine to decrypt (or sign) RSA’s private key
  • Long connection or short connection
  • The computing power of the machine against AES
  • Whether the client supports the SSL session reuse

Establishment of HTTPS connections

In simple terms, after the TCP handshake, the SSL handshake uses’ asymmetric encryption ‘to give both parties a’ symmetric encryption ‘password, and the subsequent data transmission uses’ symmetric encryption’. Note that asymmetric encryption is much more computationally demanding than symmetric encryption. There are many TLS/SSL certificates and many encryption methods. This article only discusses RSA 2048 certificates, which are transmitted using AES 256 CBC encryption.

RSA decryption speed

A secure RSA certificate is now typically 2048 bits long. For RSA algorithms, if we use the OpenSSL library (nginx and haproxy are both), we can use:

openssl speed rsa2048
Copy the code

This command checks the decryption speed of the physical machine, such as the following output on my computer:

Sign verify Sign/S verify/s RSA 2048 bits 0.003110s 0.000079s 321.5 12699.7Copy the code

For the server, the most important thing is to look at the value of ‘sign/s’. Here is’ 321.5′. This value indicates that the private key can only be decrypted 321 times per second on a single CPU. The number of HTTPS connections created per second is only 321 (even smaller considering the other consumption of the HTTP server).

In addition, we can also look at OpenSSL’s ability to encrypt AES symmetrically:

openssl speed aes-256-cbc
Copy the code

The result is this:

Type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes AES-256 CBC 95595.93K 104182.68K 105314.10K 103842.47K 104320.15KCopy the code

As you can see, AES is very fast in encryption and decryption (the result here is encryption and decryption traffic per second).

Long connection or short connection

Long connections used to reduce the overhead of TCP three-way handshakes, but with HTTPS, TLS/SSL handshakes can also reduce the overhead of asymmetric encryption.

SSL session

An SSL session simply means that the client can save the symmetric encryption key that has been discussed before. Next time, if both parties use the symmetric encryption key, the asymmetric encryption handshake can be skipped and the CONTENT of AES symmetric encryption can be directly carried out. This session reuse is more effective than the long connection above because it is connection-independent.

HTTPS offload Gateway option

Choose haProxy or nginx to do HTTPS offload for the following considerations:

  • Whether session cache is supported (TLS and ticket are not covered)
  • Whether to support SNI? If your public IP address resources are limited and multiple domain names need to be considered
  • Better monitoring

Both agents can do the first two, but third, nginx doesn’t have any metrics that allow you to collect the current SSL handshake speed, the percentage of sessions reuse, etc. Haproxy has similar metrics to work with and is a very useful feature. As far as agency is concerned, they are exactly the same. The only drawback is that the haProxy multi-process model is not master/slave, so when using TCP Reuseport, there is a small probability that the TCP RST will be generated during the Reload process.

conclusion

Thanks for reading.