Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
Aliaska Varieva
How TLS inspection splits an encrypted connection with an internal CA, what it breaks, the bypass list every deployment needs, and when a small office should skip it.
Encrypted traffic is now most of what crosses a firewall, and a firewall that can't read it can only judge where it's going, not what it carries. Inspection fixes that by opening the encrypted stream in the middle, at the price of a few broken apps and a very attractive target. This guide covers how TLS inspection works, what it breaks, the bypass list every deployment needs, and when a small office is better off without it.
TLS is the encryption behind the padlock in the browser. When a laptop opens a site, the two ends agree on keys, and nothing in between can read the traffic. That's the point of TLS, and it's also the problem for a security team: malware downloads, phishing kits and data leaving the company all travel inside the same encrypted tunnels as everything else.
TLS inspection, also sold as SSL inspection, HTTPS inspection or SSL decryption, breaks that tunnel in two on purpose. The laptop thinks it's talking to the site. It's talking to the firewall or the cloud proxy. The proxy opens its own encrypted connection to the real site, reads and filters what passes between the two, and re-encrypts it on the way through. CISA's 2017 alert on the subject describes it without euphemism: inspection "works by intercepting the HTTPS network traffic and performing a man-in-the-middle (MiTM) attack on the connection".
It's the same technique an attacker uses. The difference is consent: the company owns the devices, controls the certificate store, and tells its people it's happening. If the two halves of a TLS session are new to you, our decryption explainer covers the key exchange in plain words.
A browser only accepts a connection if the site's certificate chains up to a certificate authority it trusts. The proxy can't present the bank's real certificate, because it doesn't hold the bank's private key. So it makes its own.
The setup has three moving parts. First, the company creates an internal certificate authority, or uses one it already runs for Wi-Fi and VPN. Second, that CA's root certificate goes into the trusted store on every managed device, pushed by Group Policy, Intune or the RMM. Third, the proxy holds a signing certificate from that CA and mints a fresh leaf certificate for each site on the fly, with the right hostname on it. The laptop checks the chain, finds the company's root, and shows the padlock.
Microsoft's own cloud version, the TLS inspection feature in Entra Global Secure Access, shows the pattern clearly. Per its documentation (updated August 2026), you sign the service's request with your root or an intermediate CA, it creates a short-lived intermediate from that, and the intermediate "dynamically generates leaf certificates for TLS termination". The root has to sit in the trusted store on every client, or every handshake fails.
That last sentence is where deployments go wrong first. Unmanaged phones, a contractor's laptop, a Linux build box and every app that ships its own certificate store, such as Firefox in its default setup, Java and Python, never got the root. They see an untrusted certificate and refuse to connect. Willie Howe's walkthrough covers the firewall side of the setup and the certificate push:
The proxy has a second job that matters as much as the first. On the outside leg it has to validate the real site's certificate the way a browser would, because the laptop can no longer see it. CISA's alert names exactly this as the failure: the client "can only verify the connection between itself and the HTTPS interception product", so a proxy that accepts a bad certificate quietly downgrades everyone behind it.
Anything that checks who it's talking to more carefully than a browser does will notice the substitution. That's a security feature everywhere except behind your own firewall.
Certificate pinning. Many mobile apps, and plenty of desktop agents, ship with the exact certificate or key they expect from their own servers. A leaf minted by your CA doesn't match, so the app refuses the connection. Microsoft's Entra documentation says it plainly: "Many mobile applications implement certificate pinning, which prevents successful TLS inspection, resulting in handshake failures or loss of functionality." There's no fix on the proxy side. The only answer is a bypass rule.
Mutual TLS. Some services make the client prove its identity with a certificate of its own. A proxy in the middle can't present the laptop's client certificate, so the handshake fails. Device-based access to banks, government portals and some SaaS admin consoles works this way.
Microsoft 365. Microsoft's network connectivity principles (updated August 2026) tell admins to "bypass Microsoft 365 domains from TLS decryption, traffic interception, deep packet inspection, and network packet and content filtering". The same page lists TLS termination of any Microsoft 365 domain among the setups Microsoft hasn't tested and that "are known to cause connectivity issues". Teams calls, Outlook sync and OneDrive are the first tickets when this rule is missed.
HTTP/2 and newer protocols. Not every inspection engine speaks every protocol. Entra's TLS inspection, for one, "doesn't support HTTP/2 negotiation", so sites that require it won't load until they get a bypass rule. Older firewalls have the same gap with QUIC, which forces a block-QUIC rule so browsers fall back to inspectable TCP.
Update services. Windows Update, Apple's software update and the update channels of security agents are the usual first entries on a bypass list. A broken update is a quiet failure that nobody notices for weeks, which is worse than a loud one.
Browsers themselves can be picky too. The Chrome troubleshooting guide on allowing Chrome network access has a section on proxies and SSL inspection that covers the errors users report when the root is missing or the proxy hands out a bad chain.
Every working deployment runs on a bypass list, and the list is longer than the sales demo suggests. Build it before you switch inspection on, not one ticket at a time afterwards.
The last entry is a choice, not a compatibility fix, and it's the one teams skip. The next section explains why it belongs there.
Inspection concentrates risk in one place. The proxy sees every password, every session cookie and every file that crosses it in the clear, and it holds a signing key that every device in the company trusts. Whoever owns that box owns all of it.
Research on the products themselves isn't reassuring. A 2017 NDSS paper, The Security Impact of HTTPS Interception, measured interception at Firefox update servers, e-commerce sites and Cloudflare. The authors found "more than an order of magnitude more interception than previously estimated", and after testing popular middleboxes and client-side security software, concluded that "nearly all reduce connection security and many introduce severe vulnerabilities". CISA's alert, which cites that paper, adds that many products "do not properly verify the certificate chain of the server before re-encrypting and forwarding client data". Products have improved since, but the shape of the risk hasn't changed.
The sharper version is a firewall compromise. Edge appliances have carried a run of critical remote code execution bugs, and an attacker with root on the inspection device can sometimes pull the signing key. This r/sysadmin post from an admin who'd seen it happen twice in one year makes the case in four short paragraphs, and the poster's view is that you shouldn't be decrypting traffic "that isn't supposed to be seen by anyone":
Three habits shrink the risk. Keep the signing CA separate from the root you use for anything else, so you can revoke it without rebuilding Wi-Fi and VPN. Patch the appliance on the same days-not-weeks schedule as any internet-facing device. And keep the most sensitive traffic out of the decrypted set entirely, which is the fifth entry on the bypass list. The cipher choices on both legs matter too, and our cipher guide covers which ones the proxy should refuse.
Every firewall admin has had the week where the bypass list grew faster than the threats it caught.
Inline inspection still works with TLS 1.3, as long as the proxy terminates the connection itself. What TLS 1.3 removed is passive decryption: a monitoring box that only copied traffic and decrypted it later with the server's key no longer can, because every session uses throwaway keys.
The bigger change is Encrypted Client Hello, published as RFC 9849 in March 2026. Without it, the first message of a TLS connection names the site in plain text, in a field called SNI. A lot of filtering, including the "don't decrypt, just block by hostname" mode many firewalls run, depends on reading that field. ECH encrypts it. A firewall that doesn't terminate the connection sees an encrypted handshake to a CDN and nothing more.
The industry's answer is moving inspection onto the device. Endpoint security agents and secure web gateway clients inspect traffic before it's encrypted, on a machine you already manage, with no shared signing key on the edge. That's the direction the secure web gateway market has taken, and it's why many teams now pair a cloud gateway with the endpoint rather than decrypting at the firewall.
Inspection reads personal messages, medical portals and bank sessions along with everything else. In most places that requires telling people, and in some it requires more.
The practical baseline is the same everywhere. Put inspection in the acceptable use policy that staff sign. Bypass banking, health and personal finance categories, which most firewalls offer as built-in categories. Restrict who can read the decrypted logs, and keep them only as long as an investigation needs. In the EU and UK, data protection law treats decrypted traffic as personal data, so a works council or data protection officer may need to sign off before rollout. This isn't legal advice; it's the checklist to take to whoever gives you legal advice.
For an MSP, the notice belongs to the client, not to you. The client's policy has to say it, and the client's leadership has to approve it.
For a small office the useful question is what inspection would catch that the rest of the stack misses. That changes with what's already in place.
If devices run modern EDR, DNS is filtered, browsers are managed and Microsoft 365 is on Microsoft's own protection, the remaining gain from inspection is narrow: better visibility into downloads from unknown sites, and a way to enforce web policy when a user turns on DNS over HTTPS in the browser. That last point is the strongest argument for it, and it's the one a commenter raises in the r/msp thread below. The rest of the thread, from an MSP managing about 140 FortiGates, leans the other way: certificate pinning on phones, GDPR objections and a bypass list that never stops growing.
A workable middle path covers most small offices. Run DNS filtering on every device, block DNS over HTTPS to unknown resolvers by policy, keep EDR on every endpoint, and use the firewall's hostname-only filtering where ECH hasn't reached yet. Add full inspection only for a compliance requirement, a specific threat, or a regulated client that asks for it, and then start with a pilot group and the bypass list above.
Whichever way you go, check where the certificates landed. If you run OpenFrame, a script across a client's devices that lists the roots in the trusted store, with the output collected in one place, shows which machines have the inspection CA and which ones will throw certificate errors on day one.
TLS inspection is a sanctioned man-in-the-middle: an internal CA on every device, a proxy that mints certificates per site, and a second connection to the real server. It buys visibility at the cost of pinned apps, mutual TLS and Microsoft 365 traffic you have to bypass, plus a signing key that makes the inspection box the most valuable thing on the network. Build the bypass list first, keep sensitive traffic out of the decrypted set, tell people, and weigh it against DNS filtering and endpoint protection.
For the proxy layer itself, the next read is what a proxy server is and how forward and reverse proxies differ.
Head of Platform
Hi! I’m Aliaska, and I’ve been working as a software engineer (mostly Java + a bit Kotlin) for over 8 years now. I mostly spend my time building backend services, integrating systems, fixing bugs (the fun part 🙃), and making sure things don’t fall apart behind the scenes.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.