Inspektion von HTTPS-Verbindungen: Fluch oder Segen? (Teil 2)

Inspektion von HTTPS-Verbindungen: Fluch oder Segen? (Teil 2)

Auch unsichere Websites können das HyperText Transfer Protocol Secure (HTTPS) verwenden. Daher lassen sich bösartige Aktivitäten unter etablierter Verschlüsselung nicht ausschließen. Durch Inspektion von HTTPS-Verbindungen können schädliche Inhalte auch in verschlüsselten Verbindungen gefunden werden. Wie Sie mögliche Fallstricke vermeiden, erfahren Sie im zweiten Teil unseres Beitrags.

Inspektion von HTTPS-Verbindungen

Die Inspektion von HTTPS-Verbindungen ist sehr ähnlich zu einem Man-In-The-Middle-Angriff. Der wesentliche Unterschied ist aber, dass hier kein böser Angreifer die Verbindung aufbricht, sondern eine vertrauenswürdige Instanz wie die Firewall. Diese Instanz fungiert als Zertifizierungsstelle (CA) und erstellt für jedes originale Zertifikat vom Server ein neues Zertifikat, welches von dieser Proxy-CA unterschrieben wurde. Da die Proxy-CA als vertrauenswürdig in die Trust Stores der Browser und Betriebssysteme hinzugefügt wird, erfolgen auch keine Meldungen über fehlgeschlagene Authentisierung.

Legale Inspektion von HTTPSLegale Inspektion von HTTPS in der Firewall

Natürlich ist es jetzt Aufgabe der Firewall, eine korrekte Authentisierung des Servers vorzunehmen sowie kryptografisch starke Verschlüsselungsverfahren zu wählen. Denn anderenfalls ist ein Man-In-The-Middle-Angriff zwischen der Firewall und dem Server möglich.

Sicherheitsprobleme durch Inspektion von HTTPS

Bedingt durch die Funktionsweise der HTTPS-Inspektion stehen dem Client einige Informationen nicht mehr zur Verfügung. Diese wären aber für eine Entscheidung über das in das Zertifikat gesetzte Vertrauen sinnvoll. Das betrifft insbesondere die Sonderbehandlung der beliebten EV-Zertifikate (Extended Validation), welche von größeren Websites genutzt werden und eine höhere Vertrauensstellung suggerieren sollen. Da aber nur bestimmte, im Browser fest hinterlegte Zertifizierungsstellen derartige Zertifikate ausstellen dürfen, kann die Proxy-CA im Firewall keine EV-Zertifikate ausstellen.

EV-Zertifikate im Original und nach HTTPS-InspektionEV-Zertifikate im Original (oben) und nach HTTPS-Inspektion (unten)

Da alle vom Client empfangenen Zertifikate von der Proxy-CA ausgestellt wurden, kann der Client auch nicht mehr erkennen, welche CA ursprünglich das Zertifikat ausgestellt hat. Daher muss sich der Client darauf verlassen können, dass die Firewall nur wirklich vertrauenswürdige Zertifizierungsstellen akzeptiert. Das gleiche gilt für die benutzten Verschlüsselungsverfahren: Auch hier kann der Client nicht sehen, welche Verschlüsselung zwischen Firewall und Server genutzt wird und muss sich darauf verlassen, dass diese sicher ist. Ebenfalls geschwächt ist das Zertifikats-Pinning, bei dem der Browser normalerweise exakt ein bestimmtes Zertifikat bzw. eine bestimmte CA für den Zugriff auf eine Website erwartet: Wird HTTPS-Inspektion genutzt, so akzeptieren aktuelle Browser zusätzlich zu den eigentlich erwarteten Zertifikaten auch die von der Proxy-CA ausgestellten Zertifikate.

Diese Einschränkungen stellen durchaus eine Schwächung der ursprünglichen Ende-zu-Ende-Sicherheit dar. Da die Inspektion der mit HTTPS übertragenen Daten in der Firewall aber auch einen Sicherheitsgewinn darstellt, werden diese Einschränkungen im Allgemeinen als akzeptabel empfunden. Problematischer wird es aber, wenn bei der Inspektion gravierende Fehler gemacht werden und so ein Man-In-The-Middle-Angriff möglich wird. Dass derartige Fehler erschreckend oft vorkommen, zeigen zwei Veröffentlichungen aus der letzten Zeit: Killed by Proxy: Analyzing Client-end TLS Interception Software von 2016 und The Security Impact of HTTPS Interception von 2017. Auf Grund der dort berichteten Schwachstellen fühlte sich sogar das US-Cert gezwungen, eine explizite Warnung herauszugeben: HTTPS Interception Weakens TLS Security.

