Implementing Sophos Firewall TLS Inspection Correctly

A large portion of today’s web traffic is encrypted. Without TLS Inspection, the firewall often only sees the destination IP, SNI, certificate information, and metadata, but not the actual content of the connection.

This is a security issue: many protection functions cannot or can only very limitedly check encrypted payloads. Malware scanning, web protection, zero-day analysis, content scanning, and parts of application or threat detection only become truly effective when the firewall can decrypt, inspect, and then re-encrypt TLS traffic. IPS and NDR also benefit from more plaintext visibility. Without decryption, many signals remain limited to metadata, certificates, IPs, domains, or protocol information.

However, TLS Inspection is not a feature that should be activated unprepared for all users. It can disrupt applications, raise privacy concerns, and increase the firewall’s load. Therefore, TLS Inspection should be introduced in a planned, gradual manner with a clear exception strategy.

Orientation

Start by deciding which protection or configuration method fits the actual use case. This avoids broad rules and duplicated troubleshooting later.

License and Requirements

For TLS Inspection and the meaningful evaluation of decrypted traffic, the appropriate protection licenses are required.

The most important are:

• Web Protection: Includes Web Security, Web Control, Application Control, and Web Malware Protection.
• Network Protection: Includes IPS, Security Heartbeat, and other network protection functions.
• Zero-Day Protection: Becomes important when files or downloads need to be additionally analyzed using machine learning or sandboxing.

Web Protection is included in the Standard Protection license bundle. Xstream Protection and Epic Protection also include Web Protection and other protection modules. For the classification of bundles, see What Sophos Firewall Bundles Are Available?; for Base License, support status, and subscriptions, see Understanding Sophos Firewall Base License.

Before rollout, you should check:

• Current Sophos Firewall firmware is installed.
• Web Protection is licensed.
• The firewall’s CA certificate is distributed to clients.
• A test group or test network is defined.
• Rollback is documented.
• Exception process is clarified.
• Logging is activated.

If the CA certificate has not yet been distributed, the article Install Sophos Firewall CA Certificate for HTTPS Scanning can help.

⚠️ TLS Inspection can disrupt applications that use certificate pinning or conduct their own certificate checks. The rollout should always start with a test group and not directly with all users.

DPI or Web Proxy?

Sophos Firewall can implement HTTPS decryption in two modes:

• DPI Mode: The firewall rule uses the DPI engine. SSL/TLS Inspection Rules under Rules and policies > SSL/TLS inspection rules decide what is decrypted.
• Web Proxy Mode: The firewall rule uses the Web Proxy. HTTPS decryption is then controlled via the web proxy settings and web policies.

For modern setups, DPI Mode is often used. The firewall rule is important here:

1. Open Rules and policies > Firewall rules.
2. Edit the affected LAN-to-WAN rule.
3. Open Security features > Web filtering.
4. Activate the appropriate web policy.
5. Activate Scan HTTP and decrypted HTTPS.
6. Leave Use web proxy instead of DPI engine deactivated if the SSL/TLS Inspection Rules should apply.

If Use web proxy instead of DPI engine is activated, web traffic runs through the Web Proxy. Then different decryption settings apply for HTTP/HTTPS than with DPI-based SSL/TLS Inspection Rules. Before rollout, it should be clear whether the environment uses Web Proxy or DPI, otherwise exceptions will be searched for in the wrong place later.

Which Traffic Should Be Decrypted?

You should not blindly decrypt everything. Good TLS Inspection starts with clear goals.

Sensible initial targets:

• LAN > WAN: classic user web traffic to the internet.
• Wi-Fi > WAN: managed clients in the company WLAN.
• VPN > WAN: remote access users when their internet traffic runs through the firewall.
• LAN > DMZ: internal access to own servers when security checks are desired there and certificates are properly distributed.

Handle with caution:

• Banking, health, government, and highly sensitive portals.
• Password managers and identity providers.
• Operating system and manufacturer update services.
• Mobile apps and Android devices.
• Applications with certificate pinning.
• Voice, video, and collaboration services if they become unstable due to decryption.

For server publications from the internet into the DMZ, TLS Inspection is not automatically the best solution. For web servers, Web Server Protection / WAF or a reverse proxy is often more sensible.

Consider QUIC and Web Policy

If web traffic is not inspected as expected despite TLS Inspection, you should also check QUIC or HTTP/3. Many browsers can establish HTTPS connections over UDP 443. Depending on the rule and web policy design, the traffic may not run through the expected classic HTTPS path over TCP 443.

In client internet rules, you should consciously check:

• Is the appropriate web policy active?
• Is Block QUIC protocol active in the actually matching firewall rule?
• Is Scan HTTP and decrypted HTTPS set according to the decryption strategy?
• Does the rule use DPI or Web Proxy?
• Do you see UDP 443, TCP 443, web policy events, and SSL/TLS inspection events consistently in the Log Viewer?

The procedure for blocking QUIC is described in Correctly Blocking QUIC and HTTP/3 on Sophos Firewall. For the web policy itself, see Creating a Sophos Firewall Web Protection Policy.

Plan Rollout

