A retailer kept the full packet capture for a checkout session, and the file body inside that session is unreadable while the session uses TLS. What is the monitoring impact?
Select an answer to reveal the explanation.
Short Explanation
Think of the packet headers as a parcel’s address and the TLS-protected file body as its sealed letter. You have the full capture, so encryption hides the file body while the endpoint addresses remain visible; the capture did not fail, address translation is not stated to have removed the destination, and a firewall denial does not explain an existing captured session.
Full Explanation
Encryption hides the file body while the endpoint addresses in the capture stay visible. TLS encrypts application data, including the file body, while IP addresses are in packet headers outside the encrypted record. A full capture therefore stores the headers and encrypted bytes, showing who communicated but not what file moved; the body is unreadable, not absent. The claim that the capture failed completely and stored neither addresses nor payload bytes conflicts with the full packet capture: the headers and encrypted bytes are present. The claim that address translation removed the destination invents an effect not described in the scenario; encryption does not delete an address from the IP header. The claim that the firewall denied the flow and the session carried no file body does not explain an existing captured TLS session. A denied flow is not why its TLS body cannot be read. Exam caveat: visible IP addresses do not mean the web address, file name, or file contents are visible; TLS content stays hidden without the keys. Practical check: verify that the capture contains IP headers for both endpoints and that the application bytes are TLS records you cannot decode without the session keys.