SSL/TLS – Ein Überblick

SSL (Secure Sockets Layer), auch TLS (Transport Layer Security) genannt, ist ein Verschlüsselungsprotokoll für Datenübertragungen im Internet. Damit können sensible Daten nicht gelesen bzw. manipuliert werden können.

  1. Geschichte
  2. Technik
  3. Praxis
  4. Kritik

1. Geschichte

SSL gibt es seit August 1994 (v1.0) und wurde ursprünglich von der Firma Netscape für den gleichnamigen Browser entwickelt. Bereits neun Monate später veröffentlichte Netscape die Version 2.0 und im November 1996 dann Version 3.0.

Als SSL (TLSP als Protokollnummer 56) im Januar 1999 in die Internetprotokollfamilie (IETF) aufgenommen wurde, änderte man die Bezeichnung in TLS mit der ersten Version 1.0 (auch als SSL 3.1 bezeichnet). TLS hat bis heute einige wichtige Erweiterungen erfahren, etwa um den Verschlüsselungsstandard AES (Advanced Encryption Standard).

Heute unterstützen alle gängigen Browser TLS. Aktuell ist die SSL-Version 3.0 und ihr Nachfolger TLS 1.0 (Transport Layer Security). Die frühere Version 2.0 wird zwar noch unterstützt, so hat aber etwa die Mozilla Organisation bereits angekündigt, daß zukünftig nur noch 3.0 (TLS 1.0) in ihren Browser verwendet werden wird.

2. Technik

Bevor wir uns die Funktionsweise von TLS 1.0 an einem Beispiel anschauen, müssen wir noch ein paar technische Grundbegriffe klären. Das TLS-Protokoll ist im Protokollstapel des OSI-Modells in der Sitzungsschicht (Layer 5) zu finden, setzt also auf der Transportschicht (TCP, UDP, etc.) auf.

TLS dient der Verschlüsselung von Daten der höheren Protokollebenen 6 und 7 gemäß OSI, was der Anwendungsschicht im TCP/IP-Modell entspricht. Ein großer Vorteil von TLS ist seine Unabhängigkeit bezüglich der Anwendungsebene, was eine flexible, designspezifische Implementierung möglich macht.

TLS seinerseits besteht wiederum aus zwei Schichten: (i) dem TLS Record Protocol und (ii) dem darauf aufsetzenden TLS Handshake Protocol (genauer gesagt gehören in die zweite Schicht weitere Protokolle: Change Cipherspec. Protocol, Alert Protocol und das Aplication Data Protocol u2013 wir kümmern uns hier aber nur um das Handshake Protocol).

Das Record Protocol dient der Verbindungssicherheit und kann die Daten mittels symmetrischer Verschlüsselung vor Spionage und via MAC ashing (Message Authentication Code Hash) vor Manipulation schützen.

Basierend auf diesen Sicherheitsmechanismen dient das Handshake Protocol der Identifizierung bzw. Authentifizierung von Client und Server, dem sicheren Aushandeln von Verschlüsselungsverfahren sowie dem Austausch der Schlüssel. Das Ganze passiert, noch bevor auch nur ein Bit auf der Anwendungsebene übertragen wurde.

Etwas vereinfacht passiert beim Handshake dann zwischen ihrem Rechner (Client) und der Webseite (Webserver) Folgendes:

1. Hallo Client und Server begrüßen sich und tauschen Zufallswerte aus. Zudem wir eine Sitzungs-ID (session identifier) ausgetauscht. Wenn Client und Server später eine bestehende Sitzung fortsetzen oder duplizieren wollen, müssen dann nur noch diese dann verschlüsselte ID und die passenden kryptograhischen Parameter ausgetauscht werden.
2. Wie wollen wir es machen? Beide Seite tauschen die notwendigen kryptographischen Parameter (cipher spec) für den premaster secret aus.
3. Wer bist Du? Optional authentifizieren sich Client (derzeit wenig verbreitet) und Server (heute Standard) mit Hilfe von Zertifikaten oder öffentlichen Schlüsseln. Insbesondere kann der Server ein X509v3-Zertifikat senden, das der Client gegenüber dem Stammzertifikat (root certificate) einer ihm (d.h. dem Browser) bekannten Zertifikatsstelle (CA) zu verifizieren versucht.
4. Bist Du’s wirklich? Ist das Zertifikat verifiziert, wird aus den übermittelten Zufallswerten und dem premaster secret der master secret generiert.
5. Ok, so wird’s gemacht. Die gewonnenen Sicherheitsparameter werden dem Record Protocol bereitgestellt.
6. Prima, funktioniert. Test und Vergleich der von Client und Server ermittelten Sicherheitsparameter und Aufbau der sicheren Verbindung.

3. Praxis

TLS wird heutzutage vorrangig im World Wide Web eingesetzt:
Um eine Webseite mit SSL/TLS aufzurufen, tippen sie statt http das Präfix https ein, z.B. https://www.dergrossebruder.org. Das zusätzliche ’s‘ steht für SSL. Die dabei am häufigsten verwendeten Algorithmen sind RSA (benannt nach den Erfindern Ronald L. Rivest, Adi Shamir und Leonard Adleman) und AES (Advanced Encryption Standard).

Ein wichtiger Punkt bei HTTPS ist die Verfifizierung des Server-Zertifikates: Sollte das in Punkt drei vom Server gesendete Zertifikat nicht von einer dem Browser (oder einer anderen betroffenen Anwendung) bereits bekannten CA signiert worden sein, wird Sie Ihr Browser darüber informieren. Sie werden anschließend gebeten, das Zertifikat der Webseite selbst explizit zu bestätigen.

Desweiteren können Sie ihren Browser mit Stammzertifikate weiterer CAs bekannt machen, wenn Sie den betreffenden CAs vertrauen. Zertifikate beugen möglichen sogenannten Man-In-The-Middle-Angriffen vor, bei denen ansonsten unter Umständen die zu tauschenden Schlüsselpaare manipuliert werden können. Die CAs können sich in Deutschland wiederum bei der Bundesnetzagentur als höchste nationale Instanz akkreditieren.

Neben dem World Wide Web kommt SSL/TLS in weiteren Anwendungen vor: Email (SMTP, IMAP), Chat (IRC), Internet-Telefonie (SIP) oder News (NNTP). Nähere Informationen finden Sie im RFC-Index (RFC = Requests for Comments) der IETF.

4. Kritik

Der große Vorteil von SSL/TLS ist die Unabhängigkeit dieser Übertragungsschicht von den darauf aufsetzenden Anwendungen. Damit lassen sich unterschiedlichste Anwendungen auf verschiedenen Systemen via SSL/TLS betreiben.

Nachteilig ist die recht hohe serverseitige Rechenintensität beim Verbindungsaufbau, d.h. beim Handshake. Die Verschlüsselung der Daten selbst ist weniger aufwendig.

 Autor: Peter Ulber
 Veröffentlichung: 21. November 2005
 Kategorie: Bericht
 Tags:

Schreibe einen Kommentar