TLS Inspection should be introduced gradually so that exceptions, client certificates and support cases remain manageable.

Rollout Strategy

A phased approach has proven effective:

1. Distribute CA certificate.
2. Prepare web policy and firewall rule.
3. Select decryption profile.
4. Define a small test group.
5. Activate SSL/TLS Inspection Rule only for this group.
6. Monitor Control Center and Log Viewer.
7. Analyze errors and document exceptions clearly.
8. Gradually expand to other user groups.

This way, you can identify early which applications cause problems without affecting the entire operation.

Plan Rollout Phases

A TLS Inspection rollout should be planned in phases. This keeps it manageable and allows you to separate technical errors from acceptance or application problems.

• Preparation: CA, web policy, firewall rule, and test group are ready. CA distribution, license, logging, rollback.
• Pilot: a few managed clients test productive everyday life. Log Viewer, Dashboard Widget, user feedback.
• Expansion: include more user groups or networks. Document exceptions, monitor performance.
• Operation: TLS Inspection is regularly reviewed. Review of exclusions, reports, errors, and new applications.

It is important that each phase has a clear exit point. If a business-critical application breaks during the pilot, a broad global exception should not be set immediately. A clean analysis is better: which domain, which client, which rule, which decryption profile, and which error in the Log Viewer are affected?

Define Pilot, Owner, and Exception Process

Before the first productive rollout, it should be clear who manages the test group, who approves exceptions, and how errors are reported back. Otherwise, TLS Inspection quickly generates unordered exceptions: individual domains are hastily set to Don't decrypt without it being clear later why the exception exists.

For operation, these points should be documented:

• Pilot group, affected networks, and timeframe.
• Owner for web policy, decryption profile, and SSL/TLS Inspection Rules.
• Process for new exceptions with reason, ticket, and review date.
• Criteria for when an application is exempted and when the cause is checked first.
• Place where Log Viewer, Dashboard Widget, and user feedback are collected.
• Rollback if business-critical applications are disrupted.

Particularly important is the separation between technical exception and permanent security decision. A temporary exception can be sensible to get a service working again. However, this exception should be reassessed later once the cause, risk, and alternative are clear.

Test Rollback Before Rollout

A rollback should not be invented only during an outage. Before the pilot, it should be clear how TLS Inspection can be removed from the test group without confusing other rules, Web Policies or exceptions.

Practical rollback check:

• Remove test group: check that the SSL/TLS Inspection Rule no longer matches the pilot client.
• Disable rule: verify that traffic again uses the expected non-decryption path.
• Test exception: a targeted Don't decrypt rule must be above the general decrypt rule and visibly match in Log Viewer.
• Keep Web Policy: rolling back decryption must not accidentally remove web filtering, malware scanning or logging completely.
• Document evidence: record test client, target domain, rule name, log event and time.

This test is especially important when several admins work on Web Policies, firewall rules and SSL/TLS Inspection Rules. A clean rollback only removes the affected scope and does not make the whole Web Protection chain blind.

Configuration

The configuration should be narrow, testable and easy to review later.

Understanding Decryption Profiles

A Decryption Profile determines how strictly the firewall handles TLS connections. The profiles can be found under Profiles > Decryption profiles.

A decryption profile answers, among other things, these questions:

• What happens with invalid or untrusted certificates?
• Are old TLS versions blocked?
• Are insecure cipher suites blocked?
• What happens with SSL compression?
• What happens with unrecognized cipher suites?
• What happens if the firewall cannot decrypt a connection?
• Which CA is used for re-signing?

For an initial rollout, a more compatible profile is sensible, such as Maximum compatibility or a custom conservative profile. For productive security rules, a stricter profile like Block insecure SSL can be used later.

Important: The decryption profile is selected directly in the SSL/TLS Inspection Rule. The profile can override the global SSL/TLS inspection settings for this rule. Therefore, when troubleshooting, you should always check the specific rule and not just the global settings.

Creating an SSL/TLS Inspection Rule

The menu path is Rules and policies > SSL/TLS inspection rules.

An initial rule should be as targeted as possible:

• Action: Decrypt
• Decryption profile: conservative test profile
• Source zones: LAN or test network
• Source networks and devices: test group or test subnet
• Destination zones: usually WAN
• Destination networks: initially Any
• Services: often Any to start, as SSL/TLS can also be recognized on other TCP ports
• Websites / Categories: optionally restrict

SSL/TLS Inspection Rules can recognize TLS connections outside the classic HTTPS port. The rules are processed from top to bottom. Specific exceptions and pilot rules should therefore be above general decrypt rules, otherwise, it will be difficult to understand later why a connection was decrypted or exempted.

Exclusion Lists

Not all TLS traffic should be decrypted. Sophos uses exclusion rules and TLS Exclusion Lists for this.

Local TLS Exclusion List

The Local TLS exclusion list is the firewall’s local exclusion list. This list is empty by default and can be filled through troubleshooting in the Control Center or Log Viewer.

You can also edit it manually:

Web > URL groups > Local TLS exclusion list

This list is useful for domains that cause problems in your environment, for example, due to certificate pinning or special client applications.

