Description

Transport Layer Protocols’ Experiments with Wireshark
Ahmet UYAR
Part 1.1. UDP Experiment My UDP segment:

[1] UDP Segment
1.1.1. Time to live: 64

[2] TTL
If time to live reaches zero before the packet has reached its destination, the packet gets discarded, packet loss will occur.
1.1.2. Stream index: 0

[3] stream index
In Wireshark, the “stream index” for a UDP segment is an identifier used to organize and display related UDP packets in a sequential manner. It helps analyze the flow of UDP communication between specific source and destination IP addresses and ports, simplifying the examination of packet sequences within Wireshark.

[4] checksum
1.1.3. Checksum value of the segment: 0x603d
1.1.4. Value of my segments reserved bit flag:

[5] reserved bit flags
The reserved bit is 0. In the IPv4 header, there’s a Reserved bit that’s kind of like an empty space reserved for possible future uses—it hasn’t been decided what it’ll do yet. When you see the Reserved bit as 0, it just means it’s not doing anything special right now. It’s like a placeholder, kept there in case they want to add new features or changes to the system later on. Right now, everyone agrees to ignore whatever the Reserved bit might mean because it’s not defined yet. It’s just there, waiting for potential updates to the protocol.
1.1.5. Value of my packet length: 86

[6] packet length
Since 86 bytes have been captured, then the total length of the packet combined with its data, header, and placeholder should be 86

[7] total length of packet

[8] packet length without header
20 bytes (header length) + 52 bytes (data length) + 14 bytes (placeholder length) = 86 bytes
Part 1.2. TCP Experiment
1.2.1. No segment loss or no retransmissions

[9] successful post request
As shown in the figure, the connection is between the IPs 172.21.132.90 and 128.119.245.12. Using the postfilter “tcp.analysis.retransmission”, we do not see any retransmissions occur between these IPs

[10] segment loss not in post request

[11] payload
As we can see in the above figure, 55959 bytes were in the TCP payload and by Frame 4269, all of them were successfully transmitted.
1.2.2.

[12] RTT for request
We can infer from the graph that between t=7 and t=7.40, the round trip time has decreased from 143.7 to 140. After t=7.40 the round trip time linearly increased up to t=7.78 and then slowly linearly increased up to t=8.
1.2.3.
TCP-specific information, such as sequence numbers, acknowledgment numbers, window size, and TCP flags are apart from UDP information.
Sequence Numbers:
Explanation: Sequence numbers help organize and rebuild data at the receiving end, making sure everything is in the right order. Each piece of data in TCP has a sequence number, so even if things arrive a bit mixed up, they can be put back together correctly.
Significance: Sequence numbers ensure that data gets put back together accurately, even if it arrives in a jumbled order.
Acknowledgment Numbers:
Explanation: Acknowledgment numbers show what the next expected piece of data is, confirming that everything before it has been received successfully. They let the sender know that all the previous data has made it through.
Significance: Acknowledgment numbers are important for making sure data is intact and controlling how fast the sender sends more data based on what the receiver can handle.
Window Size:
Explanation: Window size is like a traffic cop, deciding how much data the sender can send before it has to wait for a signal from the receiver. It’s a way of managing how much space the receiver has to store incoming data.
Significance: Window size helps control the flow of data, preventing the sender from overwhelming the receiver and keeping communication running smoothly.
TCP Flags:
Explanation: TCP uses different flags, like SYN (start), ACK (confirm), FIN (finish), RST (reset), PSH (push), and URG (urgent), to send specific messages during communication. These flags help with setting up and ending connections, managing data flow, and handling special situations.
Significance: Flags are like communication signals that help in starting and ending connections, controlling data flow, and dealing with different situations in a network. For example, the SYN flag kicks off a connection during the initial handshake.
1.2.4.
TCP Flowchart:

[13] TCP flowchart

[14] UDP flow chart
The flow graphs for TCP and UDP segments in Wireshark reveal key differences in how data is transmitted. TCP, being a reliable protocol, starts with a formal connection establishment (three-way handshake), sends data in an ordered sequence, and employs flow control mechanisms for reliable delivery. It often concludes with a formal connection termination. On the other hand, UDP, a connectionless protocol, lacks a formal connection setup, transmits data independently and without guaranteed order, and does not use flow control. It does not have a specific connection termination process. These differences underscore TCP’s reliability and structured communication compared to UDP’s lightweight, unordered, and connectionless nature.
2.1
2.1.1
No. 56 – Client -> Server
SSL Protocol is used for server port 4444

