If every TLS message has to be encrypted / decrypted by both hosts involved in the secure connection, is this consuming a lot of CPU time?

  • Yes, it needs time. But todays computers can handle it without major delays. – deviantfan Jun 14 '16 at 17:18
  • 3
    There are many answers already on this site if you search "https performance". The computational overhead will be less and less of a problem on the client side compared to network latency. Servers with modern CPUs with cryptographic offload can help or you can use dedicated SSL gateways. – billc.cn Jun 14 '16 at 17:20
  • Helps also to nowadays have hardware acceleration build in to standard computers for this task. – user7933 Jun 14 '16 at 18:50

I believe the website "Is TLS Fast Yet" https://istlsfastyet.com can answer your question. Here's a quote from the top of the page:

"On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers will help to dispel that." -- Adam Langley, Google


Just performed some tests on single board ARM CPU PC: As many web questions I stumbled, also here the answer is "it depends". I tested with AB (Apache Benchmark) from PC on same network and just HTTP1.1 (do not have HTTP2 due to old Linux/Apache version)

So... if KeepAlive is disabled- performance is really bad. CPU load is high.

If AB uses KeepAlive and Apache uses KeepAlive 5 or 10- performance is still bad. Still high CPU load.

If KeepAlive is insane high 200... performance is acceptable.

So if domain sharding is used, the HTTPS performance is bad. If just one domain is used with high keepalive than the performance is acceptable.

First handshake to establish the connection makes the difference.

And yes HTTPS is like taking taking medicine if you are cold, but having to travel to next city. If you have to go for every pill to the next city and ask for directions to the next open pharmacy- it hurts you more. If you take the pack- it is acceptable.

p.s. I guess that the ARM CPU does not have hardware acceleration for the encryption or it is not enabled. It is like the CPU software rendering of games vs the GPU cores vs dedicated graphic card.

  • 1
    This is mostly a good answer, but it would probably improved by indicating some benchmarks for what 'high' and 'low' are. – Adonalsium Oct 17 '18 at 19:02
  • Not scalable, but 200-300 HTTP requests per second for small file and 30% CPU usage, 20-50 for high keepalive HTTPS and 2-3 requests per second for HTTPS without keepalive. For HTTPS the CPU usage is above 50% – Gergo Oct 17 '18 at 19:11
  • What is a "small file". What is the CPU time consumed per file transaction and CPU clock frequency. – zaph Oct 18 '18 at 0:43
  • Just tested with other PC (old but decent) with self signed certificate- instead of 2.5 on the ARM, I got 30-50 transfers per second for the laptop (no keepalive). 20% CPU usage and 6W core power. On the laptop concurrent connections are possible and this increases performance (80 r/s). On the ARM the SSL handshake fails when using concurrency. It really depends. ARM might get better if I manage to enable the HW acceleration (I suspect that it is disabled). Just 100Mbps LAN. If someone wants to test just the SSL impact- test with the loopback (localhost). There are too many factors. – Gergo Oct 18 '18 at 6:02

No matter how fast your systems are: Time == Money. CPU Time == CPU Money

The issue is not as much "is encryption under TLS or SSL fast" but rather "how much processor do you have to spare?".

AES encryption (used in TLS) is computationally intensive and expensive. As an answer points out here "SSL/TLS accounts for less than 1% of the CPU load". If, for example, it accounted for (being generous) 0.5% of the CPU load and the system had 199 simultaneous TLS connections being processed, the 200th one would have to wait because the processor was maxed out.

But 200 is not really a realistic number of connections... Lets say you are in the top web sites in the world... say in the top 0.1%, up there with NASA during Xmas, the IRS around April 15 or just an average day on CNN's web site. You are talking somewhere well beyond 70,000,000 HTTPS connections (hits) a day. So lets do the math...

70,000,000 HTTPS connections (hits) a day is 2,916,666 hits an hour 48,611 hits a minute 810 hits a second.. a hit is a file download...

So if that system is using HTTPS instead of HTTP and we give the encryption the benefit of the doubt that it is only 0.5% processor load then...

That means that you to handle the same traffic at the same load factor we need to increase the capacity of the system to handle... 0.5% * 810 is 4.05 hits per second or 0.5% * 48,611 is 243 hits per minute or 0.5% * 2,916,666 is 14,583 hits per hour 0.5% * 70,000,000 is 350,000 hits per day

The cost is 350,000 hits per day the extra capacity needed to use HTTPS.

This translates in architectural terms into adding extra SSL/TLS accelerator CPUs to keep the load off the actual web servers. And of course, any reasonable hosting architecture has to have redundancy so multiply the SSL/TLS accelerator box cost times 2, then stir in both human support costs and tech refresh costs to adequately maintain your HTTPS

Now consider if this is all for non-authenticated access... nothing that required encryption to keep it private... (like free news or sales and marketing material) then you just wasted your money and time with HTTPS vs unencrypted HTTP.

What makes more sense is to encrypt that which needs to be secure (logins, connections to restricted or private content) and leave the rest that need not be secured, unencrypted.

Arbitrarily using HTTPS for public data is like taking an antibiotic each time you get a cold... WebMD Cold Guide

  • 2
    Apart from very few special cases (e.g. a software repository where the authenticity of the content is verified through other channels), there aren't any parts on a typical website that don't need to be secured. This is all the more true if your website gets the amount of traffic that it could even noticeably affect costs. And it's not like mixing HTTPS and HTTP would make maintenance simpler. (The mention of antibiotics is of course a red herring). – Marc Schütz Nov 20 '17 at 10:28
  • 1
    1) You encrypt data in transit so your marketing materials are not tampered with by ISP or whatever rouge there is (and there is a lot) 2) If you have 70M hits a day you are big target for injection in transit, so better have HTTPS 3) Most company pages don't get even 350k hits a day so your CPU is idling, then better to use spare cycles to do encryption – Mateusz Oct 17 '18 at 19:12
  • 200 is not the number of connections a day, but the number of simultaneous connections. Any more than a few thousand and you will be simply incapable of performing any more, TLS or not. You seem to have completely misunderstood the source you are criticizing. -1 – forest Oct 18 '18 at 4:07
  • @MarcSchütz Even a signed software repository needs TLS. Imagine if this software repository were tampered with over MITM to simply remove the links to the signed digests, for example, making it likely that most people would simply assume it is not signed. – forest Oct 18 '18 at 4:09
  • @forest By "verified through other channels" I was thinking of the signing key being shipped on installation media, as is common in Linux distributions. Without something like that, you're of course vulnerable to MITM. It was just meant as a real-life example, I didn't want to go into the details in a simple comment. – Marc Schütz Oct 18 '18 at 12:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.