TLS: Viel mehr als nur eine Compliance-Anforderung

Vielleicht haben Sie schon einmal von SSL/TLS gehört, insbesondere im Jahr 2018, als die Einführung von Secure Sockets Layer (SSL) durch Webbrowser vorangetrieben wurde und der PCI-Rat darauf hinwies, dass frühere Versionen von TLS (Transport Layer Security) künftig nicht mehr unterstützt werden. 

Diese Begriffe werden oft verwendet, ohne dass man ihre Bedeutung oder Funktionsweise kennt. Das liegt daran, dass dahinter ein komplexes Zusammenspiel von Netzwerken, Kryptografie, Algorithmen und Strukturen steckt.

Dies ist kein umfassender, detaillierter Fachartikel zum Thema Kryptografie, sondern ein grundlegender Leitfaden darüber, was Kryptografie ist, wie sie funktioniert und warum wir sie in unseren SAP-Systemen und Sicherheitsprozessen implementieren sollten.

Zunächst wollen wir anhand einer kurzen Tabelle die Entwicklung von SSL/TLS veranschaulichen:

Sowohl SSL als auch TLS sind Protokolle, die zur Verschlüsselung der Kommunikation zwischen zwei Entitäten dienen, indem öffentliche und private Schlüssel ausgetauscht werden, um eine sichere Verbindung zwischen ihnen herzustellen und so den Datenschutz und die Datenintegrität zu gewährleisten. Obwohl TLS der Nachfolger von SSL ist, wird der Begriff „SSL“ im Alltag häufig als Sammelbezeichnung für beide Protokolle verwendet.

Im Laufe ihrer Geschichte wurden Schwachstellen und Konstruktionsmängel festgestellt, wie zum Beispiel DROWN und POODLE (SSL 2.0 & SSL 3.0), was Kryptografen weltweit dazu zwang, jedes Mal stärkere Algorithmen und Strukturen zu erforschen und zu veröffentlichen.
Wie aus der Tabelle weiter oben ersichtlich ist, ist TLS 1.2 die„unverzichtbare“Version, die von den gängigsten Webbrowsern und Standards wie PCI gefördert wird. 

Grundlegender TLS-Handshake (Erste Kommunikation)

In der Regel sendet der Client als Erster eine Nachricht namens„Client Hello“an den Server, um Informationen auszutauschen. Diese Nachricht enthält:

• Version: Die TLS-Protokollversion, die der Client für die Kommunikation mit dem Server verwenden möchte. Es handelt sich um die höchste vom Client unterstützte Version.
• Client-Zufallszahl: Eine pseudozufällige Zahl, die zur Erstellung des Master-Secrets (Erstellung des Verschlüsselungsschlüssels) verwendet wird.
• Sitzungskennung: Eine optionale Sitzungskennung zur Wiederaufnahme.
• Verschlüsselungssuite: Liste der vom Client unterstützten Verschlüsselungssuiten, sortiert nach der Präferenz des Clients. Eine Verschlüsselungssuite besteht aus Algorithmen für den Schlüsselaustausch, die Datenverschlüsselung und die MAC-Prüfung sowie einer Pseudozufallsfunktion, z. B.:
  Verschlüsselungssuite: TLS_DHE_RSA_WITH_AES_256_CCM (verfügbar in TLS 1.2)
  TLS = Protokollversion.

Nach dieser Nachricht ist der Server an der Reihe, die „ServerHello“-Nachricht zu senden, in der er für jedes Client-Element angibt, ob er diese Konfiguration (die höchstmögliche) unterstützt und ihr zustimmt. Nach Abschluss des „Hello“-Schritts sendet der Server sein Zertifikat, das den öffentlichen Schlüssel des Servers enthält. Anhand dieses Zertifikats überprüft der Client, ob der Server tatsächlich der ist, für den er sich ausgibt, und baut eine sichere Verbindung auf. Dies sind die wichtigsten Felder:

