SSL-Inspection

Zugriffe von Anwendern ins Internet sind heute überwiegend TLS/SSL-verschlüsselt und dank Let's Encrypt kostet ein Zertifikat nicht einmal Geld. Als Firma haben Sie aber ein berechtigtes Interesse auch diese Verbindungen zu kontrollieren, um den Download von Malware oder die Ausleitung von Firmendaten zu erkennen und zu unterbinden. Was hat es aber mit SSL-Inspektion u.a. auf Sicht, wie geht das und wo macht es keinen Sinn oder ist sogar verboten?

Beachten Sie dazu auch die Seite Risiko SSL-Inspection

Direkte TLS-Verbindung

Starten wir einfach mit einer direkten Verbindung ohne jegliche Inspektion. Wenn ein Client sich mit einem Service verbindet und dabei einen verschlüsselten Kanal aufbaut, dann folgt dies im Grund immer dem gleichen Schema:

  • TCP-Handshake
  • TLS-Handshake
  • verschlüsselte Datenübertragung

TLS ist aber nicht auf TCP beschränkt. Ein TLS-Handshake kann auch über UDP oder andere Protokolle genutzt werden. Technisch ist es ja nur ein Baustein in der Kommunikation um die Datenströme abzusichern.

Es ist eine direkte Verbindung vom Client zum Server und ein Filter oder Inspektor kann nur folgendes sehen und theoretisch blockieren.

  • Source-IP:Port und Ziel-IP:Port
  • DNS-Anfrage mit dem Namen und der IP-Adresse als Antwort
  • TLS Client-Hello mit dem SNI-Namen
    Siehe TLS Handshake mit NetMon

Eine Inspektion des Inhalts oder Veränderungen auf dem Übertragungsweg sind ist nicht möglich. Der Client kann das Zertifikat prüfen und sogar ein eignes Clients-Zertifikat zur Anmeldung einsetzen.

Proxy

Wenn ich einen HTTP-Proxy unterstütze, dann funktioniert das ohne TLS bislang so dass der Client eine TCP-Verbindung zum Proxy aufbaut und dann einen "GET zielsystem.tld" absendet. Der Proxy sieht, dass er nicht selbst gemeint ist und baut seinerseits eine Verbindung zum Ziel auf und liefert die Daten zurück.

Das ohne Verschlüsselung schon immer funktioniert, wird mit TLS etwas kniffliger. Der Schutz von TLS beruht ja darauf, dass niemand mitlesen kann. Aber das eine ist der "HTTP GET" in der Nutzlast und das andere ist der Transport über eine TLS-Verbindung. Wenn mein Client eine TLS-Verbindung über den Proxy aufbauen will, dann kann der Proxy ja schlecht eine TLS-Verbindung zu einem Ziel aufbauen, welches er nicht kennt. In dem Fall muss der Proxy die TLS-Verbindung des Clients terminieren und in den Daten dann den "HTTP GET" zum Ziel auslesen und dorthin eine eigene Verbindung aufbauen.

Das ist durchaus möglich aber der Proxy muss nun dem Client ein TLS-Zertifikat vorweisen, dem der Client vertraut. Es dürfte aber sehr unwahrscheinlich sein, dass ihr Proxy aber ein öffentliches Zertifikat für z.B. https://www.postbank.de bekommt. Das geht dann nur mit einer PKI , denen ihre Clients vertrauen. Bei Umbrella sieht das dann so aus

Das funktioniert natürlich nicht mit Webseiten, die per TLSA ein Zertifikat vorschreiben oder z.B. Apps mit aktivem Zertifikat-Pinning und damit fremde Zertifikate erkannt werden. Durch die Entschlüsselung und Neuverschlüsselung funktionieren natürlich auch Client-Zertifikate oder MTLS nicht mehr.

Proxy CONNECT

Um diese Probleme zu umgehen gibt es die "CONNECT"-Funktion, die allerdings der Client und der Proxy unterstützen müssen. Das ist aber in der Regel der Fall. Der Client verbindet sich wie bisher zum Proxy per TCP oder TLS und sendet dann aber keinen "GET <zieladdresse>" sondern ein "CONNECT <zieladresse>", was den Proxy dann anweist, eine transparente Verbindung zum Zielsystem aufzubauen und alle folgenden Bits und Bytes direkt 1:1 zum Client zu leiten. Der Client kann dann mit dem Zielsystem direkt kommunizieren und einen eigenen TLS-Handshake starten. Das geht sogar mit mehreren Proxy-Servern, die einfach mit weiteren CONNECT-Anweisungen eine Kette aufbauen.

