Was ist ein SSL-Inspection-Bypass?
Ein SSL-Inspection-Bypass ist eine gezielte Ausnahme, mit der bestimmte Anwendungen oder Domains von der SSL/TLS-Inspection ausgenommen werden. Der häufigste Grund ist Certificate Pinning: Anwendungen, die das Server-Zertifikat fest im Code hinterlegt haben, akzeptieren das dynamisch ausgestellte Inspektions-Zertifikat nicht und brechen die Verbindung ab. Die Ausnahme lässt diese Verbindungen unentschlüsselt passieren, während der übrige Verkehr geprüft bleibt. Richtig eingesetzt ist ein Bypass ein Präzisionswerkzeug: so eng wie möglich gefasst, mit dokumentiertem Grund und regelmäßiger Überprüfung, ob es ihn noch braucht.
SSL-Inspection-Bypass im Detail
Bei aktiver SSL-Inspection stellt Zscaler dem Client für jede geprüfte Verbindung ein Zertifikat aus, das die Intermediate-CA des Tenants signiert. Browser vertrauen dem, sobald das Zertifikat im Trust Store verteilt ist. Anwendungen mit Certificate Pinning vergleichen dagegen mit dem fest hinterlegten Original und beenden die Verbindung nach dem TLS-Handshake, häufig mit einem Zertifikatsfehler oder schlicht ohne Meldung. Zscaler führt eine offizielle Liste betroffener Anwendungen, von Adobe-Diensten bis zu Mobil-Apps.
Für die Ausnahme nennt die Zscaler-Dokumentation zwei Wege: die Cloud-Anwendung als Ganzes von der Inspection ausnehmen oder einzelne Domains über eine eigene URL-Kategorie. Wichtig ist die Abgrenzung zum kompletten Zscaler-Bypass über PAC-Datei oder App-Profil: Die Inspection-Ausnahme bleibt im Zscaler-Datenpfad und behält URL-Filter und weitere Kontrollen, der Komplett-Bypass verlässt ihn ganz.
Warum sind SSL-Inspection-Bypasses im Zscaler-Betrieb wichtig?
Bypasses entscheiden über zwei Dinge zugleich: Verfügbarkeit und Sichtbarkeit. Fehlt eine nötige Ausnahme, steht eine Fachanwendung still und der Helpdesk sucht die Ursache oft in WLAN, VPN oder Serverstatus, während der Abbruch tatsächlich am Pinning liegt. Existieren umgekehrt zu viele Ausnahmen, entsteht ein wachsender blinder Fleck: Verkehr, den niemand mehr auf Schadcode oder Datenabfluss prüft.
In der Praxis sammeln sich Bypasses schleichend an: eine Ausnahme für ein Projekt, eine für einen Test, eine auf Zuruf. Nach zwei Jahren weiß niemand mehr, welche davon noch gebraucht werden. Deshalb gehört zu jedem Bypass ein Eintrag mit Grund, Datum und Verantwortlichem sowie ein fester Review-Zyklus. So bleibt die Inspection-Abdeckung ein bewusster Zustand und kein Zufallsprodukt der Ticket-Historie.
Typische Fehlerquellen
- Ganze Domains oder Kategorien ausnehmen, wo einzelne Hostnamen genügen: Die Ausnahme wird unnötig breit.
- Bypass statt Inspection-Ausnahme: Der Komplett-Bypass an Zscaler vorbei nimmt auch URL-Filter und Richtlinien mit, nicht nur die Entschlüsselung.
- Ausnahmen ohne Dokumentation: Ohne Grund und Datum kann später niemand entscheiden, ob die Ausnahme weg kann.
- Pinning-Fälle als Netzwerkproblem behandeln: Der Abbruch nach dem Handshake wird mit WLAN- oder Serverproblemen verwechselt und das Ticket dreht Schleifen.
SSL-Inspection-Bypass in der Praxis: so hilft CentaurNexus
Ob eine bestimmte URL wirklich an Zscaler vorbeiläuft oder nur von der Entschlüsselung ausgenommen ist, beantwortet CentaurNexus ohne Rätselraten. PAC-Lens liest die tatsächlich aktive PAC-Datei aus dem Tenant und zeigt per Test-URL, welche Zeile greift und ob der Verkehr direkt oder über Zscaler läuft. Wie sich eine einzelne Adresse per Test-URL live prüfen lässt, zeigt unser rund zweieinhalbminütiges Video zum PAC-Tester. Connectivity Triage Map ordnet dazu ein, ob ein gemeldetes Problem am Gerät, am Netz oder an einer Richtlinie hängt. So wird aus der Frage „Warum geht diese App nicht?“ ein belegbarer Befund statt einer Vermutung. Wie Nutzer Verbindungsfaelle vorab selbst pruefen, zeigt der Beitrag Zscaler-Self-Service direkt im Browser.
Verwandte Begriffe
Häufige Fragen zum SSL-Inspection-Bypass
Solche Apps prüfen, ob das Server-Zertifikat exakt zu einem fest hinterlegten Zertifikat passt. Bei aktiver SSL-Inspection stellt Zscaler der App aber ein dynamisch ausgestelltes Zertifikat der Intermediate-CA zu. Das passt nicht zum hinterlegten Original, die App bricht die Verbindung ab. Zscaler dokumentiert betroffene Anwendungen in einer offiziellen Liste.
Laut Zscaler-Dokumentation gibt es zwei Wege: die betroffene Cloud-Anwendung von der SSL/TLS-Inspection ausnehmen oder die einzelnen Domains über eine eigene URL-Kategorie ausnehmen. Bewährt ist der spitzeste Weg: nur die tatsächlich nötigen Domains, mit dokumentiertem Grund und Datum, damit die Ausnahme später überprüfbar bleibt.
Eine SSL-Inspection-Ausnahme lässt den Verkehr weiter durch Zscaler laufen, nur eben unentschlüsselt; URL-Filter und weitere Kontrollen greifen weiterhin. Ein Bypass in der PAC-Datei oder im App-Profil schickt den Verkehr dagegen komplett an Zscaler vorbei. Das ist der deutlich größere Eingriff und sollte die seltene, gut begründete Ausnahme bleiben.
Jede Ausnahme ist ein blinder Fleck: Inhalte in ausgenommenen Verbindungen werden nicht auf Schadcode oder Datenabfluss geprüft. Einzeln und begründet ist das vertretbar, gefährlich wird die schleichende Ansammlung über Jahre. Deshalb gehören Bypasses inventarisiert, mit Grund dokumentiert und regelmäßig überprüft, ob es sie noch braucht.
Typisches Muster: Die Website funktioniert im Browser, die zugehörige Desktop- oder Mobil-App verbindet sich nicht oder meldet einen Zertifikats- oder Verbindungsfehler. Der Abbruch passiert direkt nach dem TLS-Handshake. Ein Abgleich mit der offiziellen Zscaler-Liste gepinnter Anwendungen und ein Blick in die Client-Logs erhärten den Verdacht.
- Zscaler Help Portal: Certificate Pinning and SSL/TLS Inspection (inkl. Liste gepinnter Anwendungen) - help.zscaler.com
- Zscaler Help Portal: Understanding SSL/TLS Inspection - help.zscaler.com
Hinweis: CentaurNexus ist ein unabhängiges Produkt der SourcingBlox GmbH und kein Angebot von Zscaler, Inc. Produkt- und Markennamen gehören ihren jeweiligen Inhabern.