Sophos Firewall TLS Inspection richtig einführen

Bei der TLS Inspection beendet die Sophos Firewall die verschlüsselte Verbindung des Clients und baut eine zweite zum Zielserver auf. Dazwischen kann sie den Klartext prüfen. Ein ursprünglich vertrauenswürdiges Serverzertifikat signiert sie für den Client mit einer eigenen CA (Certificate Authority) neu. Vertraut der Client dieser CA nicht, erscheint eine Zertifikatswarnung oder die Verbindung bricht ab.

Damit werden Prüfungen des entschlüsselten Inhalts möglich, etwa Malware- und Content-Scanning. Ohne Entschlüsselung bleiben Schutzfunktionen je nach Modul auf Informationen wie IP-Adresse, Domain, SNI, Zertifikat oder Protokollmetadaten beschränkt. Das rechtfertigt aber keinen breiten Start: Certificate Pinning, Datenschutz, Applikationskompatibilität und die zusätzliche Last auf der Firewall müssen vor dem Rollout geklärt sein.

Der sichere Kurzablauf lautet: DPI- oder Web-Proxy-Pfad bestimmen, Re-Signing-CA an eine kleine Gruppe verteilen, den bisherigen Zustand dokumentieren, eine eng begrenzte Decrypt-Regel erstellen, einen positiven und einen negativen Test ausführen und erst danach erweitern.

Vor dem Pilotprojekt entscheiden

Lizenz, CA und Verantwortlichkeit

SSL/TLS Inspection Rules sowie darin verwendete URL Groups werden bereits mit der Base License durchgesetzt. Web Protection ist keine allgemeine Voraussetzung für TLS Inspection. Sie wird benötigt, wenn Web-Kategorien als Regelkriterium greifen oder entsprechende Web-Protection-Funktionen genutzt werden sollen. Malware-, Zero-Day- und weitere Prüfungen benötigen jeweils die dazugehörige Subscription. Die Unterschiede erklären Welche Sophos Firewall Bundles gibt es? und Sophos Firewall Base License verstehen.

Vor der ersten Regel sollten folgende Punkte geklärt sein:

• Die eingesetzte SFOS-Version, die verfügbare Lizenz und der gewünschte Prüfpfad sind dokumentiert.
• Eine verwaltete Pilotgruppe und ein klarer Zeitraum sind festgelegt. Das Beispiel unten verwendet den Client 10.20.30.50 aus dem Testnetz 10.20.30.0/24; diese Werte müssen durch eigene Objekte ersetzt werden.
• Datenschutzverantwortliche haben Scope, Protokollierung, Aufbewahrung und Information der Benutzer freigegeben.
• Der genaue Vorzustand von Firewall-Regel, TLS-Regeln, Decryption Profile, CA und allfälligen globalen Einstellungen ist gesichert. Der vollständige Matching-Pfad vor dem Pilotprojekt, die nach dessen Deaktivierung matchende Regel (einschliesslich einer allfälligen nachgeordneten, breiter gefassten Decrypt-Regel) und jede pilotbedingte Änderung an Firewall-Regeln, DPI/Proxy-Modus, Web Policy und globalen Einstellungen sind dokumentiert. Die genauen autorisierten Wiederherstellungsschritte sind vor der Aktivierung festgelegt.
• Owner, Abbruchkriterien, Ausnahmeprozess und Rückweg sind benannt.

Die Re-Signing-CA muss im Trust Store der betroffenen Betriebssysteme oder Browser liegen. Alternativ lässt sich eine untergeordnete Unternehmens-CA verwenden. Eine öffentlich vertrauenswürdige CA ist dafür nicht erhältlich, weil die Firewall Zertifikate für fremde Domains neu signiert. Bei einer externen CA müssen Root- und Subordinate-CA importiert sein; enthält die Signing-CA eine EKU-Sektion, muss sie TLS Web Server Authentication erlauben. Die Verteilung beschreibt Sophos Firewall CA Zertifikat für HTTPS Scanning installieren, den Enterprise-CA-Weg Untergeordnete CA für Sophos Firewall TLS Inspection einrichten.

⚠️ Nicht mit allen Benutzern beginnen. Geräte ohne verwaltbaren Trust Store, BYOD und Anwendungen mit Certificate Pinning gehören zunächst in einen separaten Scope. Eine Ausnahme stellt die Verbindung zwar wieder her, nimmt ihren Inhalt aber aus der Entschlüsselung.

DPI und Web Proxy unterscheiden

SFOS verwendet standardmässig die DPI engine. In diesem Pfad verarbeitet die Firewall zuerst die Firewall Rule und danach die SSL/TLS Inspection Rules. Die Inspection Rule erlaubt selbst keinen Traffic: Auch Services: Any bedeutet nur, dass bereits von der Firewall Rule erlaubter TLS-Traffic auf jedem TCP-Port für diese Inspection Rule infrage kommt.

Für den DPI-Pfad öffnet man Rules and policies > Firewall rules, bearbeitet die betroffene LAN-to-WAN-Regel und prüft unter Security features > Web filtering:

1. Use web proxy instead of DPI engine bleibt deaktiviert.
2. Eine Web Policy wird nur gewählt, wenn sie für den geplanten Schutz benötigt wird; sie ist keine Voraussetzung für die Decryption Rule.
3. Scan HTTP and decrypted HTTPS aktiviert Malware-Scanning für HTTP und bereits entschlüsseltes HTTPS. Die Option schaltet die HTTPS-Entschlüsselung nicht selbst ein.

Im Web Proxy Mode übernimmt der Proxy die HTTPS-Entschlüsselung. Dafür ist Decrypt HTTPS during web proxy filtering im Proxy-Pfad massgebend. Die DPI-Regeln unter Rules and policies > SSL/TLS inspection rules wirken nicht auf Verbindungen, die der Web Proxy entschlüsselt. Beim transparenten Proxy laufen Port 80 und 443 über den Proxy, während SSL/TLS auf anderen Ports weiterhin vom DPI-Pfad erfasst werden kann; beim Explicit Proxy entschlüsselt der Web Proxy.

Auch die CAs sind getrennt: DPI verwendet die CA aus den SSL/TLS settings beziehungsweise dem gewählten Decryption Profile. Der Web Proxy verwendet die CA aus Web > General settings. Wer den Modus wechselt, muss deshalb nicht nur Regeln, sondern auch die tatsächlich präsentierte CA prüfen. DPI Engine oder Web Proxy richtig wählen führt die Unterschiede weiter aus.