Das Problem ist hier natürlich auch wieder, dass der Proxy Server nur den Namen des Ziels sieht aber da der TLS-Handshake transparent erfolgt, kann der Proxy nicht in die Daten reinschauen. Eine Inhaltsanalyse ist nicht möglich aber der Hostname kann schon helfen, um z.B. Zugriffe zu "<meintenant>.sharepoint.com" zu erlauben während Zugriff auf andere Webseiten unterbunden sind. Auch kann der Client sich mit Zertifikaten (MTLS) authentifizieren.

Allerdings ist die CONNECT-Methode nur über TCP möglich, d.h. über UDP z.B.: für QUIC (QUIC - UDP mit TLS statt TCP) geht nicht und jede CONNECT-Verbindung ist tatsächlich eine TCP-Connection mit einem eigenen Port. Denken Sie dabei an das NAT-Limit ihrer Firewall oder Proxy-Server, bei der pro Source-IP in der Regel nur ca. 50.000 Connections (65535 Port-Limit) möglich sind.

Wenn der Proxy und der Client es unterstützen, sind im Prinzip auch andere Protokolle möglich, z.B. WebSockets und WebRTC. Das kann auch unerwünscht sein, wenn ein Client z.B.: eine TLS-Verbindung zu einem Remoteserver Port 25 öffnet und Mails sendet oder sonstige Server mit fremden Protokollen verwendet. Prüfen Sie, dass der Proxy und die vorgelagerte ausgehende Firewall nur Verbindungen zu erlaubten Ports und Systeme erlaubt.

Proxy Inspection

Der Weg über einen Proxy mit "CONNECT" ist heute eigentlich Standard, wenn ein Proxy mit TLS genutzt werden soll. Allerdings sieht der Proxy hier nur die ClientIP:Port und das gewünschte Zielsystem. Optional kann der Proxy beim CONNECT natürlich noch mit einem "407 Proxy authentication Required" antworten und so den Benutzer authentifizieren. Er sieht aber nicht mehr die einzelnen abgerufenen URLs oder gar übertragenen Nutzdaten.

Für viele Firmen ist dies kein ausreichender Schutz und daher werden zumindest nicht vertrauenswürdige URLs vom Proxy aufgebrochen. Auch wenn der Client einen "CONNECT" sendet, so klemmt sich der Proxy in den ausgehenden TCP-Stream ein und bricht die Verbindung auf. Dazu muss der Proxy natürlich ein Webserver-Zertifikat für die vom Client angesprochene Seite dynamisch erstellen und dem Client ausliefern, damit er die dann vom Client verschlüsselt gesendeten Daten decodieren und dann über eine eigene Verbindung zum Ziel verschlüsseln kann.

Meist ist der Proxy dazu eine Issuing-CA mit einem Zertifizierungsstellenzertifikat von einer RootCA. Natürlich ist das keine "öffentliche CA", sondern eine private RootCA, die dann auf allen Client entsprechend einzutragen ist. Einige Proxy-Server sind auch direkt eine RootCA, die sich selbst die Webserver-Zertifikate ausstellt.

Das funktioniert nur, wenn der Client der ausstellenden Zertifizierungsstelle vertraut. Wenn Sie einen Client verwenden, der z.B.: per DHCP oder DNS eine WPAD-Datei zum Proxy bekommt aber nicht dieser Proxy-RootCA vertraut, dann wird er eine Zertifikatswarnung sehen. Selbst wenn die Clients dem vom Proxy untergeschobenen Zertifikat vertrauen, kann der Anwender dies dennoch herausfinden, indem er einfach im Browser den Aussteller und die Chain prüft.

Transparente Inspektion

Was machen Sie nun aber mit Systemen, die keinen Proxy unterstützen oder die Konfiguration nicht passt. Diese Systeme versuchen per DNS das Ziel aufzulösen, bekommen die öffentliche IP-Adresse und versuchen dann eine TLS-Verbindung. Sie können diese natürlich mittels Firewall anhand der IP-Adresse unterbinden. Ein Eingriff in die Namensauflösung ist nicht sicher, denn der Anwender könnte ja eine HOSTS-Datei oder DNS over HTTP o.ä. verwenden.

Die Pakete müssen aber natürlich durch die Firewall und ggfls. eine NAT-Umsetzung. Es gibt Firewalls die solche Versuche erkennen und die Verbindung auf einen Proxy umleiten oder gleich selbst als Proxy fungieren und optional auch selbst erstellte Zertifikate ausliefern. Der Client "glaubt" in dem Fall, dass er tatsächlich eine Verbindung mit dem Zielsystem hat und merkt gar nicht, dass die Firmenfirewall die Verbindung aufbricht.

