Transport Layer Security
aus Wikipedia, der freien Enzyklopädie
| Anwendung | HTTPS | IMAP | ... | |
| Transport | SSL/TLS | |||
| TCP | ||||
| Netzwerk | IP | |||
| Netzzugang | Ethernet | Token Ring |
FDDI | ... |
Transport Layer Security (TLS) oder Secure Sockets Layer (SSL) ist ein Verschlüsselungsprotokoll für Datenübertragungen im Internet. TLS 1.0 und 1.1 sind die standardisierten Weiterentwicklungen von SSL 3.0. Hier wird die Abkürzung SSL für beide Bezeichnungen verwendet.
Inhaltsverzeichnis |
[Bearbeiten] Funktionsweise
Im OSI-Modell ist SSL oberhalb der Transportschicht (z. B. TCP) und unter Anwendungsprotokollen wie HTTP oder SMTP angesiedelt. SSL arbeitet transparent, so dass es leicht eingesetzt werden kann, um Protokollen ohne eigene Sicherheitsmechanismen abgesicherte Verbindungen zur Verfügung zu stellen. Zudem ist es erweiterbar, um Flexibilität und Zukunftssicherheit bei den verwendeten Verschlüsselungstechniken zu gewährleisten.
SSL-Protokolle in der Übersicht
Das SSL-Protokoll besteht aus zwei Schichten (layers):
| SSL Handshake Protocol | SSL Change Cipherspec. Protocol | SSL Alert Protocol | SSL Application Data Protocol |
| SSL Record Protocol | |||
[Bearbeiten] SSL Record Protocol
Das SSL Record Protocol ist die untere der beiden Schichten und dient der Absicherung der Verbindung. Es setzt direkt auf der Transportschicht auf und bietet zwei verschiedene Dienste, welche einzeln und gemeinsam genutzt werden können:
- Ende-zu-Ende-Verschlüsselung mittels symmetrischer Algorithmen. Der verwendete Schlüssel wird dabei im Voraus über ein weiteres Protokoll (z. B. das SSL Handshake Protocol) ausgehandelt und ist einmalig für die Verbindung. SSL unterstützt für die symmetrische Verschlüsselung u. a. DES und Triple DES.
- Sicherung der Nachrichten-Integrität und Authentizität durch Bildung einer kryptografischen Prüfsumme u. a. SHA-1 und MD5
Außerdem werden zu sichernde Daten in Blöcke von maximal 65.536 Byte fragmentiert und beim Empfänger wieder zusammengesetzt. Auch können die Daten vor dem Verschlüsseln und vor dem Berechnen der kryptographischen Prüfsumme komprimiert werden. Das Komprimierungsverfahren wird ebenso wie die kryptographischen Schlüssel mit dem SSL Handshake-Protokoll ausgehandelt.
[Bearbeiten] SSL Handshake Protocol
Das SSL Handshake Protocol baut auf dem SSL Record Protocol auf und erfüllt die folgenden Funktionen, noch bevor die ersten Bits des Anwendungsdatenstromes ausgetauscht wurden:
- Identifikation und Authentifizierung der Kommunikationspartner auf Basis asymmetrischer Verschlüsselungsverfahren und Public-Key-Kryptografie. Dieser Schritt ist optional. Für gewöhnlich authentifiziert sich aber zumindest der Server gegenüber dem Client.
- Aushandeln zu benutzender kryptografischer Algorithmen und Schlüssel. TLS unterstützt auch eine unverschlüsselte Übertragung.
Der Handshake selbst kann in vier Phasen unterteilt werden:
Phase 1: Der Client schickt zum Server ein client_hello und der Server antwortet dem Client mit einem server_hello. Die Parameter der Nachrichten sind eine Zufallszahl, die später verwendet wird, um den pre-master-secret zu bilden (sie schützt damit vor Replay-Attacken), die höchste vom Initiator der Nachricht beherrschte SSL-Version, eine Session ID und die zu verwendende Cipher Suite.
Phase 2: Die Phase ist optional. Der Server identifiziert sich gegenüber dem Client. Hier wird auch das X509v3-Zertifikat zum Client übermittelt.
Phase 3: Die Phase ist optional. Hier identifiziert sich der Client gegenüber dem Server. Auch hier kann das X509v3-Zertifikat des Client übermittelt werden. Der Client versucht außerdem, das Zertifikat, das er vom Server erhalten hat, zu verifizieren (bei Misserfolg wird die Verbindung abgebrochen). Dieses Zertifikat enthält den öffentlichen Schlüssel des Servers. Das pre-master-secret wird hierbei, falls die Cipher Suite RSA genutzt wird, durch den im Zertifikat bekannten öffentlichen Schlüssel ausgetauscht. Hierbei kann auch das Diffie-Hellman-Verfahren verwendet werden.
Phase 4: Diese Phase schließt den Handshake ab. Aus dem vorhandenen pre-master-secret kann das Master Secret abgeleitet werden und aus dieser der einmalige Session Key. Das ist ein einmalig benutzter symmetrischer Schlüssel, der während der Verbindung zum Ver- und Entschlüsseln der Daten genutzt wird. Mit den Nachrichten, die die Kommunikationspartner sich nun gegenseitig zusenden, geben sie an, ab jetzt nur noch – wie ausgehandelt – verschlüsselt zu übertragen.
[Bearbeiten] Berechnung des Master Secrets
Aus dem pre-master-secret wird mit Hilfe der Hash-Funktionen SHA-1 und MD5 das Master Secret berechnet. In diese Berechnung fließen zusätzlich die Zufallszahlen der Phase 1 des Handshakes mit ein. Es werden hierbei beide Hash-Funktionen verwendet, um sicherzustellen, dass das Master Secret immer noch geschützt ist, falls eine der Funktionen als kompromittiert gilt.
[Bearbeiten] Vorteile/Nachteile
Der Vorteil des SSL-Protokolls ist die Möglichkeit, jedes höhere Protokoll auf Basis des SSL-Protokolls zu implementieren. Damit ist eine Unabhängigkeit von Anwendungen und Systemen gewährleistet.
Der Nachteil der SSL-verschlüsselten Übertragung besteht darin, dass der Verbindungsaufbau auf Serverseite sehr rechenintensiv und deshalb etwas langsamer ist. Die Verschlüsselung selbst nimmt je nach verwendetem Algorithmus nur noch wenig Rechenzeit in Anspruch. Die verschlüsselten Daten können von transparenten Kompressionsverfahren (etwa auf PPTP-Ebene) kaum mehr komprimiert werden. Als Alternative bietet das TLS-Protokoll ab Version 1.0 die Option, die übertragenen Daten mit ZLib zu komprimieren, dies wird jedoch in der Praxis vor allem aus Performancegründen kaum eingesetzt.
SSL verschlüsselt nur die Kommunikation zwischen zwei Stationen. Es sind jedoch auch Szenarien (insbesondere in Serviceorientierten Architekturen) denkbar, in denen eine Nachricht über mehrere Stationen gesendet wird. Wenn jede dieser Stationen aber nur einen Teil der Nachricht lesen darf, reicht SSL nicht mehr aus, da jede Station alle Daten der Nachricht entschlüsseln kann. Somit entstehen Sicherheitslücken an jeder Station, die nicht für sie bestimmte Daten entschlüsseln kann.
[Bearbeiten] SSL in der Praxis
SSL-Verschlüsselung wird heute vor allem mit HTTPS eingesetzt. Die meisten Webserver unterstützen TLS, viele auch SSLv2 und SSLv3 mit einer Vielzahl von Verschlüsselungsmethoden, fast alle Browser und Server setzen jedoch bevorzugt TLS mit RSA- und AES-Verschlüsselung ein.
SSL ist ohne eine zertifikatsbasierte Authentisierung problematisch, wenn ein Man-In-The-Middle-Angriff erfolgt: Ist der MITM vor der Übergabe des Schlüssels aktiv, kann er mit beiden Seiten den Schlüssel tauschen und so den gesamten Datenverkehr im Klartext mitschneiden.
In Verbindung mit einem Virtual Server, z. B. mit HTTP (etwa beim Apache HTTP Server über den VHost Mechanismus), ist es grundsätzlich als Nachteil zu werten, dass pro IP-Adresse nur ein Zertifikat verwendet werden kann, da die eigentlichen Nutzdaten des darüber liegenden Protokolls (und damit der Name des VHosts) zum Zeitpunkt des SSL/TLS Handshakes noch nicht übertragen wurden. Dieses Problem soll in der nächsten TLS-Version 1.2 mit der "Server Name Indication" behoben werden. Dabei wird bereits beim Verbindungsaufbau der gewünschte Servername mitgesendet.
Zusammen mit SSL-Zertifikaten versuchen die Trust Center häufig, nutzlose Site Seals zu verkaufen.
Weitere bekannte Anwendungsfälle für SSL sind POP3, SMTP, NNTP, SIP, IMAP, IRC und MBS/IP, FTP und EAP-TLS.
[Bearbeiten] Software
Bekannte Implementierungen des Protokolls sind OpenSSL und GnuTLS.
[Bearbeiten] Geschichte
- November 1993: erstes Release von Mosaic 1.0 von National Center for Supercomputing Applications (NCSA). Mosaic war der erste verbreitete Webbrowser.
- Nur neun Monate später veröffentlichte Netscape Communications die erste Version von SSL (1.0).
- Fünf Monate später wurde schon der nächste Release SSL 2.0 veröffentlicht, dieser deckte sich auch gerade mit der neuen Version des Netscape Navigator.
- Ende 1995 kam Microsoft mit der ersten Version seines Browsers (Internet Explorer) heraus. Kurz darauf wurde auch die erste Version ihres SSL-Pendants bekannt, PCT 1.0 (Private Communication Technology). PCT hatte einige Vorteile gegenüber SSL 2.0, und diese wurden dann auch in SSL 3.0 aufgenommen.
- Als SSL von der IETF im RFC 2246 als Standard festgelegt wurde, benannte man es im Januar 1999 um zu Transport Layer Security (TLS). Die Unterschiede zwischen SSL 3.0 und TLS 1.0 sind sehr klein. Doch dadurch entstanden Versions-Verwirrungen. So meldet sich TLS 1.0 im Header als Version SSL 3.1.
- Später wurde TLS durch weitere RFCs erweitert:
- RFC 2712 – Addition of Kerberos Cipher Suites to Transport Layer Security (TLS).
- RFC 2817 – Upgrading to TLS Within HTTP/1.1 erläutert die Benutzung des Upgrade-Mechanismus in HTTP/1.1, um Transport Layer Security (TLS) über eine bestehende TCP-Verbindung zu initialisieren. Dies erlaubt es, für unsicheren und für sicheren HTTP-Verkehr die gleichen „well-known“ TCP Ports (80 bzw. 443) zu benutzen.
- RFC 2818 – HTTP Over TLS trennt sicheren von unsicherem Verkehr durch Benutzung eines eigenen Server TCP Ports.
- RFC 3268 – Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS) nutzt die Erweiterbarkeit von TLS und fügt den bisher unterstützten symmetrischen Verschlüsselungsalgorithmen (RC2, RC4, International Data Encryption Algorithm (IDEA), Data Encryption Standard (DES) und Triple DES) den Advanced Encryption Standard (AES) hinzu.
- April 2006 wurde in RFC 4346 die Version 1.1 von TLS standardisiert und damit RFC 2246 obsolet. In TLS 1.1 wurden kleinere Sicherheitsverbesserungen vorgenommen und Unklarheiten beseitigt.
[Bearbeiten] Siehe auch
[Bearbeiten] Literatur
- Eric Rescorla: SSL and TLS: designing and building secure systems. Addison-Wesley, Boston 2001. ISBN 0-201-61598-3
- Roland Bless et al.: Sichere Netzwerkkommunikation, Springer Verlag, 2005, ISBN 3-540-21845-9
[Bearbeiten] Weblinks
- TLS-Arbeitsgruppe der IETF
- SSL 3.0 Spezifikation
- SSL Security Forum
- mozilla.org – Mozilla’s Network Security Services (NSS), MPL/GPL-lizenziert
- FAQ: SSL Grundlagen der VeriSign Deutschland GmbH
- Serversniff.de ermittelt Zertifikatsinfos, angebotene Handshakeprotokolle und Verschlüsselungsmethoden von TLS/SSL-Servern
- [1] Beschreibt Handshake und Protokoll im Detail
- PCA-Bibliothek – Zertifizierungsinstanz des Deutschen Forschungsnetzes
- cacert.org – Eine Community, die kostenlose SSL-Zertifikate ausstellt
- openssl.org – Open Source SSL Toolkit
- Test Zertifikate - Anleitung zum Erstellen selbst signierter Zertifikate