[15] Sent application data (not hello server)

[16] packet information
No. 104 – Client -> Server. Port 4443 for the server was used.

[17] tcp connection push

[18] packet information for tcp push 2.1.2
We can see the sent message observing the TCP case:

[19] inferrable data of TCP push
But when we observe the hello statement of Client:

[20] SSL application data transmission
The body is:

[21] unattainable information for SSL data transmission
We cannot observe the text in the TLS secure case. The reason is because SSL has an encryption scheme and disallows data observation without the private key.
2.1.3
TCP Case:

[22] TCP connection data
Indeed, the data “3732383437434f4d503431360d0a” results in the string “72847COMP416” in ASCII

[23] TCP Data converted to ASCII
SSL Case:

[24] SSL connection data
As we can observe, the application data is encrypted. “Change Cipher Spec” operation is also repeated so each time a possible adversary encounters a different scheme. Observing or interpreting the resulting encrypted data is meaningless.
As shown here;

[25] unattainable data from SSL transmission
2.1.4 – Using the below results in our java project we have created the following graph SSL Case:

[26] 5 recurrence of connection for SSL
TCP Case:

[27] 5 recurrence of connection for TCP

[28] Plot for data received in [27] and [26]
The reason SSL cases showed quicker execution times than TCP might be because SSL has an initial setup (handshake) but then becomes more efficient for ongoing data transfer. Unlike TCP, SSL only performs the handshake once during connection setup, and if connection reuse methods are used, this overhead is spread across multiple requests. TCP has a slower start, causing higher delays at the beginning of a connection. Network factors like latency, bandwidth, and packet loss also impact SSL and TCP performance. Additionally, the specific implementation and optimizations in Java’s SSL handling can influence the observed differences in delays. Analyzing the captured packets in Wireshark can give more details on SSL handshake, data transfer, and network traffic.
2.1.5
The “Client Hello” and “Server Hello” packets are part of the SSL/TLS handshake process when a client wants to securely connect to a server.
● Client Hello Packet: When a client initiates a connection, it sends a “Client Hello” packet to the server. This packet includes information like the supported SSL/TLS versions, supported cipher suites (encryption algorithms), and other details.
● Server Hello Packet: In response to the “Client Hello,” the server sends a “Server Hello” packet. This packet contains information like the chosen SSL/TLS version and cipher suite. It’s the server’s way of saying, “I acknowledge your request, and here’s how we’ll communicate securely.”
Observations:
● Client Hello: This is like the client saying “hello” and presenting a list of options for secure communication.
● Server Hello: The server responds by picking the best options from the client’s list and establishing the specifics of the secure connection.
2.1.6

[29] Client Hello TLS handshake

[30] Server Hello TLS handshake

[31] Server and Client TLS handshakes
As we can observe in the figures above, handshake types are different only in Server Hello and Client Hello. It shows the sequence of the handshake process, where each type has a specific role in creating a secure communication channel.
The protocol avoids sending the certificate for each connection by using a process called session resumption. In the initial handshake between the client and server, the server sends its certificate to the client. After this, the server and client can agree to resume the session in subsequent connections. During session resumption, the server doesn’t need to send the certificate again; instead, both parties reuse the previously exchanged cryptographic parameters. This helps save bandwidth and speeds up the establishment of secure connections by skipping the redundant transmission of certificates.

[32] Client Hello

[33] Server Hello
Moreover, we previously observed packets that had content “Application Data” and “Change Cipher”. This means the handshake is still being used.
2.2
After setting the path of my Java JRE, I followed the steps in the oracle link. Password used to create:
AHMET3994

[34] Keystore generation using keytool
Performing a cat, we have:

[35] performing cat

[36] data successfully entered in keystore
After we have exported and gained the certificate, we then import to create the truststore cacerts.jks

[37] creating truststore using the created certificate and keystore
As a result, the truststore is created. We have now three files that will be added to the project deliverables.

[38] keystore, certificate, and truststore
REMINDER: Password used to create: AHMET3994
Deliverables
Keystore.jks: keystore file
Mykey.cer: certificate
Cacerts.jks: truststore
IMPORTANT TO NOTE: The pcapng file provided in the deliverables contains both the SSL and TCP packets
REFERENCES
[23], [25] – https://www.rapidtables.com/convert/number/hex-to-ascii.html