Every request leaving your network is a piece of mail, and how much of it your firewall can read has changed three times.
For most of the web’s history, requests went out as postcards. The destination was written on the front and so was the message, and anything sitting on the route could read both. Then the postcard became a sealed envelope. The address on the outside still says something like mtrx.com, so the network can see which building the mail is going to, but not which desk inside and not a word of the letter. The third change is underway now. The envelope is going inside another envelope addressed to a forwarding service, and the network stops learning the destination at all.
Your firewall’s rules are written against whatever it can still read on the outside of that mail. As the readable part shrinks, so does the set of rules that can do anything.
How a firewall knows what it is looking at
“Block social media.” “Allow the two AI tools we sanctioned and block the rest.” “Block phishing sites and newly registered domains.” All reasonable asks, and all worth asking a follow-up question about: how does the firewall know?
Two ingredients make it work. First, somebody has to decide that a given domain is social media, or that a site registered four hours ago and hosting a login page is phishing. That is categorization and reputation work, done by commercial feed providers, by threat research labs inside the security vendors, and by community submission sources. Second, your firewall has to receive those lists and keep them current. That is what the security subscription actually buys, and update cadence matters as much as coverage. A device running without an active subscription is enforcing last year’s version of the internet.
The feeds tell the firewall what to look for: IP address and more importantly here are domain names. Matching them against live traffic is the harder half, and it depends entirely on what is still readable.
The postcard era: HTTP in the clear
When traffic was unencrypted, this was trivial. The request carried the destination host in a plain HTTP header, and deep packet inspection read it directly, along with the full path and the contents. That era is over, and the chart below is what the transition looked like.
The sealed envelope: HTTPS and SNI
What kept firewalls working through that shift was Server Name Indication. In the TLS handshake, the client announces which hostname it wants so the server knows which certificate to present, and that announcement travels in the clear. Firewalls have leaned on SNI for years.
Be precise about what SNI gives you, because this is where a lot of security conversations go wrong. It tells you the building, mtrx.com, and that is all. Not the path, not the resource, not the payload. Those are inside the envelope, and SNI does not open envelopes. A firewall matching on SNI alone can decide whether traffic is allowed to reach a destination. It can tell you almost nothing about what moves once it gets there.
That distinction has a direct cost. Most organizations carry gateway antivirus or anti-malware on their firewall or SASE platform, and against a sealed envelope it cannot scan the payload. It still sees session metadata, the hostname, and certificate and reputation signals, which is enough to make a policy decision and not enough to catch a file. Malware delivered inside TLS crosses the perimeter unscanned and arrives at the endpoint, where your EDR agent becomes the first control that actually inspects it rather than the last. Defense in depth assumes the network layer catches something.
Encrypted Client Hello: the envelope inside an envelope
ECH takes away the address on the outside. It encrypts the client hello itself, SNI included, and the outer handshake carries only a generic name belonging to the hosting provider. The observer learns you are talking to that provider. Every site behind it collapses into one indistinguishable destination.
Adoption is still small and concentrated on sites behind one large provider, but the direction is set, and the same privacy pressure that drove universal HTTPS is driving this. Anything in your stack that depends on reading SNI has a shelf life.
DNS over HTTPS: the backstop is closing
Another lever in matching on traffic via hostname is DNS. DNS inspection is the most efficient control in the stack. Block the lookup and no connection is ever established. Most firewalls do it, and it works well.
Encryption is coming for DNS as well, through DNS over HTTPS and DNS over TLS. This is separate from DNSSEC, which signs records for integrity but still transmits them in the clear. Browsers now ship with their own encrypted DNS settings, and when a browser resolves independently the query never reaches the resolver you configured or the firewall watching it.
The two changes are linked, and that is the part worth carrying out of this piece.
TLS inspection: opening the mail
TLS inspection is a different mechanism from everything above, and it is the one that restores visibility. The firewall terminates the session, reads what is inside, and re-encrypts before passing it on, the way a mail room would open a letter, inspect it, and put it in a fresh envelope.
It also holds up against ECH, though not the way people assume. An inspection proxy cannot decrypt the inner client hello, and the standard is explicitly designed to stop it from trying. Inspection survives because you control two things ECH depends on: the DNS your clients resolve against, and the trust store on a managed device. Withhold the ECH key at the resolver and the client completes an ordinary handshake your proxy can terminate. On an unmanaged endpoint you hold neither lever, which is worth knowing before you count on it.
It is not free. It costs processing headroom, and certificate pinning in applications like softphone clients means maintaining bypass lists. Call it what it is: a real commitment of capacity and configuration, and the main lever available for getting visibility back at the network layer.
Four things worth checking this quarter
The useful question is not whether encryption is winning. It is what your own platform can still see. Four checks answer that, and none of them takes longer than a coffee.
Are your security subscriptions and feeds current? An expired or absent subscription means the categorization and reputation lists behind every content rule stopped updating, quietly, on a date nobody logged.
Can your platform perform TLS inspection at all? Not whether it is enabled. Whether the capability exists. Some platforms cannot do it, and no amount of tuning changes that.
Does DNS security exist as a real capability in your stack, or only as a checkbox? Specifically, can it see and act on queries when the browser is resolving over DoH rather than through the resolver you assigned?
What in your current policy depends on reading SNI? Those are the rules with an expiry date attached.
If the answer to the second or third question is no, that is a roadmap and budget conversation rather than a configuration change, and it is better to have it deliberately than to discover the gap during an incident.
Where Matrix fits
We review firewall and SASE posture across a managed base of more than 400 clients, so we see the same gap regularly, and it is rarely a matter of a platform being poorly chosen. It is that inspection capability, DNS security, and subscription state were reasonable to treat as settled five years ago and are not settled now.
If you want a straight answer on what your current platform can and cannot see, we will run those four checks against your environment with you and tell you where the blind spots are, what is fixable in configuration, and what is not.
Request a firewall posture assessment or call 503-654-3000.