Für veröffentlichte Webserver aus dem Internet ist dieser ausgehende Inspection-Pfad nicht gedacht. Dort sind Web Server Protection / WAF oder ein Reverse Proxy meist die passendere Architektur. SSL/TLS Inspection Rules gelten für ausgehenden Traffic; als Source zones sind deshalb nur interne Zonen auswählbar. Sie erkennen TLS auf jedem TCP-Port, werden aber nicht über UDP erzwungen.

Dokumentationswiderspruch zur Richtung: Die Anleitung zum Anlegen einer Regel nennt eingehende und ausgehende Verbindungen, beschränkt Source zones später aber ausdrücklich auf interne Zonen und ausgehenden Traffic. Die allgemeine Formulierung ist kein Nachweis für WAN-Inbound-Inspection. Dieser Rollout bleibt beim beschriebenen internen Clientpfad; für eingehende Serververbindungen wird vor einer Änderung eine buildbezogene Klärung mit Sophos Support benötigt.

Vor dem Decryption-Test müssen Routing, DNS und der erlaubte Internetzugang bereits funktionieren. Unter Rules and policies > NAT rules wird die tatsächlich passende SNAT-Regel geprüft; in einem üblichen IPv4-Internetdesign ist dies beispielsweise Default SNAT IPv4 mit Translated source (SNAT): MASQ. Eine korrekt arbeitende Regel wird nicht durch eine zusätzliche breite NAT-Regel ersetzt. IPv6 und geroutete Netze benötigen eine eigene Designentscheidung, nicht automatisch MASQ. Die Pilot-Firewall-Regel braucht Action: Accept und den genehmigten Source-, Destination- und Service-Scope.

Beim Proxy zusätzlich unter Web > General settings > HTTPS decryption and scanning die HTTPS scanning certificate authority (CA), Block unrecognized SSL protocols und Block invalid certificates prüfen. Für Direct Proxy werden der konfigurierte Listener unter Web > General settings > Web proxy configuration und Administration > Device access > Other services > Web proxy nur für die benötigten Clients beziehungsweise Zonen freigegeben. Transparenter Proxy benötigt HTTP/HTTPS als Services, Direct Proxy zusätzlich den konfigurierten Listener-Port. Den vollständigen Ablauf und die Absicherung lokaler Firewall-Webdienste führt der bereits verlinkte DPI-/Proxy-Artikel aus.

Veraltetes Kompatibilitätsbeispiel: Die beibehaltene SFOS-22/23-Konfigurationsanleitung fordert im Proxy-Beispiel TLS 1.1, während die Decryption-Profile-Dokumentation Versionen vor TLS 1.2 als unsicher bezeichnet. TLS 1.1 wird deshalb nicht als Rollout-Vorgabe übernommen. Sichere Protokollvorgaben beibehalten; benötigt eine Altanwendung eine Ausnahme, werden Version, betroffener Pfad, Risiko und enger Scope vorab mit dem Firewall-Owner geklärt. Globale TLS-Absenkung ist kein Pilot-Fix.

QUIC in den Prüfpfad einbeziehen

QUIC beziehungsweise HTTP/3 verwendet UDP. Block QUIC protocol in einer Firewall Rule verwirft in deren Scope ausgehende UDP-Pakete zu Port 80 und 443, damit Clients auf einen prüfbaren TCP-Pfad zurückfallen. SFOS wählt die Option standardmässig aus, sobald in der Regel eine Web Policy gewählt oder Scan HTTP and decrypted HTTPS aktiviert wird. Das ist regelbezogen, nicht global; kontrolliert wird daher die tatsächlich matchende Firewall Rule. Clients mit einem nutzbaren TCP-Fallback versuchen normalerweise eine neue Verbindung über TCP; Clients ohne einen solchen Fallback können die Konnektivität verlieren. Die Option erfasst kein UDP auf anderen Ports. Eine tatsächliche TCP-Verbindung, die Anwendungsfunktion und das Matching des vorgesehenen Prüfpfads müssen verifiziert werden; das Blockieren von UDP allein weist nichts davon nach.

QUIC kann von diesem Webfilter nicht gescannt werden. Daraus folgt nicht, dass jede andere Firewall-Kontrolle umgangen wird, wohl aber, dass der erwartete TCP-TLS- und Webfilterpfad nicht greift. Den Regeltest zeigt Sophos Firewall QUIC und HTTP/3 richtig blockieren; die Web Policy wird in Sophos Firewall Web Protection Policy erstellen aufgebaut.

Scope nach Aufgabe und Risiko auswählen

Der übliche Einstieg ist verwalteter Benutzerverkehr von LAN nach WAN. Ein separates Firmen-WLAN kann als Wi-Fi > WAN folgen. Bei Remote Access kommt VPN > WAN nur infrage, wenn der Internetverkehr der Benutzer tatsächlich als Full Tunnel durch die Firewall läuft. Interne Verbindungen von LAN in eine DMZ werden nur einbezogen, wenn die Inhaltsprüfung dort einen klaren Nutzen hat und der Client der Re-Signing-CA vertraut, während die Firewall die ursprüngliche Serverzertifikatskette validiert. Auf gewöhnlichen Zielservern muss diese Inspektions-CA nicht installiert werden. Die Kompatibilität von Mutual TLS (mTLS) ist gesondert zu prüfen.

Technische Kompatibilität und die zulässige Entschlüsselung sind getrennte Entscheide. Banking-, Gesundheits- und Behördenportale, Passwortmanager, Identity-Provider, Betriebssystem- und Hersteller-Updates sowie Voice-, Video- und Collaboration-Dienste brauchen vor dem Einschluss eine fachliche und datenschutzrechtliche Bewertung. Pinning oder ein Fehler im Pilotprojekt rechtfertigt keine pauschale Ausnahme für die ganze Kategorie: Zuerst werden die tatsächlich benötigte Source, Domain und Anwendung bestimmt.

Ein vollständiges Pilotprojekt konfigurieren

Für ein direkt prüfbares Pilotprojekt verwenden wir diese Beispielwerte:

• Pilotclient: 10.20.30.50 aus dem dokumentierten Testnetz 10.20.30.0/24
• Firewall Rule: LAN to WAN - TLS pilot
• SSL/TLS Inspection Rule: TLS decrypt pilot client
• Source zone: LAN, Destination zone: WAN
• Destination networks und Services: Any
• Action: Decrypt
• Decryption profile: zunächst Block insecure SSL oder ein daraus abgeleitetes Pilotprofil
• Logging: Log connections für das Pilotprojekt aktiviert

