Wer heute Netzwerkverkehr überwacht, sieht oft weniger, als tatsächlich passiert. Der Grund dafür ist nicht etwa ein Rückgang der Aktivität, sondern vielmehr die konsequente Verschlüsselung moderner Kommunikation. Was ursprünglich dem Schutz legitimer Verbindungen diente, schafft in der Praxis auch einen wirksamen Sichtschutz für Angreifer. Schadcode, Command-and-Control-Kommunikation oder Angreifer, die sich innerhalb eines Netzwerkes, also lateral bewegen, können sich hinter verschlüsseltem Traffic verbergen.

Wie Enginsight mithilfe Client-basierter TLS Interception hinter diese Verschlüsselung blickt und Angriffs-Traffic wieder sichtbar macht, zeigen wir in diesem Artikel.

Doch zunächst lohnt sich ein kurzer Blick auf die Grundlagen:

Was ist TLS?

Transport Layer Security, kurz TLS, entstand als Antwort auf ein konkretes Problem der frühen Internetzeit. Das Aufkommen von Netzwerk-Werkzeugen wie tcpdump machten es bereits in den frühen 1990er-Jahren möglich, Netzwerkverbindungen mitzulesen. Gleichzeitig verlagerte sich auch immer mehr Kommunikation in das Internet. Ohne zusätzlichen Schutz wurden sensible Daten wie Logins, Zahlungsinformationen oder persönliche Angaben häufig im Klartext übertragen und konnten dadurch abgefangen oder manipuliert werden.

Einen ersten Lösungsansatz entwickelte Netscape 1994 mit Secure Sockets Layer, kurz SSL. SSL ermöglichte es erstmals, Verbindungen zwischen zwei Kommunikationspartnern kryptografisch abzusichern. Nach mehreren Versionen, teils mit schwerwiegenden Sicherheitsmängeln, entwickelte sich daraus TLS. Mit TLS 1.2 und später TLS 1.3 entstanden schließlich Standards, die konsequent auf moderne und sichere kryptografische Verfahren setzten.
Dies macht TLS bis heute zum Rückgrat der sicheren Netzwerkkommunikation.

Wie funktioniert TLS und was hat HTTPS damit zu tun?

Dass TLS heute allgegenwärtig ist, zeigt sich schon in der Adresszeile des Browsers. Wer eine Website aufruft, die mit https:// beginnt, nutzt HTTP over TLS, oder kurz HTTPS. Das kleine Schloss-Symbol im Browser signalisiert: Diese Verbindung ist durch TLS gesichert.

Doch was steckt nun technisch dahinter?

TLS – Ein Authentifizierungsverfahren in 3 Schritten

Bevor auch nur ein Byte Nutzdaten übertragen wird, durchlaufen Client und Server den sogenannten TLS-Handshake. Dabei wird die Verbindung authentifiziert, ein gemeinsamer Schlüssel ausgehandelt und die Grundlage für eine verschlüsselte Kommunikation geschaffen.

Im ersten Schritt weist sich der Server gegenüber dem Client aus. Dafür präsentiert er ein digitales Zertifikat, dass von einer vertrauenswürdigen Zertifizierungsstelle, einer Certificate Authority, signiert wurde. Browser und Betriebssysteme verfügen über Listen solcher vertrauenswürdigen CAs und prüfen anhand dieser Informationen, ob das Zertifikat echt, gültig und tatsächlich der aufgerufenen Domain zugeordnet ist.

Im zweiten Schritt handeln Client und Server einen gemeinsamen Sitzungsschlüssel aus, ohne dass dieser jemals offen über das Netzwerk übertragen wird. Dafür kommt asymmetrische Kryptografie zum Einsatz. Client und Server besitzen je ein Schlüsselpaar aus öffentlichem und privatem Schlüssel und einigen sich damit auf einen gemeinsamen Wert, den nur sie kennen.

Im dritten Schritt wird die eigentliche Kommunikation mit diesem Sitzungsschlüssel symmetrisch verschlüsselt. Ein gemeinsamer Schlüssel, mit dem beide Seiten schnell und effizient ver- und entschlüsseln können.
Wer den Datenstrom abfängt, sieht ohne diesen Schlüssel nur unlesbares Rauschen.

Während legitime Kommunikation so wirksam vor unbefugtem Mitlesen und Manipulation geschützt wird, kann dieselbe Verschlüsselung auch von Angreifern genutzt werden, um schädliche Aktivitäten innerhalb scheinbar “normaler” TLS-Verbindungen zu verbergen.

Wenn Schutz zur Tarnung wird

Was TLS so wirkungsvoll macht, stellt Sicherheitsverantwortliche gleichzeitig vor ein grundlegendes Problem. Verschlüsselung macht keinen Unterschied zwischen legitimer Kommunikation und Angriffen. Sie schützt gleichermaßen jeden Datenstrom, unabhängig davon, ob darüber ein Nutzer eine Website aufruft oder aber Malware mit ihrer Command-and-Control-Infrastruktur kommuniziert.

