HTTPS Encrypts the Conversation, Not the Fact That It Happened

Open a packet capture of an HTTPS visit and the page text is not sitting in readable packets. That is the central promise of TLS: an observer on the path should not be able to read or alter the protected HTTP exchange.

The capture is not empty. It still contains the information needed to deliver packets, plus patterns created by the conversation. Privacy depends on knowing the difference between encrypted content and visible metadata.

The network addresses stay visible

Internet routers need source and destination IP addresses to move a packet. Those addresses therefore remain outside the TLS encryption. A local observer can see that a device connected to a particular address, when it connected and how long the exchange lasted.

One address may host many websites behind a content-delivery network, so it does not always identify the exact site. Conversely, a dedicated address can make the destination obvious. Mapping addresses to services is an inference that changes over time, not a permanent label.

Ports are visible too. TCP port 443 or UDP port 443 strongly suggests HTTPS or HTTP/3, but a port alone does not prove the application.

DNS may reveal the name first

Before connecting, a device usually resolves a hostname. Traditional DNS sends that question without encryption, so a capture can show the requested name directly.

DNS over HTTPS and DNS over TLS encrypt the question between the device and resolver. The observer still sees a connection to the resolver and later connections to destination addresses. The resolver itself receives the query, so encrypted DNS changes who can observe names rather than eliminating the observation.

Cached answers mean a capture may contain a connection without a preceding DNS query. Absence of DNS in a short capture is not proof that no lookup occurred.

The TLS handshake exposes some structure

The handshake negotiates versions, cryptographic algorithms and keys. TLS 1.3 encrypts more handshake material than older versions, but compatibility fields and packet structure remain visible.

The Server Name Indication historically carried the requested hostname in clear text so a server could select the right certificate before encryption began. Encrypted Client Hello is designed to protect that name when the client, DNS setup and server all support it. Deployment is not universal, so inspect the actual handshake rather than assuming the field is hidden.

Certificates are encrypted in ordinary TLS 1.3 handshakes after key establishment. In older TLS versions they may be visible and reveal names associated with the service.

Size and timing create patterns

TLS encrypts application bytes, but records and packets still have lengths and timestamps. A capture can show bursts, idle periods, retransmissions and direction. That can distinguish a short API request from a long video transfer even when neither payload is readable.

Traffic analysis can compare those patterns with known activity, but it is probabilistic. Caching, advertisements, personalization, multiplexing and changing page assets make identical-looking visits uncommon. A pattern is evidence, not a decoded page.

Transport details remain diagnostic

For TCP, sequence behaviour, acknowledgements, retransmissions, window sizes and connection setup remain visible. Those fields help diagnose loss, latency and stalls without decrypting HTTPS.

HTTP/3 runs over QUIC on UDP. QUIC encrypts most transport metadata that TCP exposes, while retaining enough header information for packets to reach the correct connection. A capture can still measure timing, direction, size and loss indicators, but the analysis tools and visible fields differ.

A VPN changes the capture point

Capture traffic on a device before it enters a VPN tunnel and the original destination flows may be visible. Capture on the local network after encapsulation and the observer mainly sees encrypted packets between the device and VPN server. Capture at the VPN exit and destination connections reappear.

This is why “what can a packet capture see?” is incomplete without naming where the capture was taken.

Handle captures as sensitive data

Even without readable HTTPS bodies, a capture can contain device addresses, hostnames, timing, unencrypted DNS, cookies from non-HTTPS traffic and unrelated background activity. Capture only systems you own or are authorized to inspect. Limit the interface and duration, then redact or synthesize examples before sharing.

HTTPS protects the conversation’s contents and integrity. It does not conceal every participant, timestamp or traffic pattern. A useful packet report says which field was observed, where it was captured and how strong the inference really is.