10.20.30.0/24, Host-IP und Objektnamen sind Beispiele. Die produktive Source muss so eng sein, dass ein einzelner Client sicher zugeordnet werden kann. Any bei Destination und Service erleichtert im Pilotprojekt die Beobachtung von TLS ausserhalb TCP 443; es erweitert nicht die Erlaubnis der vorgelagerten Firewall Rule. Wer nur eine Zielgruppe prüfen darf, setzt zusätzlich eine URL Group oder ein anderes passendes Zielkriterium.

Decryption Profile wählen

Unter Profiles > Decryption profiles stehen drei nicht editierbare Standardprofile bereit:

• Maximum compatibility maximiert die Kompatibilität und schränkt Cipher nicht ein.
• Block insecure SSL blockiert schwache Cipher und erlaubt Traffic, der nicht entschlüsselt werden kann.
• Strict compliance setzt strenge, unter anderem auf PCI-DSS ausgerichtete Vorgaben.

Maximum compatibility kann einen problematischen Client kurzfristig eingrenzen, ist wegen seiner gelockerten Prüfungen aber kein Produktions-Abnahmekriterium. Für das Pilotprojekt ist Block insecure SSL oder ein bewusst daraus abgeleitetes Profil der transparentere Ausgangspunkt. Alte TLS-Versionen oder RSA-Schlüssel unter 2048 Bit werden nur für einen benannten Altserver und in einer engen Regel toleriert.

Ablehnung veralteter Verfahren unter Decrypt: Mit Action: Decrypt lehnt Sophos Firewall Verbindungen mit SSL 2.0 and SSL 3.0, SSL compression oder Unrecognized cipher suites weiterhin ab, auch wenn im Profil dafür Allow without decryption gewählt ist. Eine ausdrücklich genehmigte, eng begrenzte Ausnahme für Altsysteme erfordert sowohl Allow without decryption in den relevanten Profilfeldern als auch Action: Don’t decrypt; die Freigabe im Profil allein reicht nicht aus.

Ein eigenes Profil kann die globalen SSL/TLS settings überschreiben. Für die Re-Signing-CA stehen Use CAs defined in SSL/TLS settings, Re-sign RSA with und Re-sign EC with zur Verfügung. Für nicht entschlüsselbaren Traffic gibt es Use SSL/TLS settings default, Allow without decryption, Drop und Reject. Der Verweis auf den globalen Standard gilt nicht für Unrecognized cipher suites; dieser Fall muss im Profil ausdrücklich beurteilt werden. Zertifikatsfehler, RSA-Mindestgrösse, TLS-Versionen und blockierte Cipher verwenden als Block action je nach Einstellung Drop, Reject oder Reject and notify.

Ein selbstsigniertes oder unvollständig verkettetes Serverzertifikat wird durch Inspection nicht vertrauenswürdig. Statt es vorschnell auszunehmen, prüft man zuerst Hostname, Originalzertifikat und vollständige Chain.

Bei einem selbstsignierten Original ersetzt die Firewall den Schlüssel und signiert damit, aber nicht als vertrauenswürdige CA: Der Client sieht weiterhin ein selbstsigniertes Zertifikat. Fehlt die vollständige Chain zu einer von der Firewall vertrauten CA, wird ein systemgeneriertes Zertifikat verwendet, dessen CN den Fehler erklärt. Eine Warnung ist daher nicht automatisch ein Fehler der CA-Verteilung.

Ein eigenes Profil wird mit Profiles > Decryption profiles > Add, Name und Beschreibung erstellt oder aus einem passenden Profil geklont, danach gespeichert und der Inspection Rule zugewiesen. RSA- und EC-Originalzertifikate können in vielen Fällen dieselbe Signing-CA verwenden. Benötigt eine Anwendung einen bestimmten Schlüsseltyp, wird die entsprechende CA unter Re-sign RSA with beziehungsweise Re-sign EC with gewählt. Über den Download-Button neben der Auswahl wird jede tatsächlich verwendete CA bezogen; bei zwei verschiedenen CAs müssen die Clients beiden vertrauen.

Vor dem Speichern werden Certificate errors to block, Minimum RSA key size, Minimum SSL/TLS version, Maximum SSL/TLS version und Cipher algorithms to block bewusst geprüft. TLS unter 1.2 und RSA unter 2048 Bit sind kein sicherer Standard. Maximum supported erlaubt die jeweils maximal unterstützte Protokollversion. Die Prüfung auf Revoked benötigt eine importierte CRL (Certificate Revocation List); eine ausgewählte Checkbox allein belegt keine funktionierende Widerrufsprüfung. Eine Web Exception für HTTPS decryption kann passende Verbindungen mit ungültigen Zertifikaten zulassen und ist daher keine reine Pinning-Korrektur.

Zu den Zertifikatsfehlern gehören Invalid date, Self-signed, Untrusted user, Revoked, Name mismatch und Invalid for other reasons. Name mismatch vergleicht den Servernamen aus dem Client Hello mit den Namen im Zertifikat. Bei den Cipher-Algorithmen werden Schlüsselaustausch, Authentifizierung, Bulk-Cipher und Hash getrennt beurteilt. SSL-Kompression vor der Verschlüsselung hat bekannte Schwachstellen; unbekannte Cipher können nicht entschlüsselt werden.

Die globalen Vorgaben findet man unter Rules and policies > SSL/TLS inspection rules > SSL/TLS inspection settings. Unter TLS 1.3 decryption stehen Decrypt as 1.3 und Downgrade to TLS 1.2 and decrypt. Die zweite Option wirkt auf alle SSL/TLS Inspection Rules; für den normalen Pilot wird keine globale Absenkung vorgenommen.

When SSL/TLS connections exceed limit bestimmt, was bei ausgeschöpfter Decryption-Kapazität passiert: Allow without decryption erhält Erreichbarkeit, verliert aber die Inhaltsprüfung; Drop verwirft still, Reject sendet einen Reset. Das ist eine bewusste Verfügbarkeits-/Schutzentscheidung für den Pilot, nicht nur ein Performancewert. Reject and notify versucht bei HTTPS eine Blockseite mit Fehlergrund anzuzeigen, garantiert sie aber nicht; es verhindert den Datentransfer zum Server.

Bei TLS 1.3 greifen Zertifikatsfehler, Mindest-RSA-Grösse, ein globales Downgrade und Reject and notify in der dokumentierten Weise nur mit Action: Decrypt. Bei Don’t decrypt oder Deny wird für diese Profilbehandlung stattdessen Reject angewendet. Ein globales Downgrade auf TLS 1.2 bringt ein Sicherheitsrisiko mit und ist kein allgemeiner Kompatibilitätsfix.

Regel anlegen und Reihenfolge prüfen

Unter Rules and policies > SSL/TLS inspection rules > Add werden die Felder so gesetzt:

