172

I know there's no single hard-and-fast answer, but is there a generic order-of-magnitude estimate approximation for the encryption overhead of SSL versus unencrypted socket communication? I'm talking only about the comm processing and wire time, not counting application-level processing.

Update

There is a question about HTTPS versus HTTP, but I'm interested in looking lower in the stack.

(I replaced the phrase "order of magnitude" to avoid confusion; I was using it as informal jargon rather than in the formal CompSci sense. Of course if I had meant it formally, as a true geek I would have been thinking binary rather than decimal! ;-)

Update

Per request in comment, assume we're talking about good-sized messages (range of 1k-10k) over persistent connections. So connection set-up and packet overhead are not significant issues.

Community
  • 1
  • 1
joel.neely
  • 30,725
  • 9
  • 56
  • 64
  • 1
    Can you characterize your application a little more? For example, does it establish a lot of short-lived connections? While connected, how big does an individual message tend to be? (E.g., maybe you're flushing every key press with Telnet over an SSL tunnel, or maybe you're copying 1 Tb log files.) – erickson Feb 20 '09 at 23:51
  • You may take a look at this similar [question](http://stackoverflow.com/questions/149274/http-vs-https-performance). – Darin Dimitrov Feb 13 '09 at 23:05
  • Initial checking of the certificate chain takes a significant toll on the client side in terms of latency. – Louis Somers Jun 22 '22 at 00:35

3 Answers3

182

Order of magnitude: zero.

In other words, you won't see your throughput cut in half, or anything like it, when you add TLS. Answers to the "duplicate" question focus heavily on application performance, and how that compares to SSL overhead. This question specifically excludes application processing, and seeks to compare non-SSL to SSL only. While it makes sense to take a global view of performance when optimizing, that is not what this question is asking.

The main overhead of SSL is the handshake. That's where the expensive asymmetric cryptography happens. After negotiation, relatively efficient symmetric ciphers are used. That's why it can be very helpful to enable SSL sessions for your HTTPS service, where many connections are made. For a long-lived connection, this "end-effect" isn't as significant, and sessions aren't as useful.

Here's an interesting anecdote. When Google switched Gmail to use HTTPS, no additional resources were required; no network hardware, no new hosts. It only increased CPU load by about 1%.

Community
  • 1
  • 1
erickson
  • 265,237
  • 58
  • 395
  • 493
  • 7
    How do you "enable SSL sessions for your HTTPS service"? What's a good resource to learn about this? – Justin Vincent Feb 18 '10 at 20:00
  • 1
    Enabling SSL sessions is server-specific. Read the manual for your server. – erickson Oct 29 '10 at 18:32
  • 1
    Enabling SSL sessions, is that just using Keep-Alive or something more complex? – Bart van Heukelom Dec 03 '10 at 13:25
  • 7
    @Bart van Heukelom -- Keep-alive will help keep a socket (and the SSL connection) open for longer, which helps. But SSL sessions cause the negotiated cryptographic parameters to be "remembered" from socket to socket. So HTTP keep-alive would be useful for loading a single web page with its referenced content, but after a few seconds, that connection will close. Three minutes later, say, when another page is fetched, an SSL session allows the SSL connection to be re-established without repeating the full handshake. In particular, the *slow* key exchange with public key crypto can be skipped. – erickson Dec 03 '10 at 17:06
  • IMO, it's better to know why/when/where it's needed than to implement wholesale. Every little bit might not help performance at all (although I suspect there are in fact cases where it can make a bigger difference) but using it selectively will help you better understand why it's there and how/when it should be used. Blanket security is a security blanket, IMO. SSLimifying everything just to feel safe is more dangerous, IMO. – Erik Reppen Feb 05 '13 at 19:53
  • 1
    This answer is not useful. No mention of libraries and/or systems on which author made performance comparisons. The real world out there is much more complex than this simplistic answer. Anybody interested in real life I suggest you to ignore this answer. – Tony Aug 13 '13 at 23:48
  • 2
    @Tony do you have any real world examples where TLS adds more than a few percent overhead? My answer is as general as the question. If you have a different take, please share it. – erickson Aug 14 '13 at 05:17
  • I won't mention (fairly well known) libraries in the comment, but I've seen plain sockets outperforming SSL 'sockets' by a factor of 250. But you are right that question is general so answer is as well. For ex. what is comm processing versus app processing in SSL? SSL model is different from socket model so is reconciling them in a library API a comm or an application layer? And this is where, in my experience, lies the proverbial devil in the details. – Tony Aug 15 '13 at 01:09
  • 3
    @Tony I've seen plain sockets outperform SSL sockets by a factor of 42 in terms of space when writing a single byte at a time, which is the worst case. Never seen 250x. I did an extensive experiment over the Internet with 1700 data points where the general result was that plaintext sockets were no better than three times as fast as SSL, using programming no more sophisticated than buffering and flushing. JSSE, probably Java 5 given the date of the experiment. – user207421 Jul 21 '14 at 01:45
  • I'm going to note that this answer and the article it links to are 8 years old and woefully out of date thanks to known weaknesses in security algorithms. Modern security practices mandate TLS 1.2 or later, SHA-256, 2048 bit keys, and elliptical curve cryptography as **bare minimums** and it's recommended using TLS 1.3 and SSH3-256 (or higher) instead. – Powerlord Sep 29 '17 at 20:55
  • 2
    @Powerlord The article cited discusses outdated algorithms, but my answer does not, and I stand by its conclusions. Encrypt everything. – erickson Sep 29 '17 at 21:06
  • 1
    Stackoverflow did a long write about its effort to encrypt everything: [HTTPS on Stack Overflow: The End of a Long Road](https://nickcraver.com/blog/2017/05/22/https-on-stack-overflow/) – erickson Sep 29 '17 at 21:15
40

I second @erickson: The pure data-transfer speed penalty is negligible. Modern CPUs reach a crypto/AES throughput of several hundred MBit/s. So unless you are on resource constrained system (mobile phone) TLS/SSL is fast enough for slinging data around.

But keep in mind that encryption makes caching and load balancing much harder. This might result in a huge performance penalty.

But connection setup is really a show stopper for many application. On low bandwidth, high packet loss, high latency connections (mobile device in the countryside) the additional roundtrips required by TLS might render something slow into something unusable.

For example we had to drop the encryption requirement for access to some of our internal web apps - they where next to unusable if used from china.

Evgeniy Berezovsky
  • 18,571
  • 13
  • 82
  • 156
max
  • 29,122
  • 12
  • 52
  • 79
  • 21
    With 4 years hindsight: China might also just have intentionally messed up all SSL/TLS traffic. – max Sep 22 '13 at 16:53
  • 3
    China's censoring the internet and trying to sniff on everyone's traffic is not exactly news. With 4 years hindsight though, you'd think it was the NSA MITMing in on the way to your site. – Evgeniy Berezovsky Jun 02 '15 at 23:08
  • The key with flaky connections is, to set up the encryption once, and then avoid re egotiations unless really necessary, and allow both sides to change their IP addresses at any time without blinking an eye. (OpenVPN supports this.) IT helps to make fragmentation possible, as the MTU can be very unreliable and downright dishonest. – Evi1M4chine Sep 14 '16 at 23:46
12

Assuming you don't count connection set-up (as you indicated in your update), it strongly depends on the cipher chosen. Network overhead (in terms of bandwidth) will be negligible. CPU overhead will be dominated by cryptography. On my mobile Core i5, I can encrypt around 250 MB per second with RC4 on a single core. (RC4 is what you should choose for maximum performance.) AES is slower, providing "only" around 50 MB/s. So, if you choose correct ciphers, you won't manage to keep a single current core busy with the crypto overhead even if you have a fully utilized 1 Gbit line. [Edit: RC4 should not be used because it is no longer secure. However, AES hardware support is now present in many CPUs, which makes AES encryption really fast on such platforms.]

Connection establishment, however, is different. Depending on the implementation (e.g. support for TLS false start), it will add round-trips, which can cause noticable delays. Additionally, expensive crypto takes place on the first connection establishment (above-mentioned CPU could only accept 14 connections per core per second if you foolishly used 4096-bit keys and 100 if you use 2048-bit keys). On subsequent connections, previous sessions are often reused, avoiding the expensive crypto.

So, to summarize:

Transfer on established connection:

  • Delay: nearly none
  • CPU: negligible
  • Bandwidth: negligible

First connection establishment:

  • Delay: additional round-trips
  • Bandwidth: several kilobytes (certificates)
  • CPU on client: medium
  • CPU on server: high

Subsequent connection establishments:

  • Delay: additional round-trip (not sure if one or multiple, may be implementation-dependant)
  • Bandwidth: negligible
  • CPU: nearly none
Jan Schejbal
  • 4,000
  • 19
  • 40
  • Important note: Nobody should use RC4 ever again. The protocol mus be considered broken and RC4 transmission with it must be seen as equivalent to unencrypted transmission at the very least for safety from spying organizations. Nowadays, something like chacha20-poly1305 is strongly recommended for bulk encryption due to its independence from such organizations. – Evi1M4chine Sep 14 '16 at 23:42