0

Hello guys this is my first question here.
For my customer i was analyzing this ( anonymized ) capture because a SSL Handshake issue but i noted at first that TCP three way handshake is not as expected .
If you look at the screenshot , the three way handshake ACK ( third packet ) has the PUSH flag enabled because is carrying 178 bytes of payload.
With the original capture this packets contains the ssl ClientHello message.
How is it possible? This is not the TCP Fast Open (RFC 7413) , SYN and SYN+ACK don't contain the "fast open" option . The client is an IIS server which connects to a LDAPS server. Do you know any explanation about this behaviour? is there any standard or related RFC ?

thank you

enter image description here

Improve this question
1
  • RFC 7413 is an EXPERIMENTAL RFC, not a Standards Track RFC.
    – Ron Maupin ♦
    Commented Dec 27, 2020 at 15:57

1 Answer 1

Reset to default
1

It's completely normal to send data with the second ACK already. It's the client (socket initiator) sending the first part of its request (or initiating the SSL handshake). Since it's already received an ACK from the server, there's nothing prohibiting it.

For details, see RFC 793 Figure 6 - since the intiator has received the SYN/ACK sequence, the socket is already established on its side.

The server (listener) cannot send any data to the client until after it has received its ACK (the final one in the three-way handshake) - unless the TCP Fast Open option is used, which is still experimental (TCP Fast Open allows the server to send data right after it has receive the initial SYN).

Improve this answer
2
  • thank you for the answer Zak67 . I understand that is legitimate behaviour and data is also sent in advance , however it is strange to me to see this kind of handshake. On the other hand, why aren't all handshakes like that ?
    – Ryu
    Commented Dec 27, 2020 at 22:35
  • 1
    There are countless implementations of TCP, some more optimized, some less. It doesn't really make that much difference.
    – Zac67 ♦
    Commented Dec 27, 2020 at 22:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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