TLS Handshake – was ist das?

Wie bereits erwähnt, handelt es sich sowohl bei SSL als auch bei TLS um Verschlüsselungsprotokolle. Die Abkürzung SSL steht dabei für „Secure Sockets Layer“ und TLS für „Transport Layer Security“ (Transportsicherheit). Durch sie wird die Authentifizierung und Datenverschlüsselung zwischen Servern, Computern und Anwendern, die ein Netzwerk nutzen, gewährleistet. SSL ist dabei der Vorläufer von TLS und wurde bereits 1995 von Netscape entwickelt. Da bei der ersten veröffentlichten Version ziemlich schnell Sicherheitslücken gefunden wurden, wurde bereits ein Jahr später eine neue Version auf den Markt gebracht. Im Laufe der Zeit wurden die Versionen immer weiter verbessert und immer sicherer gestaltet. Im Jahr 1999 wurde schließlich TLS eingeführt. Es handelt sich dabei um eine neuere Version von SSL und baut auf SSL 3.0 auf. Genau genommen ist es ein hybrides Verschlüsselungsprotokoll, wodurch eine sichere Datenübertragung im Internet möglich ist. Modernste Verschlüsselungstechnik, umfassender Onlineschutz und starke Sicherheit für all deine Geräte.

Die Internet Engineering Task Force (kurz IETF) ist eine Organisation, die bereits 1986 gegründet wurde und die sich für die technische Weiterentwicklung des Internets einsetzt. Sie beschloss im Laufe der Jahre, dass beide SSL-Protokolle aufgrund von immer wieder auftretenden Sicherheitslücken verworfen werden müssten. Es ist also auf jeden Fall zu empfehlen, SSL 2.0 und 3.0 zu deaktivieren und ganz auf TLS-Protokolle umzusteigen. Als User erkennt man Webserver mit alten Protokollen übrigens meist durch ein durchgestrichenes Sicherheitsschloss oder anhand von anderen Sicherheitswarnungen.

TLS geht mit HTTP (Hypertext Transfer Protocol) einher. Es fügt sozusagen das „S“ für „Sicherheit“ bei HTTPS hinzu. Bei HTTP handelt es sich um ein Anwendungsprotokoll, mit dem Daten von einem Webbrowser zu einem Webserver gesendet werden. Einfach ausgedrückt: eure Suchergebnisse werden damit an euren Browser übertragen. HTTP-Verbindungen allein sind aber viel zu unsicher. Eure Daten werden quasi offen und für jeden sichtbar versendet. Auch für Man-in-the-Middle-Angriffe, bei denen es Kriminelle darauf abgesehen haben, eure Anmelde- oder Kreditkartendaten zu stehlen, ist es anfällig. Aus diesen Gründen wurde HTTPS eingeführt. Dabei handelt es sich um eine Kombination aus HTTP, das für die Datenübertragung verantwortlich ist, und aus SSL/TLS zur Datenverschlüsselung. Durch die SSL/TLS-Encryption können Unbefugte, die eure Daten abfangen wollen, diese nur noch verschlüsselt sehen. Heutzutage gibt es kaum noch Webseiten, die kein HTTPS zur Verschlüsselung nutzen. Natürlich nutzt es die Webseite von NordVPN auch. Das bedeutet, ihr könnt sie ganz unbesorgt besuchen.

Durch das TLS-Handshake-Protocol kann eine Session samt verwendeten Sicherheits-Parametern ausgehandelt werden. Handshake-Nachrichten werden dann an den TLS Record Layer gesendet und dort mit den anderen Daten verarbeitet. Diese Aufgaben übernimmt das TLS-Handshake-Protocol: Kryptographische Algorithmen, die zur Verschlüsselung verwendet werden sollen, werden dadurch ausgehandelt. Es ist aber auch eine unverschlüsselte Übertragung möglich. Die Authentifizierung der Kommunikationspartner ist dadurch möglich. Schlüsselmaterial wird ausgehandelt.