Gerade mit aktiviert SSL-Inspection kann aber auch hier ein Anwender anhand des Zertifikats erkennen, dass er nicht beim richtigen Server gelandet ist und wenn er z.B. mit Wireshark umgehen kann, dann könnte er auch anhand der Latenzzeit eines Pakets und das darauffolgende ACK erkennen, dass die Gegenstelle eher nah denn fern steht.

Kein MTLS bei Inspection

Bei der ganzen Inspektion von TLS-Verbindungen müssen Sie aber daran denken, dass es auch Verbindungen mit Client-Zertifikaten gibt. Diese werden landläufig als "Mutual TLS" (MTLS) bezeichnet und hier weist sich nicht nur der angesprochene Server sondern auch der Client mit einem Zertifikat aus. Das funktioniert nur, wenn es eine direkte Verbindung zwischen den Servern gibt oder die Verbindung über einen "kompatiblen" Proxy läuft. Kompatibel bedeutet hier die Nutzung von "CONNECT", bei dem letztlich die TLS-Verbindung zwar über den Proxy aber dennoch zwischen dem Client und dem Zielsystem aufgebaut wird. Hier ist dann keine weitergehende SSL-Inspection auf Inhalte möglich.

Solche Verbindungen sind gar nicht einmal ungewöhnlich und die TLS-Inspektion beschränkt sich ja nicht auf HTTP. Auch andere Protokolle nutzen TLS und Firewalls können diese auch ohne Proxy aufbrechen, z.B.

  • Exchange Hybrid und SMTP
    Wenn Exchange OnPremises und Exchange Online per SMTP- Mails über einen "Org Connector" austauschen, dann authentifizieren sie sich gegenseitig über Zertifikate
  • Azure IoT Hub
    Auch IoT-Geräte können vom Azure IoT Hub bei der Registrierung ein Device-Zertifikat bekommen, mit dem Sie sich dann bei nachfolgenden Verbindungen per MTLS ausweisen. So brauchen Sie keine Benutzernamen/Kennworte zu pflegen.
  • Browser/Smartcard-Anmeldung
    Natürlich können sich auch Browser bei Webseiten oder Windows Clients und VPNs per "MTLS" an der Gegenstelle anmelden

MTLS ist schon eine interessante Anmeldung, da der Server damit auch den Client nicht nur authentifiziert sondern auch identifizieren kann. 

Exchange Extended Protection

Exchange 2019 hat "Exchange Extended Protection" Anfang 2023 eingeführt und im Herbst 2023 dann als neuen Default gemacht. Damit Angriffe auf eine TLS-Verbindung erschwert werden, bezieht der Exchange Server nun auch das Zertifikat in die Schlüsselaushandlung der Verbindung mit ein. Das bedeutet ,dass die TLS-Verbindung nur dann funktioniert, wenn der Client das Zertifikat bekommt, mit dem der Exchange Server auch die Informationen schützt. Das ist schon für den Betreiber von Exchange knifflig, wenn er Loadbalancer vor seinen Exchange Servern betreibt. Diese können zwar TLS aufbrechen aber dürfen kein "Offloadig" machen und benötigen zudem das identische Zertifikat, welches auch die Exchange Server dahinter verwenden.

Das Schlüsselmaterial im Zertifikat ist Teil des TLS-Handshake und der ausgetauschten Schlüssel. Wenn nun eine Firewall oder ein Proxy die Verbindung auftrennt, um reinzuschauen, dann sind es unterschiedliche Schlüssel und die Verbindung kommt nicht zustande.

Diese Aussage muss ich bei Gelegenheit noch einmal prüfen, ob das in allen Fällen wirklich so ist oder ob ein Proxy z.B. ein Downgrade durchführen kann.

TLS 1.3

TS 1.3 ist wieder einmal "sicherer" als TLS 1.2. Das wird zum einen um besser Cipher-Suites und Hash-Funktionen, längere Schlüssel und Abschaltung schwacher Verfahren erreicht. Aber bis TLS 1.2 konnten Lauscher auf der Leitung neben den IP-Adressen der Clients und Server auch die angesprochenen Server-Namen im Klartext sehen. Im Client-Hello ist der angefragt Servername zu sehen, damit der Webserver das passende Zertifikat ausliefern kann. Das ist insbesondere für Serverfarmen und Content Delivery Networks (CDN) wichtig, die hinter einer IP-Adresse sehr viele unterschiedliche Dienste bereitstellen.

