SSL-Technik

SSL und TLS

Die Verschlüsselungsprotokolle Secure Sockets Layer (SSL) und der Nachfolger Transport Layer Security (TLS) schützen die Kommunikation im Internet. SSL wurde ursprünglich von Netscape entwickelt und hat sich nach einer Reihe von Verbesserungen zu SSL v3 entwickelt, das zusätzliche Sicherheit gegen Abhören und Fälschen von Nachrichten bietet. SSL v3 kann auch als TLS 1.0 angesehen werden. Obwohl SSL der am häufigsten verwendete Begriff ist, werden die Begriffe SSL und TLS oft als austauschbar verwendet. Die Protokolle gewährleisten:

Authentifizierung des Servers (z.B. Server eines Webshops) und optional des Clients (z.B. Browsers des Besuchers) mit Hilfe eines SSL-Zertifikats. Hier wird von asymmetrischer Verschlüsselung Gebrauch gemacht.
Gewährleistung der Privatsphäre durch Verschlüsseln der ausgetauschten Daten, basierend auf einem sich ändernden, symmetrischen Schlüssel.
Gewährleistung der Integrität; Sobald sich Daten ändern, ist die Verbindung unterbrochen.

Alle SSL-Protokolle sind jetzt veraltet und nicht mehr sicher. Der Rat ist diese auf dem Server zu deaktivieren.

TLS-Handshake-Prozedur

Das Einrichten einer TLS-Verbindung erfolgt in mehreren Schritten. In den meisten Fällen dauert die gesamte Prozedur nicht länger als eine Sekunde.

Wenn sich der Client und der Server entschieden haben, die TLS-Verbindung zu verwenden (oft wird hierfür der Port 443 für HTTPS verwendet), wird die Verbindung durch ein "Handshake"-Verfahren hergestellt. Während dieses Handshakes stimmen der Client und der Server r mehreren Parametern zu, um eine sichere Verbindung herzustellen:

Bevor die SSL-Verbindung eingerichtet wird, tauschen der Client und der Server Daten aus, z.B. den stärksten Algorithmus und das neueste SSL/TLS-Protokoll, das beide unterstützen.
Der Server sendet einen Identitätsnachweis in Form eines digitalen Zertifikats (Öffentlicher Schlüssel des Zertifikats), das der Client auf Gültigkeit überprüft. Auf diese Weise weiß der Client , mit wem er kommuniziert. Im Fall von doppelseitigem SSL fordert der Server außerdem ein digitales Zertifikat vom Client an, so dass sowohl der Server als auch der Client wissen, mit wem sie kommunizieren.
Der Client verwendet die, vom Server zur Verfügung gestellte Informationen, um den Server zu überprüfen. Wenn der Server nicht verifiziert werden kann, wird der Benutzer gewarnt, dass keine verschlüsselte Verbindung hergestellt werden kann. Nur wenn der Server erfolgreich verifiziert werden kann, fährt der Client mit dem nächsten Schritt fort.
Der Client verschlüsselt eine Zufallszahl mit dem öffentlichen Schlüssel des Zertifikats, das er in Schritt 2 des Servers erhalten hat. Dies wird zu einem sogenannten sitzungsspezifischen Pre-Master-Geheimnis. Der Client sendet diese an den Server, der das Pre-Master-Geheimnis nur entschlüsseln kann, da es den privaten Schlüssel des verwendeten Zertifikats hat. Da nur die beiden genannten Parteien Zugriff auf die verwendeten Schlüssel haben, kann ein Missbrauch durch Dritte ausgeschlossen werden.
Wenn der Server die Client-Authentifizierung angefordert hat (im Fall von zweiseitigem SSL, einem optionalen Schritt im Handshake), wird der Client ein weiteres eindeutiges Datenelement signieren. Diese Daten sind für diesen Handshake eindeutig und sowohl dem Client als auch dem Server bekannt. In diesem Fall sendet der Client die signierten Daten, das Client-eigene Zertifikat und das verschlüsselte Pre-Master-Geheimnis an den Server.
Wenn der Client nicht verifiziert werden kann, wird die Sitzung geschlossen. Wenn der Client erfolgreich verifiziert werden kann, verwendet der Server seinen privaten Schlüssel zum Entschlüsseln des Pre-Master-Geheimnisses. Dann führen sowohl der Client als auch der Server eine Reihe von Schritten durch, um basierend auf dem Pre-Master-Geheimnis ein Master-Geheimnis zu erzeugen.
Sowohl der Client als auch der Server verwenden das Master-Geheimnis, um Sitzungsschlüssel zu generieren. Dies sind symmetrische Schlüssel, die zum Codieren und Decodieren von Informationen verwendet werden, die während der SSL-Sitzung ausgetauscht werden und zum Überprüfen der Integrität (d.h. zum Erkennen von Änderungen in den Daten zwischen dem Senden und Empfangen der Daten über SSL Verbindung).
Der Client sendet eine Nachricht an den Server. Dies zeigt an, dass zukünftige Nachrichten vom Client mit dem Sitzungsschlüssel verschlüsselt werden. Der Client sendet dann eine separate verschlüsselte Nachricht, die angibt, dass der Client-Teil des Handshakes abgeschlossen wurde.
Der Server sendet eine Nachricht an den Client. Dies zeigt an, dass zukünftige Nachrichten vom Server mit dem Sitzungsschlüssel verschlüsselt werden. Der Server sendet dann eine separate verschlüsselte Nachricht, die angibt, dass der Server-Teil des Handshakes abgeschlossen wurde.

