At a manufacturer, two hosts exchange files with a peer-to-peer protocol, and those transfers never appear in the web proxy log. Why is the web proxy the wrong place to look?
Select an answer to reveal the explanation.
Short Explanation
Two coworkers trading boxes in the lot never appear in the front-desk visitor book. You will not find that peer-to-peer trade in the web proxy, because the transfers do not pass through it. The trap is assuming the proxy sees every protocol, blaming encryption alone, or pointing at a printer VLAN list.
Full Explanation
Peer-to-peer file transfers do not pass through the web proxy between these two hosts is why the proxy log is the wrong place. A peer-to-peer transfer goes between the two hosts on a protocol that is not steered through the web proxy, so the proxy never sees the files and cannot record them. Absence from that log follows from the path, not from a failure of the log itself. The web proxy is treated as a sensor that records every protocol crossing the plant network overstates what a web proxy observes. It records traffic that actually uses it, not every protocol that crosses the plant. Encryption is treated as the sole reason a transfer would be missing from that proxy log picks a hiding method the stem does not rely on. Encryption can hide content inside a flow the proxy carries; it is not required to explain traffic that never entered the proxy. An access list on the printer VLAN is treated as the path those file transfers follow points at a printer-network access list the stem never places on this path. The two hosts are trading files with a peer protocol, not traversing the printer VLAN. Exam caveat: a peer protocol wrapped in web traffic and explicitly sent through the proxy could show up there. This stem's transfers never appear, which fits traffic that does not take that path. Operational check: look at session records between the two host addresses for the peer conversation instead of searching the web proxy log for the files.