JNDI is a Java API for locating resources by name in a directory or naming service. The core idea is that an application asks a naming service to resolve a logical name to an actual resource, which can be a local object or a reference to something remote. In this context, that means JNDI can fetch a reference to a resource that may be hosted remotely (for example, a directory entry that points to a remote object or code). So JNDI’s role here is about locating and loading resources, potentially from remote servers, rather than encrypting traffic, parsing HTML, or serving DNS.

Intercepting traffic between two devices on a local network is accomplished by placing the attacker in the middle of the communication path. ARP spoofing does this by tricking devices on the LAN into associating the attacker’s MAC address with the IP address of another host (often the gateway). As a result, traffic that should go to that host is sent to the attacker, who can simply forward it on or modify it, effectively eavesdropping and potentially altering the communication. This positioning—being able to watch and control the data as it passes between two endpoints—is the essence of a Man-in-the-Middle attack. The other options don’t describe this scenario: DoS would disrupt or prevent traffic rather than intercept it, DNS cache poisoning targets name resolution rather than traffic routing at the LAN layer, and brute-force attacks aim to guess credentials rather than intercept communications.

To identify TLS handshake messages, look at the TLS protocol layer in your capture. The handshake is the sequence that sets up a secure session, so filtering for TLS (or SSL on older captures) focuses your view on the relevant traffic. Once you filter for TLS and expand the TLS protocol in a packet, you’ll see the handshake message types: ClientHello, ServerHello, Certificate, ServerKeyExchange, and Finished. These messages trace the negotiation of cryptographic parameters and the establishment of the secure channel, with the Finished message indicating the handshake has completed and normal encrypted data can follow. Other filters don’t fit this task because they target different protocols or layers: an HTTP filter would show web responses, not the handshake; a DNS filter would show name lookups; and ARP is a link-layer protocol unrelated to TLS. The TLS approach directly highlights the handshake steps, usually occurring after the TCP connection is established (often on port 443), and it’s the clearest way to identify the TLS handshake in a capture.

UDP is a connectionless, best-effort transport protocol. It does not establish a connection or perform a handshake before sending data, so there is no guarantee that a packet will arrive, nor that it will arrive in order. Packets can be lost, arrive out of order, or be duplicated, and the protocol provides no built-in mechanism for reliable delivery or retransmission. A checksum exists to detect corruption, but it does not provide error correction or delivery guarantees. Encryption is not provided by UDP itself; securing UDP requires additional layers (like DTLS or application-layer encryption). Because of its lack of delivery guarantees, lack of ordering, and absence of built-in error handling, the statement that best describes UDP is that it does not guarantee delivery, order, or error checking.