With TLS in place, what can Wireshark on the open network still see of a garage-door command, and what is now hidden?
Still visible: IP addresses and ports, the TCP and TLS handshakes including the offered cipher suites and (in TLS 1.2) the server's certificate, and the size and timing of each encrypted record. Hidden: the HTTP method, path, headers, body and response.
* TLS hides what was said, not who talked to whom, when, or how much. *
| Layer | Plain HTTP | HTTPS (TLS 1.2) |
|---|---|---|
| IP addresses, ports | Visible | Visible |
| TCP handshake | Visible | Visible |
| TLS handshake: versions, cipher suites, randoms | – | Visible |
| Server certificate (subject, issuer, validity) | – | Visible in TLS 1.2, encrypted in TLS 1.3 |
| Method, URL path, headers | Visible (POST /opengaragedoor) |
Hidden |
| Body and response | Visible | Hidden; only "Application Data" with a length |
What remains is metadata, and metadata leaks. Every button press opens a new connection to the same server, so an observer sees that a command was sent and when. AES-GCM does not pad, so a record's length is the plaintext's length plus a fixed overhead: if the "close" request's path is a character longer than the "open" one, its record is a byte longer, and the observer can tell open from close without decrypting anything. Padding requests to a fixed size closes that gap.
Note that a connection to a plain IP address carries no SNI (the host name extension in the ClientHello) because IP literals are not allowed there. With a host name, SNI shows it in clear in both TLS 1.2 and 1.3.
Go deeper:
Wireshark wiki — TLS — the tlsdisplay filter and how to inspect and decrypt TLS captures.- Wikipedia — Traffic analysis — what can be inferred from patterns of encrypted communication.