Genau darum nutzen organisierte Angriffsgruppen HTTPS inzwischen nahezu standardmäßig. Ausgehender HTTPS-Traffic ist in den meisten Unternehmensnetzen pauschal erlaubt, fügt sich unauffällig in den normalen Netzwerkverkehr ein und bleibt für viele Monitoring-Systeme inhaltlich undurchsichtig. Auch Datenabfluss über HTTPS hinterlässt in klassischen Netzwerkprotokollen oft nur begrenzt verwertbare Spuren. Laterale Bewegungen über verschlüsselte Verbindungen können netzwerkbasierte Erkennungssysteme zusätzlich umgehen.

Gleichzeitig setzen sich Zero-Trust-Architekturen durch, in denen auch interne Kommunikation konsequent verschlüsselt wird. Aus Sicherheitsperspektive ist das richtig und notwendig. Es bedeutet aber auch, dass verschlüsselter Netzwerkverkehr längst nicht mehr nur ein Thema am Perimeter ist, sondern zunehmend jede Verbindung innerhalb der Infrastruktur betrifft.

Damit stellt sich eine zentrale Frage:
Wie lässt sich verschlüsselter Netzwerkverkehr auf Bedrohungen untersuchen, ohne die Sicherheitswirkung von TLS grundsätzlich aufzugeben?

Die bisherige Antwort: Zentrale Interception über Proxys

Der bisher etablierte Ansatz setzt auf ein zwischengeschaltetes Gerät wie einen HTTPS-Proxy oder eine Next-Generation-Firewall mit TLS-Interception-Funktion. Hierbei baut der Client keine direkte TLS-Verbindung zum Zielserver auf.
Stattdessen terminiert der Proxy die Verbindung auf seiner Seite, entschlüsselt den Netzwerkverkehr, analysiert den Klartext und baut anschließend eine neue, separate TLS-Verbindung zum eigentlichen Server auf.

Für den Client wirkt dieser Vorgang zunächst wie eine normale Verbindung. Der entscheidende Unterschied liegt im Zertifikat. Dieses entstammt nicht dem Zielserver, sondern wird durch die interne CA des Proxys ausgestellt. Damit der Client diese Verbindung akzeptiert, muss diese CA auf dem Endgerät als vertrauenswürdig hinterlegt sein.

Auf diese Weise lässt sich TLS-Traffic, der über den Proxy geleitet wird, entschlüsseln und analysieren. Der Ansatz bringt jedoch strukturelle Einschränkungen mit sich, die seinen Nutzen in modernen Infrastrukturen begrenzen:

• Aufwändiger Rollout
  Das Proxy-eigene CA-Zertifikat muss auf jedem verwalteten Endpunkt als vertrauenswürdig hinterlegt werden.
• Konzentrierte Angriffsfläche
  Die gesamte Entschlüsselung läuft zentral über eine einzige Stelle. Wird ein Proxy kompromittiert, so kann ein Angreifer potenziell Zugriff auf sämtliche dort entschlüsselten Verbindungen erhalten.
• Protocol Ossification
  Einige Proxy-Implementierungen können moderne TLS-Verbindungen beeinträchtigen oder auf ältere, weniger sichere Verfahren zurückfallen. Dadurch entsteht ein Sicherheitsrisiko, das durch die Interception selbst verursacht wird.
• Kein Blick nach innen
  Ein zentraler Proxy sieht nur den Netzwerkverkehr, der auch tatsächlich über ihn geleitet wird. Interne Kommunikation, lokale Prozesse und hostbasierte Schadsoftware bleiben häufig außerhalb seines Sichtfelds. Genau dort spielen sich jedoch viele kritische Angriffsphasen ab.

TLS-Interception direkt am Client: die Enginsight-Lösung

Das von Enginsight zum Patent angemeldete Verfahren setzt TLS-Interception entgegen der verbreiten Ansätze nicht zentral im Netzwerk an, sondern direkt auf dem Client.

Möglich wird dieser Ansatz durch den Sitzungsschlüssel der jeweiligen TLS-Verbindung. Er ist auf dem Client bereits verfügbar, weil der lokale Prozess ihn zur Ver- und Entschlüsselung seiner eigenen Verbindung benötigt.

Diese Eigenschaft nutzt der Enginsight Agent Pulsar, um sich in die vorhandenen SSL/TLS-Bibliotheken des Hosts einzubinden. Das ermöglicht die Analyse des Netzwerkverkehrs direkt auf dem Client.

