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

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.

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.