marog-pixcells - Fotolia
Man-in-the-Middle-Angriffe auf SSL- und TLS-Verbindungen
Unternehmen setzen zunehmend HTTPS Inspection ein, um einen Einblick in verschlüsselte Verbindungen zu erhalten, die ihre Mitarbeiter nutzen. Das birgt jedoch Risiken.
Nicht jede neue Technologie erreicht immer genau die Ziele, die eine Organisation sich vorstellt. Das mag offensichtlich klingen, aber es muss trotzdem klargestellt werden. So können unter manchen Bedingungen technische Anpassungen, die ein Unternehmen vornimmt, zu unerwarteten Risiken und neuen Gefahren führen. Das trifft selbst dann zu, wenn damit dedizierte Nutzungen oder auch Geschäftsziele erreicht werden sollen.
Um diese Überlegungen näher zu erläutern, lässt sich als Vergleich die Renovierung einer Küche heranziehen. Wenn es zum Beispiel darum geht, die Küche zu modernisieren, werden meist nicht nur das Design, sondern auch die bisherige Einrichtung verändert: die Oberflächen werden getauscht, es werden neue Schränke installiert, ein neuer Boden wird verlegt und eventuell werden sogar neue Küchengeräte angeschafft.
Wie aber jeder weiß, der schon einmal eine größere Renovierung durchgeführt hat, können dabei unerwartete Probleme auftreten, die im Vorfeld niemand vorausgesehen hat. Zum Beispiel könnte im Laufe der Umsetzung entdeckt werden, dass eine Delle im Boden dafür verantwortlich ist, dass der Kühlschrank Flüssigkeit verliert oder dass sich hinter einer Wand noch Reste früherer Verkabelungen befinden.
Ähnliche negative Ergebnisse können auch in der IT-Welt auftreten. Relativ schnell entstehen auch dort Situationen, in denen es nötig ist, das eigentlich geplante Vorgehen an die Realität anzupassen, um trotzdem die selbstgesteckten Ziele zu erreichen. Genau wie bei der Renovierung einer Küche kann es auch in der IT dazu kommen, dass die Änderungen zu mehr Komplexität und zu gänzlich unerwarteten Problemen führen. Insbesondere die Überprüfung von HTTPS-Daten (Hypertext Transfer Protocol Secure) gehört zu den Bereichen, die in diesem Zusammenhang zu nennen sind.
Was genau ist HTTPS-Inspection?
Transport Layer Security (TLS), der Nachfolger von Secure Sockets Layer (SSL), wurde entwickelt, um einen verschlüsselten Kanal zwischen zwei Teilnehmern zu ermöglichen. Das Protokoll enthält deswegen Vorkehrungen für den Fall, dass jemand die übertragenen Informationen verändern, belauschen, unterbrechen oder anderweitig manipulieren will, um in die gesicherte Kommunikation einzubrechen.
Manchmal kommt es jedoch dazu, dass die Standardanwendung von TLS, also dass Person A ungestört mit Person B kommunizieren kann, nicht den Zielen einer Organisation entspricht. So ist es immer wieder erwünscht, die eingehenden Daten auf Malware zu überprüfen, den Application Traffic auf bekannte Angriffe zu scannen oder ausgehende Pakete auf Datenextraktion zu untersuchen. Diese Maßnahmen sind nicht leicht durchzuführen oder sogar unmöglich, wenn es um verschlüsselte Kanäle geht.
Das ist der Zeitpunkt, an dem die so genannte HTTPS-Inspection ins Spiel kommt. Dabei handelt es sich um eine Technik, die einem Man-in-the-Middle-Angriff (MITM) auf eine TLS-Verbindung stark ähnelt. Mit ihr wird beabsichtigt, eine sichere Verbindung zwischen zwei Teilnehmern zu unterbrechen und dabei wie ein Proxy zu funktionieren, der die Daten erneut verschlüsselt und weiterleitet.
Beim Einsatz von HTTPS-Inspection werden zwei statt nur eine TLS-Verbindung genutzt: Eine TLS-Sitzung zwischen dem Sender der Daten und dem MITM und eine weitere zwischen dem MITM und dem Ziel der Daten. Der Proxy verfügt dazu über ein Server-Zertifikat sowie einen privaten Schlüssel, um sichere Verbindungen mit den einzelnen Clients durchführen zu können. Auf der anderen Seite verfügt er ebenfalls über eine Client-TLS-Implementierung, mit der eine sichere Kommunikation mit dem Ziel der Daten möglich wird.
HTTPS-Inspection wird häufig auch für Cloud-Security-Tools verwendet. So sind zum Beispiel viele auf SaaS (Software as a Service) ausgerichtete Sicherheitslösungen nach dem Proxy-Modell aufgebaut. Das dient dann etwa dazu, die Daten zwischen einem Client und dem SaaS zu verschlüsseln, um die Aktivitäten der Nutzer innerhalb der SaaS-Umgebung zu überwachen, um bestimmte Ereignisse im Blick zu behalten sowie für einige andere Zwecke. Aus Sicht des Kunden ist in einer SaaS-Umgebung alles unterhalb von Layer 7 vergleichbar mit einer Black Box, in die er keinen Einblick hat. Aus diesem Grund sind diese Sicherheitsmaßnahmen auch schwer zu umgehen.
Risiken durch unbedachte Implementierungen
Das US-CERT wurde darauf hingewiesen, dass dieses Proxy-Szenario auch zu Sicherheitsproblemen führen kann. So beschreibt der im März 2017 veröffentlichte Alert TA17-075A mehrere mögliche Gefahren, die sich aus dieser Vorgehensweise und dem Einsatz von HTTPS-Inspection ergeben. Die Empfehlungen des US-CERT basieren auf dem Whitepaper The Security Impact of HTTPS Inspection, das die negativen Auswirkungen des MITM-Modells auf die Sicherheit von TLS-Verbindungen ausführlich beschreibt.
So werden in bestimmten Fällen Warnungen während einer TLS-Verbindung ausgegeben. Gründe dafür sind unter anderem demnächst ablaufende Zertifikate, nicht übereinstimmende Namen oder andere Probleme. Normalerweise weist der Browser auf diese Sicherheitsrisiken hin und macht den Anwender darauf aufmerksam, dass hier möglicherweise eine Gefahr besteht. Weil der Proxy aber seine eigene Verbindung zu dem entfernten Host aufgebaut hat und in der Regel keine Möglichkeit besteht, diese Warnungen an den Client weiterzureichen, wird dieser normalerweise nicht über die Gefahren informiert.
Der Proxy könnte aber auch in einer Art konfiguriert sein, die nicht den Vorstellungen des Anwenders entspricht. So können etwa unterschiedliche Ansichten über die Vertrauenswürdigkeit bestimmter Zertifikate bestehen. Andere mögliche Probleme sind Nachlässigkeiten bei der Überprüfung zurückgerufener Zertifikate, eine Unterstützung mittlerweile veralteter und nicht mehr als sicher angesehener Protokolle und die Nutzung schwacher Verschlüsselungsalgorithmen.
Aus diesen Gründen ist es wichtig, dass Organisationen sich bis ins Detail darüber klar sind, wo in welchen Umfang diese Methoden genutzt werden. Nur so können sie die Implementierung überprüfen, Fehler finden, alternative Strategien entwickeln oder einen Wechsel auf andere Protokolle durchführen, die nicht auf den Einsatz von Proxy-Servern angewiesen sind. Aber wie lassen sich diese Schritte erreichen?
HTTPS Inspection – Risiken erkennen
Zum Beispiel könnte eine umfassende und systematische Analyse durchgeführt werden, um damit herauszufinden, wo überhaupt überall im Unternehmen HTTPS Inspection eingesetzt wird. Im Idealfall lassen sich alle genutzten Instanzen identifizieren, gezielt überprüfen und mit Hilfe der CERT-Empfehlungen verbessern. In manchen Fällen gibt es aber nur unzureichende Aufzeichnungen über den Einsatz dieser Kontrollen, so dass Kreativität gefragt ist.
Ein guter Startpunkt sind hier die X.509v3-Zertifikate, die für den Proxy-Einsatz verwendet werden. Sie werden benötigt, da der Client in der Lage sein muss, dem Serverzertifikat auf der anderen Seite der mit TLS abgesicherten Kommunikation zu vertrauen. Dieses Serverzertifikat muss von einer internen oder externen Certificate Authority (CA) erstellt und unterzeichnet worden sein. Ausnahmen sind Fälle, in denen eine bestimmte Abteilung den Einsatz des Proxies verbergen will.
Im Angesicht der teilweise gravierenden Gefahren, die durch diese Praxis auftreten können, sollten alle neu eingeführten Kontrollen oder Applikationen genau auf ihre Risiken überprüft werden. Nur so kann sichergestellt werden, dass sie den Sicherheitsvorgaben eines Unternehmens entsprechen und keine neuen Probleme verursachen. Sollte eine Organisation bereits HTTPS-Inspection einsetzen oder dies für die Zukunft planen, ist es deswegen absolut notwendig, die Implementierung genauestens zu prüfen.
Folgen Sie SearchSecurity.de auch auf Twitter, Google+, Xing und Facebook!
