Most engineers think…
Most people assume 'the firewall already protects us, so HTTPS is fine'. In reality, if the firewall can't decrypt, the encrypted traffic is a black box — and that's exactly where modern malware, command-and-control and data theft hide.
Sophos Firewall Xstream TLS inspection is the engine that fixes that blind spot. It decrypts traffic — natively for TLS 1.3, with no downgrade to 1.2 — using a separate top-down rule table and decryption profiles, then scans the clear stream once for IPS, anti-malware, web filtering and app control. The catch is that the firewall becomes a man-in-the-middle that re-signs certificates with its own CA, so you must deploy that CA to clients and keep an exclusion list — otherwise you trade a blind spot for a wall of certificate errors and broken apps.
① Why decrypt at all — the encrypted blind spot
The starting fact: almost all web traffic today is encrypted with TLS (HTTPS). That's great for privacy, but it means a firewall that can't decrypt only ever sees scrambled bytes. Your IPS, anti-malware and web filtering have nothing to read, so threats hidden inside HTTPS sail straight through.
Attackers know this. Malware downloads, command-and-control callbacks and data theft increasingly ride inside encrypted connections precisely because most firewalls are blind to them. So the choice is stark: either inspect the encrypted traffic, or accept that a large share of your traffic is unprotected.
That's the job of Sophos Firewall Xstream TLS inspection — it opens the encrypted stream, lets the security engines scan the clear contents, then re-encrypts it on its way to the server. The rest of this lesson is how to do that at speed, and how to do it without breaking things.
Why is an HTTPS-blind firewall a security problem?
② The Xstream TLS engine — native 1.3 and a separate rule table
Xstream TLS inspection is Sophos Firewall's high-performance decryption engine. Two things make it modern. First, it inspects TLS 1.3 natively — it does not downgrade a TLS 1.3 connection to TLS 1.2 just to read it. Second, it rides the Xstream architecture and FastPath, which can offload trusted flows so throughput stays high instead of collapsing the moment you turn decryption on.
A separate, top-down rule table
Decryption isn't a single on/off switch. TLS inspection rules live in their own rule table — much like NAT rules are separate from firewall rules — and they're evaluated top-down, first match wins. Each rule matches on source, destination, zones and users and on websites or web categories, then sets an action (Decrypt or Don't decrypt) and points to a decryption profile.
The interview line: TLS inspection is rule-driven, not global. You decrypt this traffic for these users to these sites — and explicitly leave the rest alone.
Sophos Firewall's high-performance decryption engine. Inspects TLS 1.3 natively (no downgrade) and uses FastPath to keep throughput high.
A separate, top-down, first-match table (like NAT rules). Each rule matches who / where / what and sets an action plus a decryption profile.
The 'how' on a rule: minimum TLS version, re-sign vs known-key, what to do on errors and invalid certs, and exclusions.
The internal CA the firewall uses to re-sign server certs. Clients must trust it — deploy it via GPO or MDM or browsers warn.
In an interview, say it cleanly: TLS inspection rules are a separate, top-down, first-match table — like NAT rules — not a global on/off switch. Each rule pairs a match (source, dest, zones, users, websites) with an action (Decrypt / Don't decrypt) and a decryption profile.
How does Xstream TLS inspection handle TLS 1.3?
③ Decryption profiles and the certificate (re-sign) model
A decryption profile is the 'how' attached to each rule. It sets the minimum TLS version allowed, the re-sign approach, what to do on errors or unsupported sites (block or allow), how to handle invalid or untrusted server certificates, and the exclusions. Choosing 'block on error' is safer; 'allow on error' is friendlier but leaves gaps.
How the firewall reads the traffic
To see inside, the firewall acts as a man-in-the-middle: it re-signs the real server's certificate on the fly with its own internal CA. That means clients must trust that CA — you push the firewall's CA certificate to client trust stores via GPO (Active Directory) or MDM. Skip this and every browser throws a certificate warning. For your own internal servers you can use the real certificate and key (known key / server protection) instead of re-signing.
The payoff is 'decrypt once, scan many': once a flow is decrypted, a single streaming DPI engine inspects the clear stream in one pass for IPS, anti-malware, web filtering and application control — it doesn't decrypt separately for each engine.
The number-one self-inflicted outage: enable broad decryption while the firewall CA is still missing from clients. Every HTTPS site then throws a certificate warning. Always deploy the CA to client trust stores (GPO/MDM) before you widen the decrypt scope.
▶ Watch an HTTPS site get inspected end-to-end
How a single HTTPS request is decrypted, scanned and re-encrypted. Press Play for the healthy path, then Break it to see the classic failure.
After you enable decryption, why do browsers suddenly show certificate warnings?
④ Doing it without breaking things — exclusions & rollout
Decryption breaks things if you're careless, so exclusions are essential. Sites like banking, healthcare, government, software-update services and anything using certificate pinning belong on the 'Do not decrypt' list. There are two reasons: privacy and compliance (you shouldn't be reading a user's bank or medical session) and breakage — a certificate-pinned app rejects the firewall's re-signed cert and simply stops working.
A safe, staged rollout
Don't flip 'Decrypt all' on day one. The pattern that works: start with a narrow decrypt scope (a pilot group or a few categories), deploy the firewall CA to clients first, keep a maintained exclusion list, monitor TLS errors in the logs, then widen gradually. The classic failure is turning on broad decryption before the CA is pushed — instant helpdesk storm of certificate warnings.
Priya at Sundar Logistics in Kochi faces this
The day after she switches on a broad 'Decrypt all web traffic' rule, the helpdesk is flooded: every browser shows 'Your connection is not private', and the accounts team's banking portal and a vendor's auto-updater have stopped working.
The firewall is re-signing every site with its own CA, but that CA was never pushed to the client machines — and certificate-pinned sites break even when users click through.
Rules and policies ▸ TLS inspection rules shows one broad Decrypt rule with re-sign; the certificate warnings point to clients missing the CA, and the pinned-site failures appear in the TLS / decryption logs as handshake errors.
Rules and policies ▸ TLS inspection rules + decryption profile ▸ exclusions; Certificates ▸ CAPush the firewall's CA certificate to all clients via GPO/MDM; narrow the decrypt scope to a pilot group; add banking, healthcare, government, software-update and pinned sites to the 'Do not decrypt' exclusion list.
Pilot browsers show a clean padlock with no warning, the banking portal and updater work again, and the TLS logs show those sites passing through un-decrypted while general web traffic is inspected.
Don't guess whether a site is decrypting. The TLS / decryption logs show, per connection, whether it was decrypted or excluded and any handshake error. That single read tells you if a broken app is hitting pinning or just missing the CA.
A vendor's auto-updater stops working the moment you decrypt its traffic. The most likely cause is…
🤖 Ask the AI Tutor
Tap any question — instant, scoped to this lesson. No login, no waiting.
Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.
📝 Wrap-up assessment — six more
You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.
🧠 In your own words
Type one line: why does turning on Sophos TLS inspection sometimes flood the helpdesk with certificate warnings, and what's the fix? Then compare with the expert version.
🗣 Teach a friend
Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.
📖 Glossary
- Xstream TLS inspection
- Sophos Firewall's high-performance decryption engine that opens HTTPS so the security engines can scan the clear traffic, then re-encrypts it.
- TLS 1.3 native inspection
- Inspecting the modern TLS 1.3 protocol directly, without downgrading the connection to TLS 1.2 to read it.
- TLS inspection rule table
- A separate, top-down, first-match table of rules that decide whether a connection is decrypted, each with an action and a decryption profile.
- Decryption profile
- Settings on a rule: minimum TLS version, re-sign vs known-key, error and invalid-cert handling, and exclusions.
- Re-sign (man-in-the-middle)
- The firewall presents a copy of the server's certificate signed by its own CA so it can read and re-encrypt the traffic.
- Firewall CA
- The internal certificate authority the firewall uses to re-sign certs; clients must trust it (push via GPO/MDM) to avoid warnings.
- Known key / server protection
- Using an internal server's real certificate and private key instead of re-signing, so inbound inspection works without warnings.
- Certificate pinning
- An app that accepts only one specific certificate; a re-signed cert is rejected, so pinned apps must be excluded from decryption.
- TLS exclusion list ('Do not decrypt')
- Sites bypassed from decryption for privacy/compliance or to prevent breakage — banking, healthcare, government, updates and pinned apps.
📚 Sources
- Sophos Firewall — Xstream TLS inspection overview and configuration. docs.sophos.com
- Sophos Firewall — TLS inspection rules: a separate, top-down rule table. docs.sophos.com
- Sophos Firewall — Decryption profiles (TLS version, re-sign / known key, error handling, exclusions). docs.sophos.com
- Sophos Firewall — Deploy the firewall certificate authority to endpoints via GPO / MDM. docs.sophos.com
- Sophos — Xstream architecture & native TLS 1.3 inspection performance. sophos.com
- Sophos Community — TLS inspection exclusions and certificate pinning best practice. community.sophos.com
What's next?
Now the firewall can see inside HTTPS — next, go deep on what it does with that visibility: IPS signatures, Advanced Threat Protection and Zero-Day Protection sandboxing that detonates unknown files before they reach a user.