1. Rule name: TLS decrypt pilot client
2. Rule position: Top, damit die Pilotregel vor allgemeinen selbst erstellten Decrypt-Regeln liegt
3. Action: Decrypt
4. Log connections: aktiv für die Pilotbeobachtung
5. Decryption profile: das gewählte Pilotprofil
6. Source zones: LAN
7. Source networks and devices: Hostobjekt für 10.20.30.50
8. Destination zones: WAN
9. Destination networks: Any
10. Services: Any
11. Categories and websites: leer oder auf den genehmigten Ziel-Scope begrenzt

Log connections ist optional und nicht nötig, damit die Regel arbeitet. Für ein zeitlich begrenztes Pilotprojekt ist es dennoch sinnvoll, weil Handshake und Verbindungsende nachvollziehbar werden. Die Aufbewahrung richtet sich nach dem vereinbarten Datenschutz- und Betriebskonzept.

Die Tabelle wird von oben nach unten ausgewertet; beim ersten Treffer endet die Suche. Alle gesetzten Kriterien müssen gleichzeitig passen. Die feste Standardregel Exclusions by website or category steht dauerhaft ganz oben und lässt sich nicht durch Rule position: Top überholen. Eigene Don't decrypt-Ausnahmen gehören unmittelbar darunter, danach spezifische Pilotregeln und zuletzt breitere Decrypt-Regeln.

Nach Save wird die Regel in der Tabelle nochmals auf Status und Position geprüft. More options bietet Bearbeiten, Klonen, Einfügen neben einer Regel und Löschen; der Rule handle verändert die Reihenfolge. Filter nach Source, Destination oder Rule ID helfen beim Abgleich, Reset filter zeigt wieder die ganze Tabelle. Action: Deny verhindert den Verbindungsaufbau und ist nicht dasselbe wie Don’t decrypt. Categories and websites wird anhand des SNI im TLS-Handshake erkannt. Neue Installationen aktivieren SSL/TLS Inspection Rules standardmässig; der reale Status bleibt trotzdem Teil des Preflights.

Benutzer- und Gruppenkriterien sind nur zuverlässig, wenn SFOS den Benutzerkontext für die Verbindung kennt. Ist das nicht garantiert, beginnt man mit einem eindeutigen Host- oder Netzobjekt und ergänzt Identitätskriterien erst nach einem separaten Match-Test.

TLS-Konfiguration per XML API unterscheiden

Bei automatisierten Rollouts sind die Inspection Rule, die globalen DPI-Einstellungen und die HTTP-/HTTPS-Scanning-Konfiguration drei verschiedene Objekte. Eine CA-Auswahl aktiviert weder die Pilotregel noch das Scanning in der Firewall Rule. Die folgenden Zuordnungen betreffen die Objektstruktur für SFOS 22 und 23. Vor einem Schreibzugriff werden die explizite Operation und der vollständige Payload in API help des installierten Builds bestätigt. Quellfreigabe, Konto, TLS-Prüfung, Secrets und die Unterscheidung von HTTP-Erfolg und XML-Status erklärt XML API Zugriff sicher begrenzen und Antworten prüfen.

Inspection Rule: Identität, Hierarchie und Reihenfolge

Das Objekt heisst SSLTLSInspectionRule. Sein direktes Name bezeichnet die Regel; NewName ist im Beispiel der bearbeitete Name für eine Umbenennung, nicht der Name der Referenzregel für eine Verschiebung. Für den Regelnamen sind maximal 60 Zeichen, UTF-8 und kein Komma dokumentiert; Description ist auf 255 Zeichen begrenzt. IsDefault ist read-only und wird nicht verwendet, um eine eigene Pilotregel zur Standardregel zu machen.

Die Matchfelder bleiben unter ihren jeweiligen Eltern, auch wenn die Parametertabelle mehrfach denselben Kindnamen aufführt:

• SourceZones > Zone und SourceNetworks > Network: interne Quellzone und das genehmigte Pilot-Hostobjekt.
• DestinationZones > Zone und DestinationNetworks > Network: Zielzone und freigegebene Zielobjekte.
• Identity > Members: Quellbenutzer oder Gruppen, nur mit geprüftem Identitäts-Match.
• Services > Service: Serviceobjekte für den genehmigten Scope.
• Websites > Activity > Name und Websites > Activity > Type: Name und Typ des Website-Kriteriums; das Beispiel nennt Web Category und URL Group.
• MoveTo > Name und MoveTo > OrderBy: Referenzregel und relative Position; OrderBy verwendet Before oder After.

Zone, Network, Service und Website-Aktivitäten können mehrfach vorkommen. Ein flaches Name oder Network ohne den richtigen Elternknoten beschreibt nicht denselben Zweck. Objektbezeichnungen werden aus der vorhandenen Konfiguration übernommen; Scope und Profil werden nicht durch fehlende Felder oder ungeprüfte Defaults ersetzt.

Position verwendet Top oder Bottom und dient nur beim ADD zur anfänglichen Platzierung. Ohne Angabe nennt das Beispiel Bottom; für UPDATE oder APIImport ist Position nicht erforderlich und wird hier nicht als Verschiebungsmechanismus übernommen. Das optionale MoveTo wird beim ADD nach Position angewendet. Wer beides setzt, muss daher die resultierende relative Position prüfen, nicht nur den anfänglichen Top-Wert. Die feste Standard-Exclusion bleibt ganz oben; die oben beschriebene Reihenfolge der genehmigten Ausnahmen, Pilotregeln und breiteren Decrypt-Regeln gilt weiterhin.

Die direkten Felder Enable, LogConnections, DecryptAction und DecryptionProfile haben getrennte Aufgaben: Regelstatus, Logging, Entschlüsselungsentscheid und Profilzuweisung. Für Enable nennt die Tabelle Yes, No, t, f; für LogConnections Enable, Disable, t, f. DecryptAction verwendet exakt Decrypt, Do not decrypt oder Deny. Das UI-Label Don’t decrypt ist deshalb kein ungeprüfter XML-Wert. Das gewählte Profil wird unter DecryptionProfile mit seinem tatsächlichen Namen zugewiesen; eine enge Source und der vollständige genehmigte Ziel-/Service-Scope bleiben auch bei Automatisierung Pflicht.

Die objektspezifischen XML-Statuszeilen unterscheiden Operation und Symbol:

