TLS 1.3 – wird das Monitoring blind?

Das Thema des zweiten Teils dieser Beitragsreihe zu meiner Bachelorarbeit „Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring“ war der Aufbau und die Funktionsweise des TLS 1.3-Protokolls sowie die Neuerungen, die mit der Einführung der neuen Version TLS 1.3 im Vergleich zu TLS 1.2 einhergehen. In diesem letzten Teil möchte ich nun die Auswirkungen auf das Monitoring von Anwendungen aufzeigen.

Statische vs. ephemere Schlüssel

Bisher galt, dass volle Sichtbarkeit im Monitoring nur dann besteht, wenn die Daten unverschlüsselt übertragen werden. Verschlüsselte Daten stellten das Monitoring vor eine Herausforderung, die bislang aber gut zu bewältigen war. Es wurden nämlich größtenteils Verschlüsselungsverfahren eingesetzt, die statische Schlüssel nutzen. Statische Schlüssel werden für die Verschlüsselung mehrerer Sitzungen verwendet, ehe sie ausgetauscht werden. Damit war die Hinterlegung dieser Schlüssel im jeweiligen Monitoringtool möglich, und so konnte die Kommunikation dechiffriert sowie die benötigten Parameter überwacht werden.   
Mit dem verpflichtenden Einsatz flüchtiger Schlüssel ist diese Vorgehensweise nicht mehr praktikabel, da jede Sitzung mit einem neuen Schlüssel chiffriert wird. Damit wird das bisherige Verfahren beim Einsatz des TLS 1.3-Protokolls obsolet. Erschwerend kommt hinzu, dass die Verschlüsselung in TLS 1.3 nun auch früher – nämlich bereits nach dem ServerHello – als in früheren Versionen einsetzt. Informationen, die dabei verloren gehen, betreffen unter anderem den Austausch des Schlüssels und der Zertifikate.

Wie viel Sichtbarkeit wird tatsächlich benötigt?

Mit dem Ausbleiben des Schlüssels ist die Sichtbarkeit des kommunizierten Inhalts nur noch sehr gering. Ohne eine Entschlüsselung sind nur noch Metriken wie SSL Connection Setup Time, SSL Handshake Errors sowie allgemeine Metriken zur Netzwerkperformance, die TLS-Version und die verhandelte Cipher Suite sichtbar. 
Detailliertere Informationen, wie beispielsweise einzelne User oder aufgerufene URLs, sind dabei nicht verfügbar. Damit lässt sich Monitoring nicht mehr im gewohnten Umfang realisieren und eine Entschlüsselung wird benötigt.
Gleichzeitig ist abzuwägen, wie viele der aus sämtlichen Netzwerk-Metriken gewonnenen Informationen wirklich erforderlich für ein funktionierendes Monitoring sind. Wann reichen allgemeine Netzwerk-Metriken aus, die auch mit (bzw. trotz) Verschlüsselung verfügbar sind, und wann werden detailliertere Informationen benötigt? 

Lösungen

Einerseits kann man versuchen mit dem geringeren Informationsgehalt auszukommen, welchen allgemeine Netzwerk-Metriken des netzwerkbasierten Monitorings – wie zum Beispiel Dynatrace NAM - bieten. In Kombination mit anderen Informationsquellen – beispielsweise Verhalten von Hosts  oder Datenflussmerkmale – können dabei durch Korrelation aufschlussreiche Muster sichtbar werden.  Der erhaltene Detailgrad hängt vom Anteil der verschlüsselten Daten ab. Möglicherweise wird dies jedoch keine zufriedenstellende Lösung darstellen, insbesondere wenn das Monitoring auch der Gewährleistung der Sicherheit dienen soll.
Abhilfe bietet in diesem Fall der Einsatz von Agenten, die entweder den jeweils aktuellen Schlüssel an das Monitoring-Tool weiterleiten (ExtraHop Reveal(x)) oder das Monitoring direkt an den Kommunikationsendpunkten durchführen (Dynatrace). Eine Ergänzung dazu bietet Ixia mit ihren Visibility Appliances als Proxy, welche die Verschlüsselung unterbrechen, um die Datenpakete zur Analyse an ein Monitoring-Tool zu senden. Anschließend werden die Daten wieder verschlüsselt und an den eigentlichen Empfänger zugestellt.

Fazit

Auch wenn die Veröffentlichung der Spezifikation für TLS 1.3 mittlerweile schon ein Jahr zurückliegt, ist dieses Protokoll noch nicht weit verbreitet. Obwohl der Einsatz von TLS 1.3 empfohlen wird, werden mit Sicherheit noch einige Monate – wenn nicht Jahre – vergehen, bis TLS 1.3 das vorherrschende Verschlüsselungsprotokoll ist. Damit sind die Problematik der geringeren Sichtbarkeit durch TLS 1.3 und die daraus resultierenden Folgen zwar wichtig, drohen aber nicht unmittelbar. 

Dies hat den Vorteil, dass für jeden Betreiber einer Monitoring-Umgebung nun genug Zeit bleibt, um eine optimale Lösung für diese Herausforderung zu finden.

Die amasol AG arbeitet bereits jetzt mit ihren Herstellerpartnern im Bereich des Anwendungsmonitorings Dynatrace, ExtraHop und Ixia an Lösungen, um Sie bei der Umstellung bestmöglich zu unterstützen. 

Damit endet die Beitragsreihe zu meiner Bachelorarbeit „Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring“.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit austauschen möchten, erreichen Sie mich unter olga.wall(at)amasol.de. 

 

<< Zurück zu Teil II: Was ist TLS 1.3?

Olga Wall ist seit 2019 als Consultant im Application Performance Management (APM) Team von amasol tätig. In dieser Funktion berät sie Kunden zu unterschiedlichen Themen rund um netzwerkbasiertes Application Performance Management (ExtraHop, Dynatrace, IXIA, NPBs) sowie synthetisches Monitoring (Dynatrace). Darüber hinaus begleitet Olga APM-Einführungsprojekte als technische Projektleitung.

Olga Studierte zuerst Materialwissenschaften und dann Informatik. Über ein Praktikum zum Abschluss ihres Informatiksstudium stieß sie zum amasol APM-Team. Dort verfasste sie auch ihre Bachelorarbeit mit dem Titel Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring."

In ihrer Freizeit beschäftigt sich Olga mit Brettspielen und Flamenco sowie Kammermusik, denn sie spielt selbst auch Geige.

Autorin:
Olga Wall