SSL - was ist das?

Sicherheit im Internet

Jeder hat wohl schon einmal den Präfix "https://" in der Adressleiste seines Browsers bemerkt oder den Link "Secure Login" in einem Online Shopping Portal oder bei seinem Webmail-Provider ausgewählt. Verständlich - wir alle wollen Sicherheit, oder sollten danach streben, wenn es um den Schutz persönlicher Informationen geht.

Das "S" in HTTPS steht für "secure", also "sicher". Im Gegensatz zum meistens eingesetzten HTTP werden bei HTTPS alle übertragenen Daten über das SSL- bzw. TLS-Protokoll (Secure Sockets Layer / Transport Layer Security) zwischen den Verbindungspartnern verschlüsselt und damit für Dritte unzugänglich gemacht. Außerdem kann sichergestellt werden, dass es sich beim jeweiligen Verbindungspartner (in diesem Fall der Website bzw. deren Betreiber) auch wirklich um den gewünschten Kontakt - und nicht etwa um einen Angreifer der sich in die Verbindung "einklinkt" - handelt.

Wer hat SSL entwickelt, wann ist das passiert, und aus welchem Grund?

"Das" Protokoll des Internets (besser gesagt, die Protocolsuite) - TCP - gewährleistet zwar eine hohe Zuverlässigkeit bei der Datenübertragung, Punkto Authentizität (Garantie, dass der mit dem ich "rede" auch der ist, der er vorgibt zu sein), Integrität (das was ich erhalte, bzw. sende ist/wird nicht manipuliert) und Verschlüsselung (der tatsächliche Inhalt der Datenübertragung kann nicht von Dritten abgehört werden), ist TCP/IP aber als unzureichend zu betrachten.

Aus diesem Grund machte sich Netscape Communications 1994 daran, diesen Zustand zu ändern.

Eine kurze Geschichte von SSL:

Protokollentwurf Version 1.0 im Juli 1994
Erste Veröffentlichung bzw. Produkte im Dezember 1994 mit SSL v2.0
Referenz-Implementierung "SSLRef 2.0" im April 1995
- Zu diesem Zeitpunkt gab es schon viel Implementierungen, die jedoch unabhängig voneinander waren
Im Juli 1995 wurde SSL zu einer sogenannten "BOF@ IETF", d.h. die Internet Engineering Task Force erstellte Milestones und Charts - sprich verteilte Arbeit - um es zu einem Standard zu machen.
Im November 1995 wurde SSL v3.0 veröffentlicht.
Januar 1999 wurde RFC 2246 "The TLS Protocol Version 1.0" veröffentlicht (= SSL v3.1) und als Proposed Standard festgelegt.

Wie macht das SSL?

Folgende kryptographische Methoden werden verwendet, um die oben angesprochene Sicherheit (Integrität, Authentizität, Verschlüsselung) zu erreichen:

symmetrische Verschlüsselung
asymmetrische Verschlüsselung
sichere Hashfunktionen

Nun zu den einzelnen Methoden:

Symmetrische Verschlüsselung

Bei der symmetrischen Verschlüsselung wird für die Ver- und Entschlüsselung derselbe Schlüssel (key) verwendet. Damit ist das Ver- und Entschlüsseln von großen Datenmengen in einem vertretbaren Zeitrahmen möglich. Das Problem hierbei ist aber die Übertragung des verwendeten Schlüssels: Wie sage ich der Stelle mit der ich verschlüsselt kommunizieren will, welchen Schlüssel ich benutze, ohne dass es andere erfahren können?

Die Lösung hierfür liegt in der asymmetrischen Verschlüsselung:

Hierbei werden unterschiedliche Schlüssel zum Ver- und Entschlüsseln verwendet. Der eine ist öffentlich bekannt (Public Key), der andere soll geheim gehalten werden (Private Key). Kurz gesagt: Wenn ich etwas mit dem Public Key verschlüssele, ist nur der Besitzer des Private Keys dazu in der Lage den verschlüsselten Text wieder zu entschlüsseln. Der Nachteil der asymmetrischen Verschlüsselung ist, dass sie relativ aufwändig und langsam ist.

In der Praxis wird darum meistens eine Kombination beider Verfahren angewendet.

Hashfunktionen:

Eine Hashfunktion ist eine mathematische Einweg-Funktion (Falltür-Funktion), bei der eine beliebig lange Eingabe, eine Ausgabe mit konstanter, kleiner Länge liefert; damit lassen sich relativ einfach Prüfsummen generieren. Man kann damit aus dem Input den Output berechnen, wenn man allerdings nur den Output kennt, kann man keine Aussage über den Input machen. Hashfunktionen kommen bei digitalen Signaturen zum Einsatz.

