views:

400

answers:

3

(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 accurate?

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?

A: 

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.

Scooterville
it's not "approx 10x", it's "approx 12KB extra" for each connection setup.
Javier
There's startup overhead, and there's per-packet overhead. Per-packet overhead could be on the order of 30-50 bytes for padding and hash. 12K for startup sounds plausible, the number of certs presented during handshake by the client and server can vary quite a bit. Sophisticated clients and servers can cut down on that a with session resumption as the other answer says.
Marsh Ray
+2  A: 

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.
brianegge
+1  A: 

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/.

Nasko