0

I knew that the format of the TLS handshake message is as below.

"Record header+Handshake layer header+ Handshake message"

Now i have confusion while analyzing the TLS handshake messages on TCP. How the structure would look like from server in response to client hello.

Note:- Since TCP can handle segmentation i believe server hello,server crt ,server key exchange,server hello done can be handled can be received in segments and provide to tls.

There fore how does the raw date look like at the end of the all frames received till TCP ?

will be it be as below ?

Record header+Handshake layer header+Server hello +Record header+Handshake layer header+Server crt+Record header+Handshake layer header+server key exchange+Record header+Handshake layer header+server hello done

  or will it be omitting the record header ??

Record header+Handshake layer header+Server hello +Handshake layer header+Server crt+Handshake layer header+server key exchange+Handshake layer header+server hello done

3

This is implementation-dependent. The RFC says clearly that messages with the same content type MAY be put together into the same record but also that a single message might spread over multiple records. From RFC 5246 (TLS 1.2) section 6.2.1 Fragmentation:

Client message boundaries are not preserved in the record layer (i.e., multiple client messages of the same ContentType MAY be coalesced into a single TLSPlaintext record, or a single message MAY be fragmented across several records).

  • @ steffenUllrich thanks for the information!!. I am trying to analyze the TLS handshake traffic.Below is the question based on the above clarification:- 1) The above statement holds good for Handshake messages as well ? 2) if the single hand shake message is spread along multiple messages ,How does the Client side implementation know that the new message is continuation of the last message? – kumar s Oct 18 at 14:08
  • @kumars: a) Since Handshake is a single content type this is also true for Handshake messages. b) The messages (like Handshake) have their own length information and thus it is clear if the message is complete or not. If not complete it will be continued in the next record. For example in RFC 5246 section 7.4 you will find the struct Handshake with the field length. – Steffen Ullrich Oct 18 at 14:56
  • 1
    Remember Change Cipher Spec, although used only in handshake, is a different record type thus 'unmixy'. – dave_thompson_085 Oct 19 at 6:13
  • @dave_thompson_085: Thanks for pointing out that there is a difference between "Handshake" as a specific content type and "Handshake" as the process which includes messages with different content types, including but not only the "Handshake" content type. Mixing of messages within the same record cares about the content type, not about the process. – Steffen Ullrich Oct 19 at 6:49
  • thanks @steffenUllrich,@dave_thompson_085..Its clear right now. – kumar s Oct 20 at 17:52
0

All the PDUs of TLS (client hello, cert, server hello and so on) can be segmented by TCP with no problem, in general is responsibility of the operating system take all the parts and once all the data is ready at Layer7 (Application) then pass to the application (the program). If you want to think in sockets for example, you can think on a write operation of 5000 bytes that TCP will split on different packets, but there is no IP fragmentation here, is the TCP layer that splits the 5000 bytes. On the other hand, the receiver will wait on a receive system call (recv, read, or whatever) until all the 5000 bytes are received on the TCP stack and then unblock the syscall and pass the control to the application.

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.