Mit TLS 1.3 ist der Name nicht mehr sichtbar, sondern schon vor dem Handshake verschlüsselt. Das bedeutet, dass eine Inspection nur noch die IP-Adresse und Ports aber über den Weg nicht mehr die Namen der angesprochenen Server ermitteln kann.

Dies gilt natürlich nur, wenn Client und Server auch TLS 1.3 erzwingen und der Proxy dies nicht kann. Eine Firma mit TLS 1.3-tauglichen Proxy kann natürlich weiter eigene Zertifikate ausstellen und reinschauen. Nur transparent Proxy-Server oder Firewalls sehen diese Daten dann nicht mehr. 

QUIC

Zuletzt noch zu dem neuen Verfahren QUIC mit dem HTTP-Verbindung über UDP statt TCP übertragen werden. Auch über QUIC und UDP wird natürlich ein TLS-Handshake wie bisher genutzt. UDP ist ja nur ein anderes Übertragungsprotokoll zum Transportieren der TLS-Pakete. QUIC macht aber ein eigenes Multiplexing, so dass es für einen Kabelscanner schon knifflig wird, die Daten zu analysieren.

Erst mit einem Proxy-Server kann dieser erst einmal den Verbindungsaufbau steuern und filtern, da er ja den Zielnamen wissen muss und er kann die Verbindung theoretisch auch umsetzen. Allerdings muss es dazu erst einmal einen QUIC-Proxy geben. Ich habe eine IETF-Arbeitsgruppe gefunden, die unter dem Namen "MASQUE" einen Proxy für QUIC entwirft.

Aus einem YouTube-Video habe ich zwei Bilder rausgezogen, die aber sehr gut zeigen, dass der Proxy sich an der CONNECT-Methode orientiert. Der Client baut eine Verbindung zum Proxy auf, die dann aber als "Tunnel" und Transporteur für eine zweite QUIC-Verbindung direkt vom Client zum Server dient. Der Proxy ist hier wirklich nur "Weiterleiter" und sieht ansonsten nicht mehr viel.


Quelle: CoNEXT EPIC Workshop 2021 https://epiq21.github.io/, https://youtu.be/GKpl3isJHPg?t=31


Quelle: CoNEXT EPIC Workshop 2021 https://epiq21.github.io/, https://youtu.be/GKpl3isJHPg?t=254

Aktuell können Sie QUIC noch einfach verbieten, indem wie ausgehende Pakete auf Port 443/UDP unterbinden. Aber mehr und mehr Dienste sind auch per QUIC erreichbar und sie sollten mittelfristig diese Funktion zumindest für Dienste erlauben, denen Sie vertrauen.

In der Microsoft Dokumentation zu den IP-Adressen von Office 365 steht QUIC übrigens schon drin.


Quelle: https://learn.microsoft.com/de-de/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#exchange-online

Microsoft 365 und SSL-Inspection

TLS-Inspektion ist immer dann wichtig, wenn Sie neben dem sowieso erforderlichen Schutzlösungen auf den Clients auch noch zusätzlich auf dem Übertragungsweg eine Kontrollinstanz gegen Malware und andere unerwünschte oder nicht erlaubte Dateien und Informationen einziehen wollen. Das ist auch unstrittig, denn das Internet ist voll von Inhalten, die sie gefährden. Dazu zählen natürlich auch Microsoft 365 Tenants anderer Firmen.

Ob dazu aber auch die Daten in ihrem eigenen Tenant gehören, müssen Sie selbst entscheiden. Die wenigsten Firmen hatten in der "Vor Cloud Zeit" eine TLS-Inspection zwischen Client und lokalen Servern eingerichtet. Der Cloud-Service ist genau genommen nur ein Server und Service, den Sie vom Cloud-Anbieter auf Zeit gemietet haben. Dort liegen aber ihre eigenen Daten, die Sie dorthin migriert haben und dort weiter bearbeiten.

Eine Inspektion kostet ja auch Zeit und Ressourcen, um Daten zu scannen, die ihre Anwender tagtäglich bearbeiten.

Microsoft unterscheidet bei seinen Zielen nach "Optimieren", "Zulassen" und "Standard". Bei Optimieren und Zulassen sollten Sie auf SSL-Inspection verzichten. Nur die Ziele mit "Standard" sind entweder so unkritisch hinsichtlich Bandbreite, Latzenzzeit und Authentifizierung, dass Sie hier keine Allow-Liste für pflegen müssen.

Weitere Links