Message.* bleibt hier ein nicht aufgelöster Dokumentationsbezeichner, kein garantierter Laufzeittext und keine abschliessende Fehlerursache. Vor jedem Retry werden die bereinigte Antwort und der tatsächlich gespeicherte Zustand abgeglichen: ursprünglicher oder neuer Regelname, Status, vollständige Kriterien, DecryptionProfile und Position relativ zu den anderen Regeln. Auch eine 200-Zeile ersetzt weder diesen Abgleich noch den Test mit neuen Verbindungen. Bei unklarem Zustand stoppen und klären, statt durch erneutes ADD oder eine andere Position eine zweite oder breitere Regel zu erzeugen.

Globale DPI-Einstellungen: CA ist kein Ein-/Ausschalter

Unter SSLTLSInspectionSettings stehen RSACA und ECCA direkt für die Re-Signing-CA-Auswahl für RSA- beziehungsweise EC-Serverzertifikate. Sie verweisen auf CA-Objekte, nicht auf Dateipfade oder Aktivierungswerte. Das Profil kann die CA-Auswahl für seine Regel überschreiben. Vor einem Wechsel werden deshalb Profil, tatsächlich präsentierte CA, Client-Vertrauen und Root-/Subordinate-Chain gemeinsam geprüft; bei verschiedenen verwendeten CAs müssen Clients beiden vertrauen.

Davon getrennt sind die direkten globalen Felder SSLTLSEngine und SSLTLSInspection, jeweils mit Enabled oder Disabled. Das erste steuert die TLS engine, das zweite die globale SSL/TLS Inspection, nicht den Status einer einzelnen Pilotregel. Das Abschalten der Inspection verhindert Regelanwendung und Verbindungs-/Decryption-Details in Control Center und Log viewer. Das Abschalten der Engine nimmt zusätzlich die Anwendung der DPI-Web-Policy auf HTTPS aus dem Pfad; Proxy-HTTPS-Decryption bleibt davon unberührt. Keines von beiden ist ein normaler Pilot-Rollback.

TLS13Decryption steht ebenfalls direkt unter SSLTLSInspectionSettings und verwendet Decrypt as 1.3 oder Downgrade to TLS 1.2 and decrypt. Es wählt die globale TLS-1.3-Behandlung, nicht die Signing-CA und nicht die Aktion einer einzelnen Regel. Eine Absenkung betrifft alle Inspection Rules und wird nicht als Kompatibilitätskorrektur für einen einzelnen Client eingeführt. Die bereits erläuterten Grenzen bei TLS 1.3 und Action: Decrypt bleiben massgebend.

Die weiteren direkten Felder SSLv2SSLv3, SSLCompression und SSLConnectionsExceeded verwenden jeweils Allow without decryption, Drop oder Reject. Sie betreffen unterschiedliche Fälle und werden nicht mit DecryptAction gleichgesetzt. Nach einer autorisierten Änderung werden die gespeicherten globalen Werte, Profil-Overrides und der reale Pilotpfad geprüft. Zurückgesetzt werden nur die dokumentierten pilotbedingten Änderungen auf ihren exakten Vorzustand, ohne pauschales Deaktivieren der Kontrollen.

HTTP-/HTTPS-Scanning: eigenen Elternknoten beachten

Das separate Objekt AntiVirusHTTPsConfiguration enthält direkt ScanMode, FileSizeThreshold, AudioVideoFileScanning und PUADetection. Im Kindknoten HTTPSConfigurations stehen dagegen HTTPSScanningCA, DenyUnknownProtocol, AllowInvalidCertificate und NoHttpsNotification. HTTPSScanningCA gehört damit zur HTTP-/HTTPS-Konfiguration des Proxy-Pfads, nicht zu RSACA oder ECCA der DPI-Einstellungen. Diese Felder ersetzen weder den DPI-Regelmatch noch Decrypt HTTPS during web proxy filtering in der passenden Firewall Rule. Den Scanning-Kontext erläutert Malware-Scanning auf Sophos Firewall einordnen.

ScanMode nennt RealTime und BatchMode. FileSizeThreshold ist in KB angegeben; die Tabelle nennt 1 bis 1572864, maximal 7 Ziffern und den Default 1024. Dateien oberhalb der Schwelle werden nicht gescannt; der dokumentierte Default ist keine Empfehlung für jede Umgebung.

Nicht aufgelöster Wertewiderspruch: Das XML-Beispiel zeigt für AudioVideoFileScanning Enable/Disable, die Parametertabelle dagegen on/off und den Default Disable. Daraus werden keine austauschbaren Aliase abgeleitet. Auch DenyUnknownProtocol und AllowInvalidCertificate zeigen im Beispiel Enable/Disable, während die Tabelle nur on beziehungsweise on/off nennt; bei PUADetection stehen dort symbolische Werte. Vor einer automatisierten Änderung muss API help beziehungsweise Support die für Objekt und Build gültigen Werte bestätigen. Ohne Klärung den betroffenen Schreib-Request nicht ausführen; Zertifikatskontrollen nicht lockern, um einen Import passend zu machen.

Nach einer freigegebenen Änderung werden die gespeicherte CA-Auswahl und Kontrollen unter Web > General settings, der tatsächlich matchende Proxy-/DPI-Pfad und der sichtbare Zertifikatsaussteller mit dem Vorzustand verglichen. Erst danach folgen Funktions-, Positiv- und Ausnahme-Negativtest. Eine formal akzeptierte Scanning-Konfiguration ist kein Nachweis für Entschlüsselung oder wirksames Malware-Scanning.

Ausnahmen eng halten

Die Standardregel Exclusions by website or category verwendet Don’t decrypt mit Maximum compatibility und bleibt an erster Position. Die Local TLS exclusion list ist standardmässig leer; die Managed TLS exclusion list enthält bekannte inkompatible Sites und wird mit Firmware-Updates gepflegt.

Die lokale Liste lässt sich unter folgendem Pfad bearbeiten:

Web > URL groups > Local TLS exclusion list

URL Groups beziehungsweise SNI-Matches sind für Domain-Ausnahmen effizienter als viele FQDN Hosts. Laut Sophos verursachen beispielsweise 200 FQDN Hosts bei jeder neuen SSL/TLS-Verbindung 200 Lookups. Die Einschränkung für kombinierte Source-/Destination-Exceptions muss vom normalen Regelmatch unterschieden werden. Domain-Scope, Wildcards und Negativtests erklärt URL Groups erstellen und sicher verwenden.

Unklarer Ausnahme-Scope: Die Website-Ausschlussanleitung sagt, dass Source- und Destination-Exceptions nicht kombiniert werden können; die Regelanleitung bietet dagegen beide Matchfelder. Das belegt nicht, dass eine kombinierte Quell-/Ziel-IP-Web-Exception zulässig ist. Für den Pilot bleibt die Source-Begrenzung mit bestätigtem Hostnamen beziehungsweise URL Group erhalten. Sind zusätzlich beide IP-Ausnahmekriterien zwingend, wird der Ausschluss bis zur buildbezogenen Support-Klärung nicht aktiviert oder erweitert. Kein Kriterium entfernen, nur damit der Match funktioniert.

