Ferrite.“Every connection named to its process.” Here’s what that actually means.
A connections list is only useful if you can trust the names in it. Ferrite doesn’t guess which app opened a connection, and it doesn’t stop at a port number when it can read what’s actually on the wire. Two separate mechanisms, both verifiable.
Where the process name comes from
Windows itself keeps a live table of every TCP and UDP endpoint on the system and which process owns it — the same table the built-in netstat reads. Ferrite polls that table directly, so the process ID next to a connection isn’t inferred from timing or heuristics — it’s the number the OS itself assigns as the owner. That PID is then resolved to a full executable path, which is how a connection shows up as a named app instead of a bare port number.
This works in every edition, including Free, with no admin elevation required for your own processes — reading another user’s process path needs it, which is a Windows permission boundary, not a Ferrite one.
The one honest gap
The table is polled on an interval, not watched continuously. A connection that opens and fully closes faster than a single poll window can, in principle, come and go without ever appearing in a snapshot — which means a per-process block rule has nothing to act on for that specific flow. This matters for vanishingly short-lived connections; it doesn’t change the picture for anything that stays open long enough to matter, which is effectively everything you’d want to see or block. We’d rather name this limit than pretend attribution is instantaneous.
Where the protocol name comes from
Ferrite recognizes 120+ distinct protocols by name, and it does that in two different ways, not one:
- Identified — most protocols are named from their conventional port (the same logic behind “port 443 is HTTPS”), which is fast and works without reading payload bytes. The connections list marks these as inferred, not confirmed.
- Deep-inspected — for 30+ protocols, Ferrite actually reads the bytes: a TLS ClientHello, an HTTP verb line, an SSH version banner, a DNS header shape, a WireGuard or QUIC packet structure, a BitTorrent handshake, and more. This is confirmation, not inference — and it’s also what makes TLS-SNI-aware rules possible, since the hostname a connection is actually reaching comes out of that same handshake read.
Protocol identification — both tiers of it — is a Pro capability, tied to the same deep-inspection engine that reads TLS handshakes for SNI rules. Process attribution is not: knowing which app made a connection is free-tier, in every edition; knowing what protocol it’s actually speaking, confirmed rather than guessed, is what Pro adds on top.
Why bother with two tiers of protocol naming
A port-based guess is right most of the time and costs nothing to compute — there’s no reason to throw that away. But a guess is still a guess: plenty of traffic runs somewhere other than its default port, deliberately or not. Reading the actual bytes is how Ferrite tells the difference between “probably HTTPS because it’s on 443” and “confirmed TLS, and here’s the hostname it asked for” — the distinction that makes a DNS-bypass or disguised-traffic rule actually enforceable instead of a best guess.