• Seriennummer: Diese ist für jedes ausgestellte Zertifikat eindeutig und wird von der Zertifizierungsstelle (CA) vergeben.
• Signaturalgorithmus: Gibt den kryptografischen Algorithmus an, den die Zertifizierungsstelle zum Signieren des Zertifikats verwendet. Seit 2016 müssen alle Zertifizierungsstellen die Signatur mit dem SHA-2-Algorithmus vornehmen.
• Aussteller: Die Zertifizierungsstelle, die das Zertifikat signiert hat.
• Gültig ab und Gültig bis: Diese Felder geben den Gültigkeitszeitraum des Zertifikats an, das zwischen diesen Daten gültig ist.
• Betreff: Enthält die Informationen zum Distinguished Name (DN) des Zertifikats; je nach Art des Zertifikats werden unterschiedliche Angaben angezeigt. Die gängigste Art ist „Organization Validated“ (OV), bei der folgende Angaben angezeigt werden: Common Name (CN), Organisation (O), Organisationseinheit (OU), Ort oder Stadt (L), Bundesland oder Provinz (S) und Ländername (C).
• Öffentlicher Schlüssel: Dient zur Angabe der Schlüssellänge des Moduls.
• Alternativer Name (SAN): Die meisten Anwendungen und Webbrowser unterstützen dieses Feld; es listet alle FQDNs auf, für die das Zertifikat gültig ist, wenn es auf eine Anwendung angewendet wird. 

Sobald das Zertifikat des Servers überprüft wurde, generiert der Client ein „Pre-Master Secret“, das von der verwendeten Verschlüsselungssuite abhängt. Bevor er es an den Server sendet, verschlüsselt er es mit dem öffentlichen Schlüssel des Servers (den er dem Zertifikat des Servers entnimmt). Nach dem Empfang sollte der Server in der Lage sein, es mit dem privaten Schlüssel zu entschlüsseln, und beide Seiten können das „Master Secret“ generieren, indem sie eine pseudozufällige Funktion auf das „Pre-Master Secret“ und die zuvor ausgetauschten Zufallszahlen anwenden. Dieses Master Secret ist der Schlüssel, den Client und Server künftig zur Verschlüsselung ihrer Kommunikation verwenden.

Sobald der Schlüssel generiert wurde, überprüfen beide Seiten alle Informationen mithilfe einer Nachricht namens„ChangeCipherSpec“. Sobald die Verbindung hergestellt ist und beide Seiten dieselbe „Sprache“ sprechen, sind sie bereit, Informationen auszutauschen, die im„ApplicationData“-Paket enthalten sind.

Warum sollte ich es nutzen?

Nehmen wir einmal an, wir möchten uns wie immer mit unseren Zugangsdaten bei einem unserer SAP-Systeme anmelden.

Wir senden diese Informationen, ohne zu bedenken, dass sie im Klartext über das Netzwerk übertragen werden. Jeder, der den Netzwerkverkehr abhört oder ausliest, könnte alles sehen, was wir an den SAP-Server senden. Mit anderen Worten: unsere Anmeldedaten oder sonstige sensible Transaktionsdaten.
 

Nach der Implementierung von TLS können wir feststellen, dass zwischen unserem Gerät und dem Server TLS-1.2-Pakete ausgetauscht werden, wobei jedoch keine Informationen im Klartext übertragen werden (verschlüsselt).
 

Entscheidend ist hierbei, dass diese Sicherheitslücke bei sensiblen Daten die gesamte Gruppe von SAP-Systemen betrifft, die nicht über eine ordnungsgemäße TLS-Konfiguration verfügen – ganz gleich, ob Sie auf ABAP, Java oder HANA basierende Stacks verwenden, eine Verbindung zu einer Datenbank herstellen oder einen mobilen Client nutzen.

Ausführlichere Informationen zu den in CommonCryptolib 8 implementierten kryptografischen Algorithmen und SSL/TLS-Verschlüsselungssuiten finden Sie hier.

Informationen zu TLS-Implementierungen finden Sie unter den folgenden Links:
Transport Layer Security auf SAP NetWeaver AS für Java
Transport Layer Security auf dem AS ABAP
TLS/SSL-Konfiguration auf dem SAP-HANA-Server