TLS 1.3 - Auswirkungen auf Netzwerk-Monitoring

„Neben allgemeinen Netzwerk-Metriken werden beim Monitoring auch user-spezifische Interaktionen vermessen."

Angeregt durch die Veröffentlichung der Spezifikation für die neueste Version 1.3 des Transport Layer Security (TLS)-Protokolls (RFC 8446) im August 2018 stand schnell fest, dass das Thema meiner Bachelorarbeit „Das Verschlüsselungsprotokoll TLS 1.3 und seine Auswirkungen auf das Netzwerk-Monitoring“ lauten soll. Der Fokus liegt dabei primär auf dem netzwerkbasierten Monitoring von Anwendungen, da dieses von der Umstellung auf TLS 1.3 voraussichtlich am stärksten betroffen sein wird. 
Die Ergebnisse dieser Arbeit möchte ich nun in einer dreiteiligen Beitragsreihe vorstellen.

Monitoring – ein Überblick

Zunächst habe ich mich mit den verschiedenen Möglichkeiten des Monitorings von Applikationen beschäftigt. Anwendungen werden überwacht, damit stets ihre Verfügbarkeit, aber auch eine schnelle oder sogar proaktive Behebung von auftretenden Performance-Problemen gegeben ist. Dazu gibt es drei Verfahren: das synthetische, das agentenbasierte und das netzwerkbasierte Monitoring.
Während beim synthetischen Monitoring der Datenverkehr in einem Netzwerk simuliert wird, misst beim agentenbasierten Monitoring ein im System installierter Agent den „echten“ Datenverkehr. In beiden Fällen muss ein Zugang zu den zu überwachenden Systeme bestehen („aktives Monitoring“). Hingegen benötigt das netzwerkbasierte Monitoring keinen Zugriff auf die Endpunkte der Kommunikation, da es Informationen zur Performance aus den über das Netzwerk übertragenen Datenpaketen erhält, die durch die tatsächliche Nutzung der jeweiligen Anwendung erzeugt werden („passives Monitoring“). 
Darüber hinaus kann man unterscheiden, ob das Monitoring des Traffics innerhalb eines Rechenzentrums („intern“) oder über die Grenzen eines Rechenzentrums hinweg („extern“) erfolgt, sowie ob die Überprüfung der Datenpakete am Original („inline“) oder an deren Kopie („out-of-band“) durchgeführt wird.

Warum sollten Daten verschlüsselt werden?

Neben allgemeinen Netzwerk-Metriken werden beim Monitoring auch user-spezifische Interaktionen vermessen. Dabei ist jedoch nicht auszuschließen, dass personenbezogene Daten – zum Beispiel Login-Daten – aufgezeichnet und eingesehen werden. Aus diesem Grund ist es wichtig derartige sensible Daten zu schützen. Mögliche Vorkehrungen dazu sind die Einschränkung der Sichtbarkeitsrechte auf bestimmte Nutzergruppen des jeweiligen Monitoringtools. Darüber hinaus muss man die Übertragung von Daten in Netzwerken im Allgemeinen schützen. Dies erfolgt durch die Nutzung von Verschlüsselungsprotokollen, beispielsweise mit TLS. 
Es ist nämlich möglich, dass sich ein Angreifer – ein unbefugter Dritter – auf irgendeine Weise Zugang zur Kommunikation verschafft und an sensible Daten kommt. Diese Art, sich in die Verbindung zwischen zwei kommunizierenden Endpunkten einzuschalten, nennt man „Man-in-the-Middle“-Ansatz und nutzt sie, um unter anderem als Proxy verschlüsselte Kommunikation zu überprüfen.  
Im Fall eines nicht autorisierten Eingriffs handelt es sich jedoch um einen Man-in-the-Middle-Angriff. In den letzten Jahren sind einige dieser Angriffe erfolgt, bekannt unter den Namen „POODLE“, „ROBOT“ oder „Heartbleed“, um nur einige wenige zu nennen. Aus diesem Grund ist eine Ende-zu-Ende-Verschlüsselung von Kommunikation essentiell.

Wie verschlüsselt man Daten?

Eigentlich ist es ganz einfach Daten zu chiffrieren: man wählt einen Schlüssel und wendet ihn auf den zu schützenden Datensatz an, sodass aus der dadurch entstandenen Zeichenfolge nicht auf den ursprünglichen Inhalt geschlossen werden kann. Den Schlüssel kann man sich als eine mathematische Funktion y = f(x) vorstellen und den zu verschlüsselnden Text als „x“, den man in die Funktion einsetzt. Das Ergebnis – „y“ – ist der chiffrierte Text, der an den Empfänger übermittelt wird.
Dabei gibt es jedoch zwei Herausforderungen: Wie kann man sichergehen, dass der Schlüssel auch tatsächlich sicher ist, das heißt, die Verschlüsselung nicht ohne unverhältnismäßigen Aufwand gebrochen werden kann? Und wie erhält der Empfänger den Schlüssel, um die übermittelte Nachricht lesen zu können?

Die schlechte Nachricht vorneweg: Es gibt keine absolut sicheren Schlüssel, da es immer eine Möglichkeit für den Empfänger (die „Umkehrfunktion“) geben muss, die Nachricht wieder zu entschlüsseln. Es gibt aber Möglichkeiten, die Verschlüsselungsfunktion so zu wählen, dass diese nur mit unverhältnismäßigem Aufwand erraten und umgekehrt werden kann.
Die zweite Herausforderung ist die sichere Übermittlung des Schlüssels an den Empfänger, damit dieser die an ihn gerichteten, verschlüsselten Nachrichten dechiffrieren kann. Abhilfe schafft in diesem Fall die Tatsache, dass es zwei grundlegend verschiedene Arten der Verschlüsselung gibt: symmetrische und asymmetrische Verschlüsselung, die aber auch kombiniert werden können.

Verschlüsselung    Prinzip    Vorteil    Nachteil 
Symmetrisch

Selber Schlüssel für Ver- und Entschlüsselung 

Sehr schnell       Schlüsselaustausch ist angreifbar
Asymmetrisch
(„Public- Key-
Verfahren")

- Schlüsselpaar privatem und öffentlichem Schlüssel
- Absender verschlüsselt mit öffentlichem Schlüssel
- Empfänger entschlüsselt mit privatem Schlüssel   

Sicheres Verfahren    Langsam
Hybrid
(„Pre-Shared-Key-Verfahren")    
- Asymetrische Verschlüsselung für Austausch des symmetrischen Schlüssels    
- Symmetrische Verschlüsselung für Datenaustausch
Kombinierte Vorteile beider Verfahren: sichere Schlüsselübertragung bei schnellem Datenaustausch  

 

Da es viele verschiedene Verschlüsselungsalgorithmen gibt, werden die jeweiligen Kombinationen als Cipher Suiten bezeichnet. Eine Cipher Suite legt fest, mit welchem Algorithmus welcher Teil einer Kommunikation verschlüsselt wird, und wird zu Beginn einer verschlüsselten Verbindung – zum Beispiel gesichert mit TLS – ausgehandelt.  

Was genau TLS ist und wie es funktioniert wird das Hauptthema des zweiten Teils dieser Beitragsreihe sein.

Wenn Sie sich mit mir über die Inhalte meiner Arbeit austauschen möchten, erreichen Sie mich unter Olga.Wall@amasol.de. 

 

Weiter zu Teil II: Was ist TLS 1.3? >>