Should Your Corporate Internet Gateway Decrypt TLS Traffic?

The exemption list lives in a spreadsheet that has not been reviewed since the last gateway refresh. It is the actual decryption policy.

The mandate to enable TLS inspection at the corporate gateway usually starts with a security requirement: malware delivery and data exfiltration hide inside HTTPS, so the gateway must see the payload. The project quickly devolves into an administrative trap. Managing what not to decrypt takes more engineering hours than analyzing the plaintext. You are trading end-to-end encryption for end-to-middle-to-end encryption, and the gateway becomes the most valuable data repository in the company.

Before deciding what the gateway should decrypt, check what the endpoint already sees.

The Endpoint Shift

EDR agents, enterprise browsers, and OS-level proxies inspect data in memory before it hits the network stack and undergoes TLS encapsulation. If the endpoint already sees the plaintext, the gateway is a second opinion.

The gateway earns its keep on the devices you cannot manage. For contractors on the guest Wi-Fi, unmanaged BYOD phones, OT networks, and IoT sensors, the gateway is often the only vantage point you have. If you cannot push an agent to it, you must intercept it at the network boundary.

For managed corporate laptops with active EDR, the gateway’s value drops. It is still useful for catching lateral traffic, identifying exfiltration by authorized users, and scanning downloads from unmanaged browsers. But for standard malware delivery to a managed endpoint, the endpoint is the first line of defense.

The Protocol Ceiling

The internet engineering community is actively designing protocols to break middlebox inspection. The decision is not whether to decrypt traffic forever; it is what fraction of traffic you can decrypt today, what it costs in compute, and what you will build for the day the inspection ceiling drops further.

TLS 1.3 increases the handshake cost per session compared to TLS 1.2. Encrypted Client Hello (ECH) hides the Server Name Indication (SNI) during the handshake. If the gateway cannot read the SNI, it cannot check its category-based bypass list. It either blocks the connection or blindly intercepts it, hoping it is not a local banking portal.

QUIC and HTTP/3 run over UDP 443. Most gateways cannot inspect QUIC traffic. The default behavior in many organizations is to silently block UDP 443 to force a TCP fallback. That decision has a user-visible performance cost. If you cannot inspect QUIC, you must decide deliberately whether to block it, allow it as a visibility gap, or replace the gateway hardware with a model that supports it.

Size the gateway hardware for peak concurrent TLS sessions and handshake rates, not for bandwidth. Decryption is math-heavy and cuts advertised throughput by 50 to 70 percent. A gateway sized for average utilization will peg its CPU and drop packets during a major OS update release.

Pinning and Application Breakage

Certificate pinning is a vendor telling you they do not trust your gateway. They are right not to.

Mobile apps, package managers like npm and pip, IoT firmware updaters, and some enterprise clients hardcode expected certificate hashes. They bypass the operating system trust store entirely. When the gateway intercepts the traffic and presents its dynamically generated certificate, the client detects the mismatch and severs the connection.

The breakage lands on the network team. The exemption lands on nobody.

Do not treat pinning as a nuisance to route around with a wildcard bypass. Treat it as a design constraint. If a critical business application pins its certificates, the choices are an application change, a narrow SNI bypass, or blocking the application. If the bypass request process takes three days, developers will route around the gateway entirely. Mutual TLS (mTLS) presents a similar constraint; if the gateway terminates the client side and the server expects the original client certificate, the connection will fail.

Scoping the Inspection

Deciding which traffic to decrypt, which to bypass, and which to block requires separating security requirements from privacy liabilities and operational constraints.

• Name the control first. If no security control, such as Data Loss Prevention (DLP) or malware scanning, acts on the decrypted plaintext, do not collect the plaintext by default. Decryption is a visibility tool. It is also a liability surface. The two are the same number.
• Default to bypass for specific categories. Instead of decrypting everything and exempting what breaks, reverse the logic. Decrypt uncategorized sites, known high-risk categories, and newly registered domains. Let trusted SaaS, CDNs, and known good traffic pass untouched.
• Legal and HR decide the privacy carve-outs. Banking, health, and personal webmail are not exceptions to be added when a help desk ticket is filed. They are requirements that shape the design. Network engineering does not own the liability for reading an employee’s medical data or personal banking transactions. Legal must approve the bypass categories before the pilot starts. Works councils and regional privacy laws dictate what is permissible on managed devices.
• Treat the exemption list as production configuration. Every bypass needs a named owner, a date, a reason, and a review date. When an internal auditor asks who approved the financial institution exemption, a blank spreadsheet row is not an answer. A bypass is a security decision, not a troubleshooting note.
• Handle failure deliberately. Decide what happens when inspection fails or capacity is reached. A fail-open setting is also an inspection policy; it just activates when the equipment is under stress. Determine whether the gateway should block, bypass, or route the traffic through another control, and test that behavior for each traffic class.

Key Custody and Liability

To make TLS inspection work on managed devices, IT must deploy a custom Root CA to the trust store of every endpoint via GPO or MDM. The gateway uses the corresponding private key to sign leaf certificates that impersonate external sites.

The enterprise CA private key is the most consequential secret on the network. If it is compromised, an attacker can silently impersonate any website to every employee, intercepting passwords, session tokens, and proprietary documents without triggering a browser warning.

Decide the CA custody model before the first pilot. The root CA must be offline. The issuing CA must be backed by a Hardware Security Module (HSM). The issuance path must be documented and restricted. If you cannot describe exactly how a subordinate certificate gets issued, rotated, and revoked, you are not ready to turn on inspection. Distributing that trust broadly increases the consequences of CA compromise. Limit the deployment of the inspection CA only to the devices in the inspection program.

The gateway will always see the destination metadata, but the decision to see the payload belongs to the business, not the network team.