How much network overhead does TLS add compared to a non-encrypted connection?

(Approximately) how many more bits of data must be transferred over the network during an encrypted connection compared to an unencrypted connection?

IIUC, once the TLS handshake has completed, the number of bits transferred is equal to those transferred during an unencrypted connection. Is this ac开发者_Python百科curate?

As a follow up, is transferring a large file over https significantly slower than transferring that file over http, given fast processors and the same (ideal) network conditions?

---

I've gotten this question a few times, so I decided to write up a small explanation of the overhead with some sample numbers based on common case. You can read it on my blog at http://netsekure.org/2010/03/tls-overhead/.

Summary from blog post:

• The total overhead to establish a new TLS session comes to about 6.5k bytes on average.
• The total overhead to resume an existing TLS session comes to about 330 bytes on average.
• The total overhead of the encrypted data is about 40 bytes.

---

The short answer is: Your Milage May Vary (YMMV) - it all depends on your traffic pattern. There are a number of factors to take into account:

• The additional handshakes and certs will add 4-6KB to the TCP stream, this will result in more ethernet frames going across the wire as well
• Clients should download the certificate revocation list. Some tools like cURL omit this step. The crl may be cached by the browser, however, it usually doesn't have a long age associate with it. Verisign sets theirs to expire after four minutes. In my testing, I see Safari on Windows downloading the same 91KB file two times.
• TLS Session resumption can avoid the public key-exchange part of the handshake, as well as the certificate verification.
• HTTP keep-alives will keep the socket open, same as http, but has more savings when the socket is TLS.
• SSL compression support is starting to show up server side, but AFAIK, most browsers aren't implementing this yet. Additionally, if you are already compressing at the http layer, not much will be gained here. Potentially large gains could be had if the client is sending large amounts of text to the server, which ordinarily isn't compressed at the http layer.

---

In 2020, TLS 1.2 and 1.3 are more typical with AES-GCM being a streaming cipher mode with lower overhead.

See https://tools.ietf.org/id/draft-mattsson-uta-tls-overhead-01.xml#rfc.section.3.

Per packet, the overhead for AES-GCM is 29 bytes. The TCP MSS may be as large as 1460 (https://blog.apnic.net/2014/12/15/ip-mtu-and-tcp-mss-missmatch-an-evil-for-network-performance/). So for a large download (where the maximum MSS is used), the overhead would be 29:1431 which is 2.03%.

(Handshake overhead is separate being once-off)

---

An order of magnitude. See this. This is not too significant, if the information that is protected is worth securing. And remember that processor speeds can only go up, so performance will keep getting better.