In this article
This distinction matters when a connection list shows a reassuring service name beside an unfamiliar app. The list can accurately report the destination port while knowing nothing about the protection applied to the data. You need to separate three questions: where the connection goes, which protocol it uses, and whether you trust the app sending it.
Start with the process and endpoint
Open Applications → Utilities → Activity Monitor, select Network, and find the app or helper you are investigating. Its sent and received byte counts help establish whether it is active. They do not establish TLS use.
For a selected process ID, Terminal’s built-in lsof can show numeric endpoints:
lsof -nP -a -p 12345 -i
Replace 12345 with the actual process ID. The -P option keeps port numbers numeric instead of replacing them with service names. Our guide to checking a Mac app’s network connections explains this inspection in more detail.
Read the destination after the arrow in a connected socket. A high-numbered local port and a remote port of 443 are different fields. A LISTEN row is also different from an established outgoing connection: it describes a socket waiting for connections. Neither row is a certificate report.
What port 443 actually tells you
The IANA service-name and port-number registry assigns HTTPS to port 443. It also explicitly cautions that traffic on a registered port need not correspond to the assigned service.
A program chooses a socket and implements a protocol. Assigning a familiar number does not add encryption to arbitrary bytes. In normal HTTPS, TLS provides the encrypted channel and server authentication; the port is a convention that helps the client find the service.
The reverse matters too: a connection on a different port is not automatically plaintext. HTTPS services can use an explicitly specified alternate port. You cannot reliably sort every app connection into encrypted and unencrypted groups from its number alone.
| Observation | What it supports | What remains unproved |
|---|---|---|
Remote port 443 | The endpoint uses the conventional HTTPS port | That this particular flow negotiated TLS |
| A service label such as “HTTPS” | The tool associates a name with the port or observed protocol | Which method the tool used to classify it |
TCP state ESTABLISHED | A TCP connection exists | TLS negotiation, certificate validity, or payload contents |
| App-specific TLS diagnostics | Evidence about the connection covered by that diagnostic | The behavior of every other connection from the app |
Before treating a label as proof, check the tool’s explanation of that label. A name derived from a number and a result derived from a TLS handshake are different evidence.
A measured example: ordinary HTTP on port 8443
We tested that distinction on macOS 15.7.5, Apple Silicon, on October 3, 2026. A small Python fixture opened a server on 127.0.0.1:8443, connected a client to it, and exchanged a synthetic HTTP request and response. Both endpoints were on the same Mac. No real account, browser session, or external server was involved.
The fixture used ordinary sockets and no TLS library. Port 8443 was deliberately chosen because it is commonly associated with alternate secure-web services. Here is what the two observations showed:
| Evidence collected | Actual result |
|---|---|
Numeric socket endpoint from lsof | 127.0.0.1:65514 → 127.0.0.1:8443, ESTABLISHED |
| Bytes received by the server | Plain-text GET /vaultdog-fixture HTTP/1.1 |
| Bytes returned to the client | Plain-text HTTP/1.1 200 OK and the synthetic body fixture |
| TLS setup in the fixture | None |
All sockets were closed after the observation. The test proves that using a number associated with secure web traffic does not itself encrypt bytes. It does not show that a particular commercial app sends plaintext, or estimate how often that happens.
We initially attempted a loopback bind on port 443, but this environment denied it without elevated privileges. We did not change privileges and did not complete a port-443 experiment. The direct claim about assigned port numbers is supported by IANA; the measured example is specifically on 8443.
Look for evidence that matches the connection
For a website open in Safari, use the browser’s connection and certificate information for that website. That evidence concerns the browser’s connection. Opening a developer’s homepage securely does not demonstrate how its separate desktop app transmits data.
For a desktop app, start with its official security or networking documentation. Look for a statement that names the service or feature you are using, rather than a general privacy slogan. If the app exposes connection diagnostics, compare the time, endpoint, feature, and app version with the event you observed.
Apple’s TLS security guide describes the encrypted channels and network APIs available on macOS. Those platform capabilities are useful context, but their existence is not an audit of every installed app. A network listing still needs separate protocol evidence.
A useful support question is: “For this feature and endpoint, what protocol protects the connection, and how can I verify it in the app’s diagnostics?” That is more answerable than sending a screenshot of 443 and asking whether the entire app is safe.
Read VaultDog’s service classification with that limit
VaultDog’s Network Watch helps associate observed connections with apps and inspect their endpoints. Its current service classification uses known port numbers: for example, port 443 is associated with HTTPS, and 8443 with secure web service traffic. These labels do not verify a negotiated TLS session.
Use that view to decide which app and destination need a closer look. VaultDog does not read the contents of HTTPS traffic. An encrypted connection also does not establish that its recipient is appropriate, that the app needed to send data, or that you approved the behavior.
Similarly, an estimated connection country is another piece of metadata, not a verdict about the service. Keep the endpoint, protocol evidence, and app’s purpose together when deciding what to investigate next.
