[WireShark]TCP Three Way Handshake

WireShark를 통해서 TCP 3 WAY-HANDSHAKE를 추출하는 방법에 대해서 기술한다.

tcp.flags.syn==1 || (tcp.seq==1 && tcp.ack==1 && !tcp.nxtseq>0)

[기타 참고자료]

https://blog.packet-foo.com/2015/03/advanced-display-filtering/

TCP Three Way Handshake

Filtering for the packets of a TCP three way handshake may sound like a simple task, but it isn’t.  The first two packets are easy, because those are the only two that have the SYN flag set. To find these, simply filter on “tcp.flags.syn==1“. But what about the third packet? It has only the ACK flag, but that’s also true for all other packets following the handshake, so we can’t just use that flag (at least not alone). Now, Wireshark beginners often try to find a filter expression that looks at packet dependencies, e.g. like “filter a packet that has a sequence number equal to the sequence of the previous SYN packet of the same connection plus one.” – and such a filter does not exist. You simply cannot filter on things in two different packets at the same time. Filters always look at one packet at a time.

The workaround for filtering for the packet we want is to filter on values that can only be found in a packet that is the third packet of a three way handshake:

1. We know that the sequence number is one higher than in the SYN packet. Since the initial sequence number is random we would have a problem, but fortunately, Wireshark offers relative sequence numbers (turned on by default). This means that every SYN has a relative sequence number of zero, and the third packet will have a sequence number of one. So we filter on “tcp.seq==1“. And since we must have acknowledged the SYN/ACK from the server we know that the ACK number must also be one, which leads to a better filter: “tcp.seq==1 and tcp.ack==1“.Unfortunately, many packets can have a relative sequence number of one, because if the client (which initiated the connection, thus being the sender of the first and third packet) does not send any data (e.g. when receiving FTP-Data), the sequence will stay at one for the whole connection. So we need more fields to filter on that only appear in the third handshake packet.
2. We can exclude all packets that contain a TCP payload, because the third packet is empty (this may change with new rapid connection setup implementations in the future, but for the time being, it is empty). So we add the zero payload length to our filter: “tcp.seq==1 and tcp.ack==1 and tcp.len==0“
3. The next problem is that this filter will also show all empty ACK packets where we haven’t seen the SYN and SYN/ACK packet in the trace (because they weren’t captured early enough), so we need to find a way to make sure we only accept ACK packets where we have the SYN and SYN/ACK in the trace. There is an easy trick to do this, but it only works since Wireshark version 1.12 and later: Wireshark 1.12 is the first version to calculate initial RTT for all TCP conversations when it has the full three way handshake. So if the iRTT field is available, we know that we have seen the SYN and SYN/ACK packet. The final filter for the third handshake packet is: “tcp.seq==1 and tcp.ack==1 and tcp.len==0 and tcp.analysis.initial_rtt“.

To filter on all three way handshake packets: “tcp.flags.syn==1 or (tcp.seq==1 and tcp.ack==1 and tcp.len==0 and tcp.analysis.initial_rtt)” – keep in mind that this will show the handshake packets of any conversation, so there may be more than one set. If the filter doesn’t work for you, check if you have enable absolute sequence numbers.