Eine eigene SSL/TLS Inspection Rule mit Action: Don’t decrypt sollte Domain, betroffene Source, Grund, Ticket, Owner und Review-Datum enthalten. Don’t decrypt ist kein bedingungsloser Bypass: Die Einschränkungen des ausgewählten Decryption Profile gelten weiter. Sollen SSL 2/3, Compression oder unbekannte Cipher für einen ausdrücklich genehmigten Altfall passieren, braucht es ein Profil mit Allow without decryption zusammen mit Action: Don’t decrypt. Diese Kombination gehört nicht in eine breite Internetregel.

Für einen ausdrücklich genehmigten Altfall wird unter Profiles > Decryption profiles > Add beispielsweise Allow_non-decryptable_profile erstellt. Nur die tatsächlich benötigten Felder SSL 2.0 and SSL 3.0, SSL compression oder Unrecognized cipher suites erhalten Allow without decryption. Unter Rules and policies > SSL/TLS inspection rules > Add wird das Profil einer engen Don’t decrypt-Regel mit Pilotquelle, internem Source-Bereich, passender Destination und bekanntem Ziel zugeordnet. Das ist ein Sicherheitsabbau für einen begründeten Altfall, keine allgemeine Freigabe dieser Protokolle.

Fehlt ein auswertbares SNI, können URL Group und Domain-Regex das Ziel nicht erkennen. Dann kommt nach Prüfung des tatsächlichen Flows ein enger IP Host unter Destination networks infrage; ein FQDN Host bleibt eine DNS-basierte Alternative mit den genannten Kosten. Bei Regex sind ein verankerter Beginn ^ und ein Negativtest wichtig; breite Wildcards können zusätzlich langsamer sein. Der folgende Web-Exceptions-Link erklärt die vollständige sichere Syntax und den Unterschied zum Domainlisten-Match.

SSL/TLS Exclusions und Web Exceptions lösen verschiedene Aufgaben. Die TLS-Ausnahme entscheidet im DPI Mode über Decryption auf beliebigen TCP-Ports. Eine Web Exception verändert ausgewählte Web-Policy-Prüfungen; im Proxy Mode betrifft sie den entsprechenden Proxy-Pfad. Ob Decryption oder nur eine Web-Prüfung ausgenommen werden soll, muss daher vor der Änderung feststehen. Web Exceptions sicher erstellen und prüfen zeigt den Auswahl- und Regex-Pfad.

Android mit engem Scope unterstützen

Einige Android-Verbindungen verwenden Certificate Pinning. Dann können Connectivity Check, Play Store oder Updates bei Decryption ausfallen. Der von Sophos dokumentierte Workflow verwendet ein isoliertes VLAN oder WLAN und eine FQDN Host Group mit:

• *.play.googlezip.net
• *.gvt1.com
• *.app-measurement.com
• der lokalen Google-Domain, in der Schweiz beispielsweise *.google.ch

Die Gruppe wird unter Hosts and services > FQDN host group > Add angelegt. Unter Hosts and services > FQDN host > Add entsteht je Domain ein Host, der direkt dieser Gruppe zugeordnet wird. Ein neues Sophos-WLAN wird unter Wireless > Wireless networks > Add erstellt; das zugehörige Netzobjekt unter Hosts and services > IP host > Add mit IP version: IPv4, Type: Network, eigener Netzadresse und Maske. Bei einem vorhandenen isolierten VLAN/WLAN wird dessen passendes Objekt verwendet, nicht ein neues Netz auf Verdacht erstellt. Die tatsächlich dieser Schnittstelle oder diesem VLAN zugewiesene Eingangszone muss bestätigt werden; Wi-Fi ist das Beispiel für Sophos-WLAN, keine Vorgabe für jedes Mobilgeräte-Netz.

Die allgemeine Dokumentation empfiehlt eine Ausnahme für alle Android-Geräte; der konkrete Workflow begrenzt sie auf Google-Ziele im isolierten Mobilnetz. Für diesen Rollout gilt der engere Ablauf mit Positiv- und Negativtest, nicht ein pauschaler Bypass aller Android-Verbindungen. Ein Wechsel zum Web Proxy ist eine separate Architekturentscheidung, kein automatisch gleichwertiger Pinning-Fix.

Darüber liegt eine SSL/TLS Inspection Rule mit Action: Don’t decrypt, Decryption profile: Maximum compatibility, der tatsächlichen Eingangszone des Mobilgeräte-Netzes als Source zone (zum Beispiel Wi-Fi, LAN oder eine konfigurierte benutzerdefinierte Zone), dem Mobilgeräte-Netz als Source networks and devices, WAN als Destination zone und der Google-Gruppe als Destination networks. Sie steht unter der festen Standard-Exclusion, aber vor der allgemeinen Decrypt-Regel. Das Mobilnetz bleibt von sensiblen internen Ressourcen getrennt.

Abgenommen wird mit einem Android-Pilotgerät: Connectivity Check und Browserzugriff werden geprüft, eine genehmigte Test-App wird aus Google Play heruntergeladen und eine installierte App über Google Play aktualisiert. Jeder Vorgang muss erfolgreich abgeschlossen werden. Im Log viewer dürfen nur die erwarteten Google-Ziele die Ausnahme treffen; ein anderes HTTPS-Ziel aus demselben VLAN muss weiterhin die vorgesehene Decrypt-Regel verwenden. Für diese tatsächlichen Verbindungen werden die tatsächliche Quellzone und das Quellobjekt, das Matching der Google-Ausnahme und das Matching der vorgesehenen Decrypt-Regel bestätigt. Verwendet wird ein verwaltetes Pilotgerät, dessen konkreter Testbrowser oder dessen konkrete Test-App der Inspektions-CA vertraut; für das entschlüsselte Ziel werden die erfolgreiche Funktion sowie Zertifikats- und Lognachweise geprüft. Clients oder Apps, deren Vertrauen in die Inspektions-CA nicht verwaltet werden kann, bleiben ausserhalb des Decrypt-Scope. Dieser Negativtest verhindert, dass eine funktionierende, aber zu breite Ausnahme akzeptiert wird. Weitere Methoden und SNI-Grenzen behandelt Web Exceptions und TLS-Ausnahmen sicher erstellen.

Wirkung nachweisen

