1

How can I identify precisely the exact number of bytes the ClientHello and ServerHello in a TLS traffic needs? this is for traffic analysis purpose to capture the TLS bytes of interest (client hello and server hello only).

  • It's variable length so you can't capture them based only on this. – Aria Feb 1 '18 at 15:36
3

How can I identify precisely the exact number of bytes the ClientHello and ServerHello in a TLS traffic needs?

The size of the ClientHello varies. Parts of it depend on a specific client TLS implementation or configuration, especially the number of ciphers offered by the client and the extensions. Then there are use case specific differences: for example the client might add ALPN extension to signal support for HTTP/2 in case of a web client. The size of the server_name extension depends on the size of target hostname. And then there might be additionally a session id or session ticket if the client tries to resume an existing session. Only if all these variations are known you can compute the size of the ClientHello simply be filling in the necessary parts in the ClientHello structure.

The ServerHello itself is similar variable size and depends mainly on the kind of extensions added. But, after the ServerHello you get additional variable parts until the ServerHelloDone message, like the certificates (which can differ in both number and size), key exchange specific parts and an optional variable-sized CertificateRequest. Similar, only if all of this is known you can compute site size of it.

If you instead just want to get some statistics about this you might do a packet capture of your favorite use case, extract the relevant parts and measure their size (or look at the length fields as RoraZ suggested). Note that any conclusions you draw from this only apply to the use case and context you've measured. It can be wildly different if other clients or other servers are used or even if the same clients or servers are used but the hostname and certificates differ.

If you've already captured traffic then getting the size of each record is simple since all records follow the same structure described in RFC 5246 section 6.2 Record Layer: first is the ContentType (one byte - 0x16 for records in the TLS handshake), then the protocol version (two bytes) and then you have the length of the remaining data (uint16, i.e. two bytes).

  • The TLS Record for a Client Hello has a length field. Seems like it would be straightforward to parse out. – RoraΖ Feb 1 '18 at 16:18
  • @RoraΖ: thanks for the input. I've included it into the answer. – Steffen Ullrich Feb 1 '18 at 16:22
  • @RoraZ+ Careful; each TLS record has a length field, but there is no guarantee the first server record is exactly the ServerHello message. The server can put more messages (Certificate, CertReq, ServerHelloDone) in the same record, or it can break the ServerHello message over multiple records (though I've never seen an implementation do the latter since usually multiple records are used only for long messages like Certificate and maybe Ticket). Each handshake message has a length field, which is correct except for not including its own header (always 4 bytes unles DTLS). – dave_thompson_085 Feb 1 '18 at 22:55
1

If running a tool like Wireshark is an option... here's a snapshot of a TLS handshake - you can see the length in bytes of the client hello, server hello (includes Ethernet/TCP framing):

TLS handshake

More details are available when you select each frame. For example, here's Client Hello:

enter image description here

Note I also added "ssl" (which includes TLS) in Wireshark's filter box to reduce network noise. Wireshark has an SDK as well.

0

The client hello is not a big block of 2000 bytes, I have seen between 80 and 300 bytes on my network approximately, some have sslid that is 32 bytes more and others have extensions that others don't, but is not a big block of 2000 bytes of memory, the for the server hello is similar. I will suggest you to capture traffic in your network and do the exercise.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.