Digitale Zertifikate:

Ein digitales, X509 konformes Zertifikat kann als Ausweis betrachtet werden. Es wird meist von einer offiziellen CA (Certification Authority) ausgestellt, und enthält den Public Key des Besitzers des Zertifikates, eine Seriennummer, den Namen und das Ablaufdatum. Weiters ist in ihm die Digitale Signatur der CA enthalten. Die CA bürgt dafür, dass der Besitzer des Zertifikats derjenige ist, der er vorgibt zu sein (und lässt sich dafür üblicherweise gut bezahlen).

Dadurch ist der jeweils zum Zertifikat gehörige Public Key eindeutig zuzuordnen, d.h. ich weiß wer mein Gegenüber ist und jemand (dem ich hoffentlich vertraue) bürgt dafür!

Wie läuft eine SSL-Verbindung ab?

Fordert ein Client eine über HTTPS erreichbare Webseite an, so beginnen sein Rechner und der Server der Webseite miteinander zu kommunizieren. Zuerst handeln die beiden aus, welche Version von SSL sie verwenden wollen. Ist das erledigt, müssen sie sich darüber einig werden, welches asymmetrische Verfahren sie verwenden, um den Schlüssel für die schnellere symmetrische Verschlüsselung auszutauschen, und dabei nicht Gefahr zu laufen, diesen preiszugeben. Ist das erledigt, tauschen sie noch Zertifikate aus, zumindest jedoch sendet der Server seines an den Client, der überprüft

ob das Zertifikat zum URL passt,
ob er die digitale Signatur bereits kennt. Falls nicht, gibt er eine Warnung aus, verschlüsselt aber bei entsprechender Entscheidung des Benutzers trotzdem.

Ist das erledigt, tauschen beide über das vorher gewählte, asymmetrische Verschlüsselungsverfahren ihre Schlüssel aus und legen so fest, welchen sie für die symmetrische, schnellere Verschlüsselung verwenden. Danach erhält der Client eine "Session ID", eine eindeutige Nummer welche die Transaktion identifiziert.

Was macht SSL nicht?

SSL ist nicht das Allheilmittel für ein sicheres Internet. Benutzt ein Server SSL, um mit dem Client zu kommunizieren, ist dieser Übertragungsweg sicher, aber was mit den Daten danach auf dem Server passiert liegt nicht mehr im Bereich von SSL. Hier muss man weiterhin dem Betreiber des Servers (der Website) bzw. dessen technischer Kompetenz trauen.

Bruce Schneier - Autor des Buches "Applied Cryptographie" (gewissermaßen die Bibel der Kryptographie) - meinte einmal:

Benutzt man SSL [oder allgemein Kryptographie], um seine Kreditkartennummer sicher zu übertragen, so ist das, als wenn man in einer Pizzeria beim Bezahlen die Kreditkarte der Bedienung gibt, diese, von zwei schwerbewaffneten Soldaten beschützt, die Transaktion durchführt und die Karte zurückgibt. Alle sind zufrieden, der Kreditkarte ist nichts passiert. Was aber, wenn der Beleg in der Pizzeria auf das schwarze Brett geheftet wird, dieses gleich neben dem Hinterausgang hängt, der stets sperrangelweit offen ist?

Quellen bzw. weiterführende Literatur zu SSL & Kryptographie:

Spezifikation von SSL v3.0: http://wp.netscape.com/eng/ssl3/3-SPEC.HTM

SSL Basics http://mailman.sil.at/pipermail/cd/2002-May/000095.html

Usenet: sci.crypt FAQ (gefunden auf Cypherpunks Homepage)

SSL-Talk List FAQ

A Cryptographic Compendium http://home.ecn.ab.ca/~jsavard/crypto/jscrypt.htm

The PKI page - SSL/TLS: http://www.pki-page.org/#SSL

SSL-Zusammenfassung: http://www1.tfh-berlin.de/~toby/vs/ssl/

RFC 2246 http://www.ietf.org/rfc/rfc2246.txt

Die Bibel: "Applied Cryptography" von Bruce Schneier (ISBN:0471117099)

For Fun: "Cryptonomicon" von Neal Stephenson (ISBN:0060512806)

Einstiegsliteratur: "Geheime Botschaften" von Simon Singh (ISBN:3423330716)