Die wesentlichen in diesen Veröffentlichungen beschriebenen Probleme zeigen eine unzureichende Authentisierung des Servers. Dabei wird in den schlimmsten Fällen keinerlei Validierung des Zertifikats durchgeführt. Teilweise wird nicht überprüft, ob der Name im Zertifikat zum gewünschten Ziel passt und häufig werden abgelaufene Zertifikate akzeptiert oder nicht überprüft, ob das Zertifikat gesperrt wurde. Daneben gibt es noch Probleme bei der Qualität der benutzten kryptografischen Verfahren, die im schlimmsten Fall sogar so alt und schwach sind, dass auch darüber Man-In-The-Middle-Angriffe durchgeführt werden können. Und es gibt auch die Fälle, bei denen ein Firewall-Hersteller exakt die gleiche Proxy-CA für viele Kunden nutzt, anstatt dass die Proxy-CA vollständig unter Kontrolle des jeweiligen Kunden ist.

Inspektion von HTTPS in der Firewall genugate

Auch die High Resistance Firewall genugate bietet die Möglichkeit für eine Inspektion von HTTPS. Wir sind uns sicher, dass wir in aktuellen Produktversionen keine der beschriebenen gravierenden Fehler machen, welche die Sicherheit deutlich reduzieren.

Standardmäßig wird auf der genugate eine strikte Authentisierung der Zertifikate durchgeführt. Dabei legt der Administrator explizit fest, welche Zertifizierungsstellen als vertrauenswürdig erachtet werden. Zertifikate, welche ungültig sind, nicht von einer vertrauenswürdigen CA ausgestellt wurden, abgelaufen sind oder explizit gesperrt wurden oder bei denen das Zertifikat nicht für das vom Client übermittelte Ziel ausgestellt wurde, werden standardmäßig abgelehnt. Es ist aber möglich und in einigen Situationen auch sinnvoll, derartige Zertifikate für eine einzelne Firewall-Policy explizit zu erlauben, sodass trotz Fehlern bei der Authentisierung eine Verbindung möglich ist. Dabei wird jedoch für das fehlerhafte Zertifikat kein von der Proxy-CA unterschriebenes Zertifikat, sondern ein sogenanntes selbst-signiertes Zertifikat augestellt. Dieses führt dazu, dass es vom Client nicht als vertrauenswürdig erachtet wird. Das heißt, dass auf der Firewall festgestellte fehlende Vertrauen in das Zertifikat wird an den Client weitergegeben. Dieser kann dann entscheiden, ob eine explizite Ausnahme eingerichtet wird. Dieses Vorgehen unterscheidet sich von dem Verhalten einiger anderer Firewalls, bei denen in derartigen Ausnahmefällen das Zertifikat trotz fehlendem Vertrauen mit der Proxy-CA unterschrieben wird und somit ein ursprünglich fehlerhaftes Zertifikat im Client als vollständig vertrauenswürdig ohne Nachfrage akzeptiert wird.

Zusammenfassung

Die Inspektion von HTTPS-Verbindungen in einem Proxy ermöglicht es, schädliche Inhalte auch in verschlüsselten Verbindungen zu finden. Um die Daten im Proxy unverschlüsselt analysieren zu können, wird dazu aus einer Client-zu-Server-Verschlüsselung eine Client-zu-Proxy und eine Proxy-zu-Server Verschlüsselung gemacht. Da der Client somit keine direkte Verbindung mehr zum Server hat, muss er sich auf eine korrekte Verschlüsselung zwischen Proxy und Server verlassen können, welche insbesondere auch die korrekte Authentisierung des Servers beinhaltet. Untersuchungen zeigen jedoch, dass viele Sicherheitslösungen dabei scheitern und so die Gesamtsicherheit gefährden. Mit der High Resistance Firewall genugate jedoch ist der Nutzer auf der sicheren Seite.

 

Bildquellen: © bagotaj - Fotolia.com


Lesen Sie auch

Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.