How much network overhead does TLS add compared to

问题:

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

回答1:

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.

回答2:

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.

回答3:

On the overhead computed in http://netsekure.org/2010/03/tls-overhead/ , do you think you could've skipped the initialization vector (IV) for the AES in CBC mode? since it is AES128, I think 16 Bytes of IV need to be added to the overhead, making the total of 56 instead of 40 Bytes.

回答4:

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.