Der SSL-Handshake ist nun abgeschlossen und die Sitzung beginnt. Der Client und der Server verwenden jetzt die Sitzungsschlüssel zum Verschlüsseln, Entschlüsseln und Überprüfen der Integrität von Daten. Für jede Sitzung (z.B. Besuch der Website) wird der Handshake-Prozess erneut ausgeführt und neue Schlüssel werden verwendet.

Geschichte

Beim Einrichten einer sicheren Verbindung verhandeln der Client und der Server ein gemeinsames Protokoll, um den Kanal während des Handshakes zu schützen. Es wurden mehrere Versionen von SSL und TLS entwickelt; Die neueste Version ist TLS 1.3.

SSL 1.0, 2.0 und 3.0

Die erste SSL 1.0-Technologie wurde von Netscape im Jahr 1994 entwickelt. Aufgrund der ernsten Sicherheitsprobleme, wurde diese Version nie veröffentlicht. 1995 veröffentlichte Netscape SSL 2.0. Die Sicherheitslücken der Vorversion sind hier verbessert, aber SSL 2.0 hatte noch ein einige Verschlüsselungsschwächen. Netscape veröffentlichte 1996, dass von Paul Kocher entwickelte, SSL 3.0. In dieser Version wurde das Protokoll komplett neu geschrieben und alle Sicherheitslücken wurden geschlossen. Im Jahr 2014 wurde eine weitere schwerwiegende Schwachstelle in SSL 3.0 entdeckt.

PCT 1.0

Private Communications Technology (PCT) 1.0 ist ein von Microsoft in den 90er Jahren entwickeltes Protokoll. PCT wurde entwickelt, um Sicherheitslücken in Version 2.0 von Netscape Secure Sockets Layer Protocol (SSL) zu beheben und Netscape zu zwingen, die proprietäre Rechte und die Kontrolle über das SSL-Protokoll in einen offenen Standard umzuwandeln. PCT ist jetzt ein veraltetes Protokoll und ist durch SSLv3 und TLS ersetzt. PCT wurde vorübergehend noch von Internet Explorer unterstützt, aber die neuesten Versionen unterstützen keinen PCT mehr. Das PCT-Protokoll befindet sich weiterhin in IIS und in der Systembibliothek von Windows-Betriebssystemen, ist jedoch standardmäßig deaktiviert.

TLS 1.0

TLS 1.0 wurde erstmals im Januar 1999 in RFC 2246 als Upgrade von SSL 3.0 beschrieben. Obwohl zwischen TLS 1.0 und SSL 3.0 keine signifikanten Unterschiede bestehen, konnten die Protokolle nicht zusammenarbeiten. Darüber hinaus war es möglich mit TLS 1.0 eine SSL 3.0-Verbindung einzurichten, welches jedoch die Sicherheit schwächt. Im Jahr 2011 wurde diese Version von Thai Duong und Juliano Rizzo geknackt, wodurch diese Version als sicheres Protokoll unbrauchbar wurde.

TLS 1.1

TLS 1.1 wurde im April 2006 veröffentlicht und in RFC4346 beschrieben. TLS 1.1 ist ein Update und eine Weiterentwicklung zur Version 1.0. Diese Version bietet mehrere Verbesserungen, z.B. verbesserte Sicherheit und Handhabung von Fehlern. Trotz der verbesserten Funktionalität wird diese Version kaum genutzt.

TLS 1.2

TLS 1.2 wurde im August 2008 veröffentlicht und in RFC5246 beschrieben. TLS 1.2 ist eine Weiterentwicklung der Version 1.1 mit einer Reihe von signifikanten Verbesserungen, darunter:

Verwendete kryptografische Hashes, die sich als unsicher erwiesen haben, wurden durch SHA-256 ersetzt.
Verbesserte Unterstützung für modernere Verschlüsselungsmethoden aus dem Advanced Encryption Standard.
Fallback-Kompatibilität mit der unsicheren SSL 2.0 Version wurde entfernt.

TLS 1.3

TLS 1.3 wurde im März 2018 fertiggestellt und der Änderungsantrag wurde am 10. August 2018 veröffentlicht. Wichtige Browser wie Chrome und Firefox unterstützen dies bereits ab Version 56 bzw. 52. Im Januar 2021 hat das National Cyber Security Center seine Empfehlung auf 1.3 angepasst, wobei der Status von 1.2 von gut auf ausreichend herabgestuft wurde. TLS 1.3 ist widerstandsfähiger gegen (zukünftige) Angriffstechniken und auch einfacher sicher zu konfigurieren als der Vorgänger TLS 1.2, und die meisten Software-Bibliotheken unterstützen das Protokoll inzwischen.

TLS 1.3 ist eine Weiterentwicklung der Version 1.2 mit einer Reihe von wichtigen Verbesserungen, darunter:

Erhöhte Geschwindigkeit, im Vergleich zur Vorgängerversion ist nur noch ein Round Trip erforderlich.
Erhöhte Sicherheit, veraltete und unsichere Funktionen wie SHA1 und MD5 wurden entfernt.