Managed TLS Exclusion List

The Managed TLS exclusion list contains exceptions maintained by Sophos for known problematic services. This list is updated through firmware updates.

Typical examples are services where TLS Inspection is known to cause problems or is technically not sensible.

Custom Exclusion Rules

Additionally, you can create your own SSL/TLS Inspection Rules with Action > Don’t decrypt. These should be directly below the default exclusion rule and only contain traffic that really should not be decrypted.

Possible criteria:

• Web categories
• URL groups
• Users and groups
• Source and destination networks
• IP addresses
• Services

Exceptions should be documented: domain, reason, affected users, date, and review date.

Monitoring and Evaluation

After activation, the dashboard and Log Viewer show whether traffic is actually decrypted or excluded.

Monitoring the Dashboard Widget

In the Control Center, there is a widget for SSL/TLS Inspection. This widget is very helpful for monitoring rollout and errors.

It shows, among other things:

• Percentage of decrypted SSL/TLS sessions.
• Percentage of non-decrypted SSL/TLS sessions.
• Other traffic.
• Errors from the last few days.
• Top websites or top users with problems.
• Decryption peak and decryption limit.

If many errors appear in the widget, you should not immediately disable all TLS Inspection. It is better to use Fix errors to specifically check the affected targets and create clean exceptions if necessary.

Evaluating the Log Viewer

In the Log Viewer, you can select the SSL/TLS inspection filter. There you can see what happened with individual connections.

The colours help with the initial assessment:

• Red: Error. The connection could not be correctly decrypted or processed. Here you should check certificate errors, cipher suites, TLS versions, or incompatible applications.
• Green: Do not decrypt. The connection was deliberately not decrypted, for example, due to an exclusion rule or a TLS Exclusion List.
• Blue: Decrypt. The connection was decrypted and then re-encrypted and forwarded.

In the log, you also see decryption profile, source IP, destination IP, user, category, and target domain. This allows you to check whether the correct rule matched and whether an exception really applies.

Tests

After activating TLS Inspection, you should check:

• Is the Sophos CA certificate used in the browser?
• Do important business applications work?
• Are there TLS errors in the Log Viewer?
• Are malware or web policy events correctly detected?
• Is the traffic displayed as decrypted in the Control Center widget?
• Does the firewall performance remain within the expected range?
• Are there complaints from test users?

For troubleshooting, Log Viewer, Policy Test, browser certificate view, Packet Capture, and the SSL/TLS Inspection widget are particularly helpful.

Troubleshooting and Operation

TLS Inspection problems are usually solved through clear exceptions, controlled rollback and regular review.

Typical Errors

• Browser shows certificate warning: CA missing in trust store or wrong CA used. CA distribution, certificate chain in browser, client restart.
• Log Viewer shows no SSL/TLS inspection events: wrong mode, no matching rule, or SSL/TLS engine not active. Firewall rule, DPI/Web Proxy, SSL/TLS Inspection Rule.
• Traffic is allowed but not decrypted: Don't decrypt rule, managed exclusion, or wrong rule order. Check SSL/TLS Inspection Rules from top to bottom.
• Web filter does not work as expected: Web policy missing, QUIC active, or Scan HTTP and decrypted HTTPS misunderstood. Matching firewall rule, QUIC, web policy log.
• Individual applications break: Certificate pinning, old TLS version, incompatible cipher suite, or own certificate check. Log Viewer, decryption profile, targeted exception.
• Many errors in the dashboard widget: too broad rollout or unsuitable decryption profile. Reduce pilot group, sort errors by domain and category.
• Performance drops after activation: too broad scope, large downloads, or too many simultaneous sessions. Check decryption scope, firewall load, and top users.
• Exception does not work: Exception is below a more general decrypt rule. Check rule order and matching criteria.

In unclear cases, you should not change multiple things at once. A tighter test case is better: one client, one target domain, one firewall rule, one decryption profile, and a clear time in the Log Viewer.

Rollback

If disruptions occur, a clear rollback should be possible:

• Deactivate SSL/TLS Inspection Rule.
• Remove test group from the rule.
• Soften decryption profile.
• Add exception for affected domain or application.
• Switch firewall rule back to Web Proxy if that is consciously desired.

SSL/TLS Inspection Rules and the SSL/TLS engine must be visibly active for the Control Center and Log Viewer to display details. If you deactivate SSL/TLS Inspection for troubleshooting purposes, you should reactivate it afterwards and briefly document the state.

Operational Recommendation

TLS Inspection is not a one-click project. Properly implemented, however, it provides significantly more visibility and enhances the effectiveness of Web Protection, Malware Scanning, IPS, NDR, and Zero-Day functions.

For productive environments, we recommend:

• Start with LAN-to-WAN for a small test group.

• Distribute CA certificate properly.

• Consciously choose DPI/Web Proxy mode.

• Do not start decryption profile too aggressively.

• Monitor Log Viewer and Dashboard daily.

• Document exceptions and review regularly.

• Only roll out further after successful tests.

• Keep rollback tested for the pilot group and exceptions.

FAQ