Application-layer filtering: why port 443 proves nothing

Classic firewall rules were written in ports: allow 80 and 443 for the web, 25 for mail, block the rest. That made sense when each service had its own port. Today, almost every app speaks HTTPS on port 443: browsers, chat apps, update checkers, analytics libraries, and attackers too. MITRE ATT&CK documents this under T1071, Application Layer Protocol: command-and-control traffic deliberately blends into ordinary web traffic so a port rule cannot tell them apart.

Filtering by application, not by port

NIST’s firewall guidelines (SP 800-41) describe application-aware filtering as a step beyond packet and port rules. On an endpoint, the most useful application attribute is identity: which program opened the connection. On macOS, that identity can be verified through the app’s code signature, which ties it to a developer and makes it hard to impersonate.

• A rule like “Zoom may reach zoom.us” is meaningful; “port 443 is allowed” is not.
• If identity is checked by signature, a fake app called “Zoom” does not inherit Zoom’s rules (MITRE ATT&CK T1036, Masquerading).
• An unsigned program, or one whose signature is broken, is a strong signal on its own.

What an encrypted connection still reveals

Encryption hides the content of a connection, but not everything around it. Before encryption starts, most TLS connections announce the name of the site they want in the Server Name Indication field (SNI), defined in RFC 6066. DNS lookups, unless they are themselves encrypted, reveal which names an app asked for. And some traffic still travels in the clear.

There is another path, TLS interception: installing a trusted root certificate so a security tool can decrypt and re-encrypt everything. It sees more, but it becomes a very attractive target, weakens the encryption guarantees apps rely on, and breaks apps that pin their certificates. For a personal device, it is usually the wrong trade.

How FireAI inspects without decrypting

FireAI identifies every app by its code signature and matches rules by app and destination. It does not install a root certificate and never reads the inside of an encrypted connection. It looks only at what a connection announces before encryption starts, or what is already sent in the clear:

• Secure connections: it reads the site name announced in the TLS handshake and blocks it if a threat list you turned on names it.
• Unencrypted secrets: it blocks unencrypted web requests carrying card numbers, bank details, passwords or keys before they leave the Mac.
• Hidden data in lookups: it blocks a technique that smuggles data out disguised as DNS lookups (MITRE ATT&CK T1071.004).
• It reads DNS answers to attach real host names to apps that connect by IP address.

Where it stops

Newer standards narrow this view on purpose. Encrypted Client Hello (ECH), being standardised at the IETF, hides the site name inside the handshake, and encrypted DNS hides lookups. As they spread, name-based inspection sees less, and app identity plus destination address become even more important. The blog article on ECH and DNS-over-HTTPS goes deeper into what that means for firewalls.

Try it: read an app’s identity

You can see the identity a firewall relies on. In Terminal, the read-only command codesign -dv --verbose=2 followed by the path of an app (for example /Applications/Safari.app) prints its identifier and the team that signed it, and spctl --assess -vv on the same path says whether Gatekeeper accepts it and why. Try it on an app you downloaded recently. The blog guide on reading code signatures and notarisation from Terminal walks through the output line by line.

Then think about what a rule should say. “This app, signed by this developer, may reach these names” survives an attacker renaming a file or copying an icon. “Anything on port 443 is fine” survives nothing.

Layers, not a silver bullet

None of these checks is sufficient alone, and each one fails differently. Identity rules fail if a trusted app is itself compromised. Name inspection fails when names are hidden or when an attacker uses a legitimate service. Threat lists only know what has already been reported. Plaintext checks only see what is sent unencrypted. Used together, they cover more of each other’s gaps, which is the same layered reasoning the course on layers of security applies to the whole system.