Am Anfang steht ein Client Hello vom Client an den TLS-Server. Mit enthalten ist eine Liste mit Cipher Suites und auch eine Sitzungsnummer, die benötigt wird, wenn die Sitzung später wieder aufgenommen werden soll. Auch eine Liste mit Komprimierungsalgorithmen wird mitgesendet. Der Server antwortet auf das Client Hello mit einem Server Hello. Andernfalls kommt aufgrund eines Fatal Errors keine Verbindung zustande. In dieser Antwort ist die ausgewählt Cipher Suite und Sitzungsnummer enthalten. Es gibt Schlüsselaustausch-Methoden, die ein Zertifikat benötigen. Deshalb folgt der Server Hello Nachricht immer eine Server Certificate Nachricht. Hierbei handelt es sich um eine Nachricht, die nur dann gesendet wird, wenn im Server Zertifikat nicht alle Parameter enthalten sind, die zur Schlüsselberechnung (Pre-Master-Secret) nötig sind. Auch diese Nachricht ist nicht immer zwingend erforderlich. Damit ist es möglich, dass auch der Server vom Client ein Zertifikat anfordern kann. Die Certificate Request Nachricht wird im Anschluss an die Server Key Exchange Nachricht gesendet, oder, wenn diese nicht gesendet wird, nach dem Zertifikat des Servers. Damit sind die Authentifizierung und der Schlüsselaustausch des Servers abgeschlossen. Die Server Hello Kommunikation ist damit beendet. Der Server muss nun auf die Antwort des Clients warten. Der Client sollte aber nicht sofort mit einer Nachricht beginnen, sondern er sollte zunächst sicherstellen, dass das Server-Zertifikat auch valide ist. Im Zuge dessen sollten auch die anderen Server Hello Nachrichten überprüft werden. Im Falle einer Aufforderung durch den Server sendet der Client ebenfalls ein Zertifikat, das zur Cipher Suite passt. Auch wenn kein passendes Zertifikat vorhanden ist, muss der Client eine Certificate-Nachricht senden. Passiert dies nicht, kann der Server entweder die Verbindung kappen oder den Handshake trotz fehlender Client-Authentifizierung weiter ausführen. Die Client Key Exchange Nachricht wird, im Gegensatz zur Server Key Exchange Nachricht, immer versendet. Damit wird das Pre-Master-Secret festgelegt. Auch diese Nachricht ist optional. Es findet damit eine Verifikation des Client-Zertifikats statt. Dies ist der Nachweis dafür, dass der Client auch wirklich die privaten Schlüssel besitzt und derjenige ist, für den er sich ausgibt. Ob die Nachricht versandt wird, hängt davon ab, ob das Client-Zertifikat überhaupt signiert werden kann. Mit dieser Nachricht bekommt man die Gewissheit, dass ab jetzt die Kommunikation gesichert ist. Denn ab hier benutzt der TLS Record Layer die vorher ausgehandelten kryptographischen Algorithmen und Schlüssel. Es handelt sich bei der Change Cipher Spec also auch um die erste geschützte Nachricht. Mit dieser Nachricht wird euch mitgeteilt, dass der Schlüsselaustausch und der Authentifizierungsprozess erfolgreich waren und jetzt abgeschlossen sind. Der Empfänger der Finished-Nachricht, muss deren Inhalt auf Korrektheit überprüfen. Um dies zu gewährleisten, wird jeweils ein Hashwert für alle ausgetauschten Nachrichten errechnet und geprüft. So können zum Beispiel Downgrade-Attacken verhindert werden, bei denen ein Angreifer Cipher Suites vom Client Hello gelöscht hätte. {SHORTCODES.blogRelatedArticles}

Damit eine TLS-Verbindung zustande kommt, müssen vom Systemadministrator mindestens zwei Dateien vorbereitet werden: der private Schlüssel und das Zertifikat. Wird von einer Zertifizierungsstelle wie Symantec Trust Service ein TLS-Zertifikat beantragt, muss noch eine weitere Datei erstellt werden: Die „Signaturanforderung für ein Zertifikat“ (Certificate Signing Request, CSR). Sie wird vom privaten Schlüssel generiert. Der Prozess der Generierung der Dateien unterscheidet sich je nachdem, welche Software die Dateien zur Verschlüsselung nutzen. Die meisten Clients vertrauen Zertifikaten, die bei Zertifizierungsstellen wie Symantec beantragt werden, grundsätzlich. Dennoch kann es sein, dass zusätzliche Zertifikate auf dem Server installiert werden müssen. Diese werden als „Zertifikate der Zertifizierungsstelle“ (Certificate Authority Certificates) oder als „Stammzertifikate der Zertifizierungsstelle“ (Certificate Authority Root Certificates) bezeichnet. Ob dies der Fall ist, ist auch abhängig von der verwendeten Serversoftware. Im Normalfall ist es jedoch nicht notwendig diese Zertifikats-Dateien zu installieren. Sind die Dateien schließlich verfügbar und auch korrekt installiert, kann mit der TLS-Aushandlung – dem TLS-Handshake also – über das abgesicherte Protokoll angefangen werden.

Hier werden Informationen übermittelt, die für die Kommunikation mit dem Client über SSL notwendig sind. Diese umfassen zum Beispiel Verschlüsselungseinstellungen, SSL-Versionsnummer und sitzungsspezifische Daten. Es werden Informationen übermittelt, die der Server benötigt, um mit dem Client über SSL kommunizieren zu können. Auch hier sind die Verschlüsselungseinstellungen, die SSL-Versionsnummer und die sitzungsspezifischen Daten ein wichtiger Bestandteil. Vom Server wird der Pre-Master-Secret-Wert mit Hilfe des privaten Schlüssels entschlüsselt. Server und Client versuchen beide den Master-Secret-Wert durch das vereinbarte Verschlüsselungsverfahren zu generieren. Der Client tauscht sich mit dem Server aus und teilt mit, dass Nachrichten in Zukunft verschlüsselt werden. Das Server-Zertifikat wird durch den Client authentifiziert. Dann erstellt der Client den Pre-Master-Secret-Wert für die Sitzung. Anschließend verschlüsselt er ihn mit dem öffentlichen Schlüssel des Servers. Der verschlüsselte Pre-Master-Secret-Wert wird an den Server gesendet. Letztendlich ist die TLS-Verschlüsselung sicherer als ihre Vorgänger. Doch auch sie ist natürlich nicht perfekt und es kann einiges schieflaufen. Besonders dann, wenn unsichere TLS-Versionen und Kryptosuiten gewählt werden. Sich über das Thema mal genauer zu informieren kann sich also auf jeden Fall lohnen.