Home Resources Firewall sizing TLS inspection
SSL and TLS inspection: what it costs and what it breaks
A firewall that does not decrypt is inspecting a small share of what passes through it. A firewall that does decrypt costs more, breaks things, and creates a legal question the customer has to answer. This page covers all three, in the order the project runs into them.
The short answer
Decryption is the largest single variable in firewall sizing. Size for it at purchase even where the customer plans to enable it later, because retrofitting it is the most common reason an appliance is replaced before its subscriptions expire.
Interception breaks a predictable set of traffic. Certificate pinning, mutual TLS and applications carrying their own certificate store all fail by design rather than by fault, and each one needs a documented exemption.
Every exemption is traffic passing uninspected. Track the exempted share as a number and report it, because an inspection policy with an unmeasured exemption list is a control nobody can size.
Whether the customer may decrypt is a legal question rather than a technical one. Raise it in writing before the project starts, and let the customer's own advisers answer it.
Why it is not optional
Most traffic on a modern network is encrypted, and a firewall that does not decrypt cannot see inside any of it.
That has a consequence worth stating plainly to a customer. Intrusion prevention, antivirus scanning, data loss prevention and content-aware application policy all operate on the contents of a session. Without decryption, those subscriptions are active, licensed and applied to the minority of traffic that arrives in the clear.
The customer is therefore paying for a set of controls whose coverage is determined by the decryption policy rather than by the licenses. That is the sentence to put in the design document, because it converts decryption from a performance discussion into a value discussion, and the value discussion is the one that gets it approved.
Two consequences follow for an MSP. Inspection subscriptions sold without a decryption plan may deliver less than the customer believes they bought. And a security review eighteen months after the appliance was sized frequently produces a decryption requirement the appliance cannot carry.
What decryption costs
Decryption costs more than any other inspection function, and the reason is structural.
Inspecting an encrypted session requires the firewall to act as an intermediary between the client and the server. It terminates the client's session, establishes its own session to the server, performs the cryptographic work for both, presents a certificate it has generated to the client, and then performs all the inspection it would have performed on a plaintext session anyway. The cryptographic work is additional rather than substitutive.
Four properties change how expensive that is for a given customer.
- The share of traffic decrypted. A policy that decrypts everything except a short exemption list costs more than one that decrypts a named set of categories.
- Cipher suites and key exchange in use. Different suites impose different costs per session, and the session establishment cost is larger than the per-byte cost.
- Session churn. The expensive part of decryption is establishing the session. A network of many short sessions pays that cost repeatedly.
- What runs after decryption. Decryption exposes the content, and then the content is scanned. The second half of the cost is the inspection, not the cryptography.
Where a vendor publishes a decryption throughput figure, it is measured under its own conditions and belongs in the sizing model as a separate input. Where a vendor publishes none, the cost is still there, and the absence of a figure is a question for the reseller. The throughput reference page covers how to read those figures, and the sizing page covers where this input sits in the model.
The mechanism described here is the standard operation of a TLS inspection proxy and is documented by every vendor implementing it. We publish no percentage for the performance cost, because it varies by cipher suite, session profile and platform, and a single figure repeated in a customer meeting would be a guess. Read the decryption figure on the datasheet for the model being quoted. Checked 12 August 2026.
Eight things that break
Interception breaks a predictable set of traffic, and none of it is a fault in the firewall.
Each of these is a client correctly refusing a certificate it was not expecting. Knowing the list in advance turns a rollout from a series of incidents into a series of planned exemptions.
| What breaks | Why | Usual handling |
|---|---|---|
| Certificate pinning | The application accepts only a specific certificate or issuer, by design | Exempt by destination. There is no configuration that makes this work. |
| Mutual TLS | The client presents its own certificate, which an intermediary cannot forward | Exempt. Common in banking, EDI and machine-to-machine integrations. |
| Independent certificate stores | The application trusts its own bundle rather than the operating system store | Inject the inspection certificate into that store where possible, exempt where not |
| Software update agents | Updaters verify publisher signatures and frequently pin | Exempt the vendor update domains, and keep the list current |
| Unmanaged and guest devices | They never received the inspection certificate | Separate policy for the guest network, usually without inspection |
| Embedded, medical and industrial devices | Fixed trust stores that cannot be updated, and support terms that forbid changes | Exempt, and segment instead of inspecting |
| Nested VPN clients | A tunnel inside the inspected session cannot be read, and interception may break the tunnel | Exempt the tunnel endpoints, and decide separately whether to permit them |
| QUIC traffic | Many inspection implementations do not decrypt it | Commonly blocked at UDP 443 so clients fall back to TCP, which is inspectable |
These failure modes follow from how TLS interception works and from the certificate validation behaviour of the clients concerned. They apply on every platform implementing inspection rather than to any one vendor. The list is drawn from the exemptions we maintain across the estates we run, and it is our operating experience rather than a vendor statement.
From the operations side
The ticket that arrives on the Monday after a rollout is rarely a browser. Browsers fail visibly, with a certificate warning a user can describe. The tickets that consume a week are the silent ones: a backup agent that stops completing, a payment terminal that reports a generic network error, a line-of-business client that hangs on launch with no message at all. None of them mention certificates. Before enabling enforcement, get a written list of every application that talks to something outside the network, and treat anything nobody can name as a reason to keep the policy in monitoring mode for another week.
Exemptions are a measurement
An exemption list is a record of traffic the customer is paying to inspect and is not inspecting.
Every rollout produces one, and the list grows fastest in the weeks when pressure to resolve tickets is highest. That combination is how an inspection policy designed to cover most traffic ends up covering considerably less, without anybody making a decision to reduce it.
Three practices keep this visible.
Record the traffic share alongside each entry. An exemption is not one line among thirty. It is a percentage of sessions and a percentage of bytes. Two entries may account for more uninspected traffic than the other twenty-eight combined.
Give each exemption an owner and a review date. Exemptions added during an incident are provisional by nature and permanent by default. A review date converts the provisional ones back into decisions.
Report the inspected percentage to the customer. A customer buying inspection is entitled to know what proportion of their traffic is inspected, and the number is more useful to them than any other metric the service produces. It also makes the case for the next appliance, because rising coverage means rising load.
Where an exemption exists because inspection would break the traffic, the remaining control is placement rather than inspection. Traffic that cannot be inspected can still be segmented, restricted by destination, and logged. Recording which compensating control applies to each exemption turns the list into a design artifact rather than a backlog.
TLS 1.3, ECH and QUIC
Three protocol developments are reducing what a firewall can determine without decrypting.
The direction of travel is consistent. Each of them moves information that was previously observable into the encrypted part of the exchange, which increases the share of traffic that has to be decrypted to achieve the same visibility.
TLS 1.3 encrypts the certificate
In TLS 1.3, the server certificate is exchanged after the handshake has been secured, so a passive observer no longer sees it. Policy that previously worked from the certificate subject now requires decryption. The server name in the client hello remains readable, which is why so much current policy depends on it.
Encrypted Client Hello removes the server name
Encrypted Client Hello conceals the server name in the initial handshake, which is the last widely used field a firewall can read without decrypting. Where it is deployed, category and destination policy that depends on the server name stops working, and the choices reduce to decrypting the session or deciding on address alone.
QUIC moves the problem to UDP
QUIC carries HTTP over UDP with more of the connection setup encrypted than TLS over TCP exposes. Inspection support varies by platform and by release. The common operational response is to block UDP port 443 so clients fall back to TCP, which is inspectable, and that response has a cost in performance for the applications designed around QUIC. Decide it deliberately rather than discovering it as a default.
TLS 1.3 is defined in RFC 8446 and QUIC in RFC 9000, with its use of TLS in RFC 9001. Encrypted Client Hello is specified in the IETF draft draft-ietf-tls-esni, which stood at revision 25 and had not been published as an RFC when we checked on 12 August 2026. Support for each of these in a given firewall release is a vendor question and changes between releases, so confirm it against the platform being quoted rather than against this page.
The question that is not technical
Whether a customer may decrypt their users' traffic is a legal question, and it is one an MSP should raise rather than answer.
Decryption gives the operator of the firewall access to the contents of communications that the people involved believe to be private. The rules governing that vary by jurisdiction, by the employment relationship, and by what the customer has told the people concerned.
Four points belong in the design conversation.
- Notice. Inspecting employee traffic generally requires that employees have been told, usually through an acceptable use policy that specifically mentions interception rather than monitoring in general terms.
- Consultation. In some jurisdictions, workplace monitoring requires consultation with a works council, union or equivalent body before it begins.
- Category exemptions. Health, financial, legal and government categories are commonly exempted from decryption for reasons that have nothing to do with whether they break technically. Most platforms support category-based exemption for exactly this purpose.
- Where the decrypted content goes. Logging, sandboxing and data loss prevention may retain content or send it to a vendor cloud. That is a separate disclosure from the interception itself.
The MSP's obligation here is procedural rather than advisory. Raise the four points in writing before the project starts, record the customer's answer, and configure to it. An MSP that configured decryption without asking has taken on a position it has no basis to defend.
This section describes considerations to raise rather than legal advice, and Bonsai Security gives none. Requirements differ by jurisdiction and by employment arrangement. Direct the customer to their own legal advisers, and keep their written instruction on file.
A rollout order that works
Enable inspection in stages, with enforcement last.
The failure mode is well established. Inspection is enabled estate-wide in a single change window, the helpdesk receives more tickets in a morning than it handles in a week, and the change is rolled back under pressure. The rollback is usually correct and the project rarely recovers its credibility.
- Distribute the certificate and confirm it. Push the inspection certificate to every managed device through the existing management tooling, then verify presence on a sample rather than assuming deployment succeeded. Devices outside management are the exemption list's first entries.
- Run in monitoring mode. Most platforms can log what inspection would do without enforcing it. Run that for a full business cycle, including a month end, and build the exemption list from observed traffic rather than from a template.
- Apply the known exemptions. Take the eight classes above, add whatever the monitoring period surfaced, and document the compensating control for each.
- Enforce for a pilot group. Choose one that is technically literate and reachable, and tell them what is happening and what to report. A pilot group that knows it is a pilot group produces better information than a larger one that does not.
- Widen by group, with a rollback ready per group. The ability to remove one group from enforcement without reverting the whole policy is what keeps the project moving after the first bad day.
- Re-measure capacity. Inspection load rises with each group added. Confirm the appliance is inside its limits at each stage rather than at the end.
Budget helpdesk capacity for each stage explicitly. The tickets are a known cost of the project rather than a sign that it is going badly, and an MSP that scheduled for them absorbs them without the customer losing confidence.
The month after inspection goes on
Decryption rollouts generate their tickets at hours nobody planned for, and each one looks like an application fault until somebody checks the exemption list. We run firewalls that MSPs have already sold, under their brand, on eight platforms, from $29 per firewall per month. The exemption list, the coverage number and the 2am ticket are ours.
Get your rateCommon questions
What customers ask when decryption reaches the design document. Something missing? Tell us and we will add it.
How much does SSL inspection reduce firewall performance?
The reduction is large on every platform, and the size of it depends on the cipher suites in use, the share of traffic decrypted, and how much inspection runs after decryption. Rather than applying a rule of thumb, size against the vendor's own decryption figure where one is published, read the conditions in its footnote, and treat a missing figure as a question for the reseller rather than as evidence the cost is small. Decryption is the single largest variable in most sizing models and it is the most common reason an appliance is replaced before its subscriptions expire.
What breaks when you enable TLS inspection?
Eight classes of traffic fail predictably. Applications using certificate pinning reject the firewall's certificate by design. Mutual TLS fails because the client certificate cannot be presented through an intermediary. Anything with its own certificate store rather than the operating system store will not trust the inspection certificate, which covers many developer tools, Java applications and update agents. Software updaters, embedded and medical devices, some VPN clients inside the tunnel, and QUIC traffic all commonly fail. Each needs an exemption, and every exemption reduces the share of traffic actually being inspected.
Does TLS 1.3 prevent inspection?
It does not prevent interception, and it removes some of what a firewall could previously see without decrypting. TLS 1.3 encrypts the certificate exchange, so the server certificate is no longer visible to a passive observer. The server name in the client hello remains readable unless Encrypted Client Hello is in use. The practical effect is that policy decisions which used to be possible from passive observation now require full decryption, which increases the amount of traffic an inspection policy has to decrypt to achieve the same visibility.
Should exemptions be treated as a security problem?
They should be treated as a measured quantity rather than as a list. Every exemption is traffic passing uninspected, and an exemption list that grows during rollout can reduce inspection coverage to a fraction of what the design assumed. Record the share of total traffic each exemption covers, review the list on a schedule, and report the resulting inspected percentage to the customer. A customer paying for inspection is entitled to know what proportion of their traffic is actually inspected.
Is TLS inspection legal?
It depends on jurisdiction, on the employment relationship, and on what the customer has told the people whose traffic is being decrypted. Inspecting employee traffic generally requires notice, and in some jurisdictions consultation with a works council or equivalent body. Categories such as health, financial and legal traffic are frequently exempted for reasons unrelated to whether they break technically. This is a question for the customer's own legal advice rather than for their MSP, and the MSP's obligation is to raise it in writing before rollout rather than to answer it.
How should TLS inspection be rolled out?
In stages, with the certificate distributed first and inspection enabled last. Deploy the inspection certificate to every managed device and confirm it, then run the policy in a monitoring or log-only mode to build the exemption list from real traffic, then enable enforcement for one pilot group, then widen it by group rather than all at once. Enabling inspection estate-wide in a single change generates a volume of tickets that the helpdesk cannot absorb, and the usual outcome is an emergency rollback that costs the project its credibility.