Eine Policy-Simulation, ein echter Client und die Logs beantworten unterschiedliche Fragen. Für eine belastbare Abnahme werden sie kombiniert.

Unter Diagnostics > Tools > Pop-out tools > Policy tester wählt man Firewall, SSL/TLS, and web und setzt Source-IP, Destination beziehungsweise URL, Protokoll und bei Bedarf den Port. Ohne Protokoll testet das Tool HTTP mit dem protokollspezifischen Standardport. Der Policy tester simuliert transparenten Webtraffic; SD-WAN-Routen bildet er nicht ab, und Regeln mit MAC-Adressen unter Source networks and devices matchen dort nicht. Web policy only prüft nur die Web Policy. Das Ergebnis ist deshalb eine Vorhersage, kein Nachweis des realen Datenpfads.

Am Client folgen vier gezielte Tests:

1. Vor der Änderung werden Ziel-Domain, Zertifikatsaussteller, Antwortzeit und funktionierende Business-Anwendung notiert.
2. Ein genehmigtes positives Ziel wird geöffnet und der gewählte Prüfpfad verifiziert. Bei DPI muss der Browser die für DPI gewählte Re-Signing-CA als Aussteller zeigen, und der Log viewer muss die erwartete Decrypt Rule samt Decryption Profile treffen. Bei Web Proxy werden die unter Web > General settings > HTTPS scanning certificate authority (CA) gewählte CA, die tatsächlich matchende Firewall Rule mit Use web proxy instead of DPI engine und Decrypt HTTPS during web proxy filtering sowie entsprechende Proxy-/Web-Lognachweise der erfolgreichen Anfrage geprüft. Für eine durch den Proxy entschlüsselte Verbindung wird weder ein DPI-Regel-/Profil-Match noch ein Eintrag im DPI-Widget verlangt.
3. Ein bewusst ausgenommenes Ziel wird geöffnet. Es muss die erwartete Don't decrypt-Regel treffen; der Browser darf dort nicht das von der Firewall neu signierte Zertifikat sehen.
4. Ein zweites, nicht ausgenommenes Ziel aus demselben Client-Scope muss weiterhin entschlüsselt werden. Das ist der Negativtest für die Ausnahme.

Wenn eine Web Policy Teil des Designs ist, wird zusätzlich eine eigens dafür freigegebene Testkategorie oder Test-URL blockiert. Ein Malware-Test wird nur mit einem dokumentierten, ungefährlichen Hersteller-Testobjekt und einem vorher festgelegten Erwartungswert durchgeführt. Vor und nach dem Pilotprojekt werden ausserdem CPU-/Speicherlast, Antwortzeit und Benutzerfehler im gleichen Zeitfenster verglichen.

Control Center und Log viewer lesen

Das Control-Center-Widget heisst SSL/TLS connections. Seine Details werden alle fünf Minuten aktualisiert. Sessions beziehen sich auf die letzten 24 Stunden, Fehler auf die letzten 7 Tage; Failed wird um Mitternacht zurückgesetzt. Die Detaildaten enthalten keine Web-Proxy-Verbindungen. Decryption peak erscheint nur nahe oder über dem Peak, Decryption limit nur nahe am geräteabhängigen Limit. Es gibt daher keinen universellen Grenzwert für alle Appliances.

Den Log viewer öffnet man oben rechts und wählt das Modul SSL/TLS inspection. Eine TLS-Verbindung wird nach abgeschlossenem Handshake und beim Schliessen protokolliert. Entscheidend sind Action, Rule, Decryption Profile, Source, Destination, Domain und Fehlergrund; Farben allein sind kein belastbares Abnahmekriterium. Unter Manage > Exclude kann man Domains oder Subdomains zur Local TLS exclusion list und Kategorien zur Standard-Exclusion hinzufügen. Bei Error IDs 19004 und 19005 steht Exclude nicht zur Verfügung.

Ein Don't decrypt-Event beweist nur, dass nicht entschlüsselt wurde. Erst die getroffene Regel, der Listenabgleich und der Negativtest zeigen, ob die Ausnahme fachlich korrekt und eng genug ist.

Fehler eingrenzen und Änderungen zurückrollen

Bei einer Störung bleibt der Fall zunächst auf einen Client, eine Domain, einen Zeitpunkt, eine Firewall Rule und eine SSL/TLS Inspection Rule begrenzt.

• Zeigt der Browser eine Zertifikatswarnung, vergleicht man den sichtbaren Aussteller mit der CA des tatsächlich verwendeten DPI- oder Proxy-Pfads. Danach werden Client-Truststore, Root-/Subordinate-Chain und Hostname geprüft.
• Fehlen SSL/TLS-Events, kontrolliert man zuerst den Treffer der Firewall Rule und den Modus. Danach müssen Rules and policies > SSL/TLS inspection rules sowie Advanced settings > SSL/TLS engine > Enabled aktiv sein.
• Wird Traffic erlaubt, aber nicht entschlüsselt, sucht man von oben nach unten nach der festen Standard-Exclusion, Managed/Local List oder einer eigenen Don't decrypt-Regel. Anschliessend wird der Negativtest wiederholt.
• Greift der Webfilter nicht, wird die echte Firewall Rule auf Web Policy, Scan HTTP and decrypted HTTPS, Block QUIC protocol und DPI/Proxy-Modus geprüft. Eine vorhandene Web Policy beweist keine Decryption.
• Bricht nur eine Anwendung ab, liefern Fehlergrund, TLS-Version, Cipher, Zertifikatskette und Pinning den nächsten Entscheid. Eine temporäre Ausnahme bleibt eng und erhält ein Review-Datum.
• Steigt die Last, verkleinert man den Pilotumfang und vergleicht das gleiche Zeitfenster vor und nach der Änderung. Peak- oder Limit-Hinweise werden appliancebezogen bewertet.

Die SSL/TLS engine darf nur kurz zur Fehlersuche deaktiviert werden. Dann greifen keine SSL/TLS Inspection Rules, und die DPI engine wendet die Firewall-Web-Policy nicht auf HTTPS an; Proxy-HTTPS-Decryption bleibt davon unberührt. Das Deaktivieren ist daher kein gleichwertiger, risikoarmer Ersatz für eine gezielt deaktivierte Pilotregel.

Port-agnostic IPS nur mit bekanntem Vorzustand testen

SFOS prüft entschlüsselten Traffic standardmässig auf jedem TCP-Port gegen IPS-Signaturen. Bei einem reproduzierbaren Fehlalarm dokumentiert man Signature ID, Source, Destination, TCP-Port, Firewall Rule, Inspection Rule und SFOS-Build. Bevorzugt wird eine enge Signaturausnahme mit Action: Allow packet in der tatsächlich verwendeten IPS Policy; Sophos Firewall IPS einrichten und testen beschreibt diesen Weg.

