How big are TLS records during a handshake? last month
I've asked some TLS size questions on Twitter and got some nice results :]
Around how many bytes is a Client Hello in TLS 1.2?— David Wong (@lyon01_david) June 22, 2017
Approximately how many byte is a Server Hello in TLS 1.2?— David Wong (@lyon01_david) June 22, 2017
People mostly got it right for the Client Hello. But it wasn't as easy for the Server Hello.
Client Hello → 212 bytes
Server Hello → 66 bytes
These are just numbers I got from a TLS 1.2 handshake with a random website. These numbers are influenced by the browser I use and the configuration of the server. But they should be close to that range anyway as the structure of a Client Hello or a Server Hello are quite simple.
In a TLS 1.2 handshake. What is bigger?— David Wong (@lyon01_david) June 22, 2017
A better question would be: what is the bigger message? and the Client Hello would always win. This is because the Server Hello only replies with one choice from the list of choices the client proposed. For example the server will choose only one ciphersuite from the 13 suites the client proposed. The server will choose one curve from the 3 different curves proposed by the client. The server will choose a single signature algorithm from the client's 10 propositions. And on and on...
Approximately how many bytes is a Server's Certificate in TLS 1.2?— David Wong (@lyon01_david) June 22, 2017
Everyone (mostly) got this one!
Certificate → 2540 bytes
Obviously, this is the biggest message of the handshake by far. The number I got is from receiving two different certificates where each certificate is about a thousand bytes. This is because servers tend to send the full chain of certificates to the client, longer chains will increase the size of this message. Probably why there are propositions for a certification compression extension.
Approximately how many bytes is a ClientKeyExchange in TLS 1.2?— David Wong (@lyon01_david) June 22, 2017
Approximately how many bytes is a ServerKeyExchange in TLS 1.2?— David Wong (@lyon01_david) June 22, 2017
ServerKeyExchange → 338 bytes
ClientKeyExchange → 75 bytes
Both of these messages include the peer's public key during ephemeral key exchanges. But the ServerKeyExchange additionally contains the parameters of the key exchange algorithm and a signature of the server's public key. In my case, the signature was done with RSA-2048 and of size 256 bytes, while the NIST p256 public keys were of size 65 bytes.
Using ECDSA for signing, signatures could have been smaller. Using FFDH for the key agreement, public keys could have been bigger.
Tim Dierks also mentioned that using RSA-10000 would have drastically increased the size of the ServerKeyExchange.
Maybe a better question, again, would be which one is the bigger message.
Which one is bigger in a TLS 1.2 handshake?— David Wong (@lyon01_david) June 22, 2017
People mostly got it right here!
The rest of the handshake is negligible:
ChangeCipherSpec is just 6 bytes indicating a switch to encryption, it will always be the same size no matter what kind of handshake you went through, most of its length comes from the record's header.
Finished is 45 bytes. Its content is a MAC of the handshake transcript, but an additional MAC is added to protect the integrity of the ciphertext (ciphertext expansion). Remember, Finished is the first (and only) encrypted message in a handshake.