What does an outbound rule 'allow tcp/443 to any' actually assert about the traffic it permits?
answer
- a header field, not a property
- who writes the number into the packet
- the registry is a convention
- no handshake is ever verified
- reachability of a port, not an application
basics
~20 sOnly that packets carrying destination port 443 may leave. The port number is a header field the sender chose, not a property of the application, so the rule permits whatever a host decides to send there.
solid answer
~50 sIt asserts reachability of a port, nothing more. A packet filter written on the five-tuple matches protocol 6 and destination port 443 in the header; those values are chosen by the client and by whatever software is listening at the far end. The port registry is a convention, not something TCP/IP enforces, so no handshake is verified and no application is identified. In practice that means a service moved onto 443 at a host someone controls, or another session tunnelled inside an ordinary-looking 443 flow, matches the same rule as a browser. The rule still buys something real: it bounds which ports hosts can reach, it defeats software that never tries another number, and its deny counters record what was refused. What it cannot do is say which application crossed, and at a branch with no inspection appliance there is nothing on the path that could.
go deeper
Be ready to say plainly that the sender picks the port number and the filter only compares numbers. Naming one everyday way something other than a browser ends up on 443 is enough at this level.
Explain which fields of the five-tuple the decision uses and who controls each one, and why the port registry is a convention rather than an enforcement point.
Show that you can state the control's limit without dismissing it: bound port space and deny-side evidence are real, application identity is not, and the compensating levers are destination sets and default-deny.
Own the framing that a rule base implies guarantees it never made, and be able to say which of those implied guarantees your organisation is currently relying on without evidence.
## What the rule matches A packet filter expressed as `permit tcp any any eq 443` is evaluated against fields in each packet's header: the IP protocol number (6 for TCP), the source and destination addresses, and the source and destination transport ports. That collection is the five-tuple. Every one of those fields is written by the sender. The filter compares numbers; it does not open a connection, does not observe a handshake, and has no way to ask the sending host what process produced the packet. | Field in the decision | Who chooses it | |---|---| | Source address | the sending host (subject to any anti-spoof filtering on the path) | | Source port | the client stack, from the ephemeral range | | Destination address | the sending application | | Destination port | the sending application, matching whatever the far end binds | | Protocol | the sending application | ## Why a port number is a claim, not a fact Port assignments are an addressing convention maintained in a public registry: 443 is *registered* for HTTPS, 22 for SSH, 53 for DNS. Nothing in the protocol stack checks that the bytes above a port belong to the registered service. A server binds whatever port its operator tells it to bind; a client sends to whatever port it is configured to reach. So "this flow is on 443" is a claim made jointly by two endpoints, at least one of which may be under the control of the person you are filtering. The adversary here is often not exotic. It is an insider or a piece of software choosing a number that is already permitted, because that is the number that works. Three ordinary shapes: - **Relocation.** The far-end service is configured to listen on 443 instead of its usual port. Nothing on the wire ever carries the port you denied. - **Encapsulation.** A tunnel is established over one permitted 443 flow, and arbitrary inner sessions ride inside it. Your other deny rules never see the inner ports, because they never appear in the outer header. - **Carrier substitution.** The same logical session runs over UDP/443 rather than TCP/443. A rule written for TCP does not cover it at all; it is a different protocol number and needs its own decision. ## What the rule genuinely buys It is a mistake to conclude that a port ACL is worthless. It bounds the reachable port space, which is a real reduction: commodity software that only ever tries its default port simply fails. It forces anyone going around it to do extra work, and that work is often visible as a configuration somebody had to make. Its deny side produces evidence — counters and logs showing that something on your network attempted a destination you refused, which is frequently the first sign that a host is doing something nobody asked for. And it is cheap: it runs at line rate on hardware that already exists at the site. ## What it costs to do better, and where that cost is infinite The alternative to matching numbers is looking at what is inside the flow, which requires a device on the path that can inspect and, for encrypted traffic, terminate and re-originate the session. At a twenty-person branch on consumer broadband, with an ISP router and a small firewall, that device does not exist and is not in the budget. Worse, for some traffic the alternative is unavailable at any price: a vendor agent that pins its own certificate will refuse a substituted one, and an application that speaks only QUIC on UDP/443 has no fallback you can read. So the honest position at such a site is not "we will inspect later"; it is "for these flows we will never know, and here is what we do instead". ## The sentence to be able to say out loud *An `allow tcp/443 any` rule asserts nothing whatsoever about which application crossed.* It says packets addressed to that port were allowed to leave, and that is the entire claim. Everything else — that it was TLS, that it was a browser, that it was business traffic — is an assumption layered on top by the reader, and interviewers ask this question precisely to see whether you layer it on. ## Where the compensating levers actually are When you cannot see inside, the remaining levers are the other fields and the shape of the policy: restrict *which destinations* a given host may reach on the permitted port (tight for servers, hard for user laptops), default-deny everything else outbound so the exception list is explicit and reviewed, and keep the deny logs because they are the only evidence the control produced anything. Those are weaker than inspection and you should say so rather than let a rule base imply a guarantee it never made.
- Does that rule also permit QUIC to the same destination?No. QUIC runs over UDP, so a rule matching protocol TCP with destination port 443 never matches it. UDP/443 is a separate decision you have to make explicitly, and forgetting it is a common gap: the same logical session can leave over the carrier you never wrote a rule for.
- The source port is 51344 — what does that field add to your decision?Almost nothing. The client stack picks an ephemeral source port, so it is the field the sender has the most freedom over and the least reason to keep constant. Writing policy on a source port is how old stateless ACLs got bypassed: an attacker simply sourced traffic from the number the rule trusted.
- If the rule proves so little, why keep it?Because it bounds the reachable port space cheaply, it stops software that only ever tries its default port, and the deny side produces evidence of attempts. The defect is not the rule; it is claiming the rule identifies applications. Keep it, and write down honestly what it does not do.
A port number is like the label on an envelope, not an inspection of what is inside: the sender writes it, and the sorting office routes on the label alone.
saying these in an interview costs you the question
- Says port 443 means the traffic is HTTPS
- Assumes the firewall validates a TLS handshake
- Treats a port ACL as an application allow-list
- Thinks only browsers use destination port 443
- Believes a TCP rule also covers QUIC on UDP/443