Der entschlüsselte Inhalt kann anschließend durch das integrierte hostbasierte Intrusion-Detection-System auf Angriffsmuster untersucht werden. Der Netzwerkverkehr muss dafür weder über einen zentralen Proxy geleitet noch an einer zentralen Stelle gesammelt werden.
Die Verbindung selbst bleibt bestehen, während die Analyse lokal auf dem Gerät erfolgt.

So funktioniert es in der Praxis

• Kein Eingriff in die Verbindung
  Client und Server kommunizieren wie gewohnt mit echten Zertifikaten, ohne Unterbrechung. Der Pulsar Agent analysiert passiv, während der TLS-Kanal vollständig unangetastet bleibt.
• Kein Rollout von Zertifikaten oder Schlüsseln
  Das Verfahren kommt ohne zusätzliches Schlüsselmaterial aus. Es sind weder Zertifikatsverteilung noch Infrastruktur zur Schlüsselverwaltung erforderlich.
• Keine Änderungen an der Netzwerkinfrastruktur
  Der Pulsar läuft direkt auf dem Client. Es sind keine zusätzlichen Netzwerkkomponenten und kein Konfigurationsaufwand an bestehenden Systemen nötig.
• TLS 1.3-fähig
  Der Pulsar arbeitet direkt auf dem Client, wo der Sitzungsschlüssel nach erfolgreichem TLS-Handshake verfügbar ist. Dadurch ist die Analyse auch bei TLS 1.3 möglich.

Schluss mit blinden Flecken im verschlüsselten Netzwerkverkehr

Der Enginsight Agent Pulsar setzt voraus, dass auf dem Host kompatible SSL/TLS-Bibliotheken vorhanden sind. In der Praxis ergibt sich dennoch eine breite Abdeckung, weil gängige Webserver und Reverse Proxys in großem Umfang unterstützt werden.

Der entscheidende Unterschied liegt nicht allein in der technischen Umsetzung, sondern im Ort der Analyse. Ein zentraler Proxy sieht nur den Netzwerkverkehr, der über ihn geleitet wird. Der Pulsar hingegen analysiert ausgehende, interne und lokale Verbindungen direkt auf dem Client.

Die Analyse ist dadurch nicht mehr auf den Traffic am Netzwerkperimeter begrenzt. Auch interne Verbindungen, lokale Prozesse und verschlüsselte Kommunikation innerhalb der Infrastruktur werden direkt auf dem Client sichtbar und können in die Erkennung mit einbezogen werden.

Schadsoftware, die per HTTPS mit einem Command-and-Control-Server kommuniziert, wird somit nicht erst am Netzwerkperimeter sichtbar, sondern direkt auf dem Gerät, auf dem sie ausgeführt wird. Auch laterale Netzwerkkommunikation innerhalb des Netzes bleibt nicht länger unsichtbar, nur weil sie über verschlüsselte Protokolle abgewickelt wird. Und in Zero-Trust-Architekturen entstehen keine neuen blinden Flecken, nur weil interne Kommunikation konsequent verschlüsselt abläuft.

Zentraler Proxy vs. Enginsight Agent Pulsar im direkten Vergleich

	Zentraler Proxy	Enginsight Agent Pulsar
Welche Infrastruktur wird benötigt?	Zusätzliches Netzwerkgerät erforderlich	Agent läuft auf dem Client
Was muss auf den Endgeräten eingerichtet werden?	Proxy-CA muss auf jedem Endpunkt hinterlegt werden	Kein Zertifikats-Rollout nötig
Was passiert mit der verschlüsselten Verbindung?	Wird aufgebrochen und neu aufgebaut	Bleibt unverändert, mit echten Zertifikaten
Werden zusätzliche Schlüssel benötigt?	Zusätzliche CA-Schlüssel im Umlauf	Nutzt den vorhandenen Sitzungsschlüssel
Lässt sich TLS 1.3 analysieren?	Nur eingeschränkt, manche Proxys fallen dabei auf ältere, weniger sichere Verfahren zurück	Ja, der Sitzungsschlüssel ist nach dem TLS-Handshake direkt auf dem Client verfügbar
Wird interner Netzwerkverkehr erfasst?	Nein, sofern er nicht über den Proxy läuft.	Ja, auch Verbindungen zwischen Systemen im internen Netz, etwa bei lateraler Bewegung von Angreifern.
Werden lokale Prozesse und Schadsoftware auf dem Gerät erfasst?	Nein, der Proxy sieht nur den Netzwerkverkehr, nicht was auf dem Gerät selbst passiert	Ja, über das hostbasierte Intrusion-Detection-System
Wo findet die Analyse statt?	Der Traffic muss zur Analyse über den zentralen Proxy geleitet werden	Die Analyse bleibt direkt auf dem Endpunkt
Skalierbar ohne zentrale Infrastruktur	Nein, wachsender Traffic erfordert mehr Kapazität am zentralen Proxy	Ja, jeder Host analysiert seine eigenen Verbindungen