Ein mögliches Fehlerbild der port-agnostischen Prüfung sind wiederholte Treffer derselben IPS-Signatur auf derselben Website. Die Wiederholung allein beweist keinen Fehlalarm. Man gleicht die genaue Signature ID und das Ziel in den Logs ab, prüft den betroffenen legitimen Arbeitsablauf und bewertet das Risiko, bevor eine eng begrenzte, reversible Signaturausnahme freigegeben wird.

Die umfangreichere Prüfung auf mögliche Bedrohungen kann die Last erhöhen und den Durchsatz für entschlüsselten HTTPS-Traffic gegenüber älteren Sophos-Firewall-Versionen geringfügig reduzieren. Das ist ein möglicher, versionsbezogener Effekt, kein garantierter Rückgang und kein Nachweis einer Regression des aktuell eingesetzten Builds. Zur Einordnung vergleicht man Durchsatz, CPU-/Speicherlast und Antwortzeit bei vergleichbarer Verkehrslast im gleichen Zeitfenster; ein einzelner Vergleich ersetzt keine Ursachenanalyse.

Der globale Vergleich in der Device Console ist nur zulässig, wenn der exakte aktuelle Wert on oder off bereits aus der Change-Dokumentation beziehungsweise einer verlässlich gesicherten Konfiguration bekannt ist. Die offizielle SFOS-22-Dokumentation nennt für diesen Schalter keinen Befehl zur Abfrage des aktuellen Zustands. Ist der Vorzustand unbekannt, wird der Test nicht ausgeführt.

Nur bei dokumentiertem Vorzustand on kann man für genau einen vorbereiteten Vergleich setzen:

set ips scan_decrypted_port_agnostic off
set ips scan_decrypted_port_agnostic on

Der zweite Befehl stellt hier ausschliesslich den bekannten Vorzustand on wieder her. War der Vorzustand off, darf man ihn nicht blind einschalten; dann ist off zu erhalten beziehungsweise nach jeder autorisierten Änderung exakt wiederherzustellen. Diese globale Einstellung betrifft die Firewall insgesamt und kann den Durchsatz leicht reduzieren beziehungsweise bei off den Prüfbereich verkleinern. Ergebnis und Zeitfenster werden dokumentiert, ohne daraus allein eine allgemeine Ursache abzuleiten.

Rollback in fester Reihenfolge

Ein Rollback stellt den dokumentierten Vorzustand her, statt eine neue Architektur einzuführen:

1. Vor dem Deaktivieren von TLS decrypt pilot client die dokumentierte nachfolgend matchende Regel und den genehmigten Wiederherstellungsplan prüfen: Eine nachgeordnete, breiter gefasste Decrypt-Regel kann übernehmen. Die Pilotregel deaktivieren und die dokumentierten pilotbedingten Änderungen an Firewall-Regeln, DPI/Proxy-Modus, Web Policy und globalen Einstellungen in der vorbereiteten Reihenfolge zurücksetzen, ohne gleichzeitig sachfremde Änderungen vorzunehmen.
2. Vom Pilotclient aus neue Verbindungen aufbauen und den dokumentierten ursprünglichen Matching-Pfad, den Zertifikatsaussteller, die Logs und die Anwendungsfunktion prüfen. Bestehende Sitzungen werden nicht als sofort neu bewertet vorausgesetzt. Falls eine nachgeordnete Decrypt-Regel übernimmt oder die Wiederherstellung fehlschlägt, den Rückbau stoppen: Der Rollback ist nicht abgeschlossen. Die tatsächlich matchende Regel ermitteln und nur die autorisierte Regelreihenfolge, die Kriterien und die Einstellungen wiederherstellen, die zum Reproduzieren des Vorzustands erforderlich sind; anschliessend diese Prüfungen mit neuen Verbindungen wiederholen.
3. Nur wenn der ursprüngliche Pfad nicht entschlüsselt wurde und der genehmigte Wiederherstellungsplan dies verlangt, eine zeitlich begrenzte, eng gefasste Don't decrypt-Regel für die Pilotquelle und die erforderlichen Ziele verwenden. Sie wird vor der unbeabsichtigt matchenden nachgeordneten Decrypt-Regel, aber unter den anwendbaren genehmigten Ausnahmen platziert. Sowohl ihren Positiv- als auch ihren Negativtest ausführen; keinen breiten Bypass improvisieren und keinen zuvor geprüften Pfad durch einen ungeprüften ersetzen.
4. Temporäre Ausnahmen, Testobjekte und nur für das Pilotprojekt eingerichtetes CA-Vertrauen beziehungsweise CA-Einstellungen erst zurückbauen, wenn die Wiederherstellung verifiziert und die Entfernung freigegeben ist. CA-Vertrauen, das der aktive Pfad weiterhin benötigt, bis zum erfolgreichen Abschluss dieser Prüfungen beibehalten; gemeinsam genutzte CAs werden nicht ohne Prüfung der Abhängigkeiten entfernt.
5. Rule ID, Client, Ziel, sichtbare CA, Log-Event, Zeitpunkt und wiederhergestellte Einstellungen im Change festhalten.

Die Web Policy darf konfiguriert bleiben, doch ohne Decryption kann sie den verschlüsselten HTTPS-Payload nicht scannen. Auf Web Proxy wird nur zurückgestellt, wenn genau dies der gesicherte Vorzustand war. Die ganze SSL/TLS engine wird nicht als Standard-Rollback abgeschaltet, weil dadurch sämtliche DPI-TLS-Regeln und die Anwendung der DPI-Web-Policy auf HTTPS ausfallen.

Der Rollout stoppt, sobald eine geschäftskritische Anwendung ausfällt, Zertifikatswarnungen ausserhalb der Pilotgruppe auftreten, der Scope unerwartet breit matcht oder Last und Fehler die vorab definierten Grenzen überschreiten. Erst wenn positiver Test, Ausnahme-Negativtest, Business-Anwendungen, Logs, Benutzerfeedback und Lastbild im vereinbarten Zeitraum passen, wird die Source-Gruppe schrittweise erweitert.

Im Betrieb werden Exclusions, TLS-Fehler, neue Anwendungen, Last und Benutzerfeedback in einem festgelegten Rhythmus geprüft. Temporäre Ausnahmen bleiben nur bestehen, wenn Owner, Grund und Review-Datum noch gültig sind; andernfalls werden sie nach einem erneuten Positiv- und Negativtest entfernt.

FAQ