You blocked the gaming site but cannot block just one YouTube channel. You allowed the news site but cannot stop its video section. The reason is one word — HTTPS — and once you understand what encryption hides and what it still shows, every filtering decision gets easier.
Almost every website today runs on HTTPS, which means the connection between the browser and the site is encrypted end to end. That is excellent for security and privacy — and it fundamentally changes what any office filter can see. This page explains, in plain words, what your firewall can still see (more than you might fear), what it cannot (the exact page), and the three real options when domain-level blocking is not fine-grained enough.
When a browser starts an HTTPS connection, it must tell the server which site's certificate to present — many sites share one server. That name travels in a field called SNI (Server Name Indication), and it is sent before encryption begins. So your firewall and DNS logs can see youtube.com, facebook.com, something-shady.example — the domain, every time. What SNI never contains is the page, the video, the search words or the account. Domain-level filtering works because of SNI and DNS; page-level filtering fails because of encryption. Both facts come from the same design.
For most offices this is the correct and honest answer. Social media is a domain. Streaming is a set of domains. Gambling and adult categories are domain lists. The cases that feel like they need page-level control usually dissolve on inspection — allow YouTube for training but not entertainment sounds reasonable until you price the machinery needed to tell a training video from a music video. Domain rules plus a sensible exception process cover real office needs at a fraction of the cost.
A firewall can decrypt HTTPS — by standing in the middle: it makes its own encrypted connection to the site, and a separate one to the PC, reading everything in between. This is TLS (SSL) inspection, and it genuinely enables full-URL rules. Now the costs, stated plainly:
Large regulated organisations do this with legal advice and full disclosure. A 20-PC office almost never should.
When page-level control is truly needed, the practical place is on the device, where the browser has already decrypted the page for display: browser extensions and endpoint agents (the browser-control features in tools like ManageEngine) can apply rules to full URLs, keywords and uploads. SaaS apps add their own lever: your Google Workspace or Microsoft 365 admin console can restrict parts of those services directly. Use the layer that can actually see the thing you want to control — and write the SNI reality into your policy document so nobody promises management a filter that physics will not deliver.
The full video shows each method working — this page explains the encryption wall every method runs into.
▶️ Watch Full VideoThe encryption questions behind every filtering argument.
Because of HTTPS encryption. Your filter sees the domain — youtube.com — in the DNS query and the SNI field, but the channel and video address travel inside the encrypted connection where no network filter can read them. Page level control needs endpoint software or TLS inspection.
SNI is the site name a browser sends in plain text while setting up an HTTPS connection, so the server knows which certificate to show. It is the reason domain-based blocking and category filtering still work in an encrypted web — the domain remains visible even though the content does not.
Almost certainly not, unless you are a large or regulated organisation with legal advice. It requires installing a trust certificate on every device, excludes banking and health traffic, breaks certificate-pinned apps, concentrates everyone's decrypted data on one box, and must be disclosed to staff. Domain filtering plus endpoint tools covers normal office needs.