Man unterscheidet zwischen Verschlüsselung und Authentifikation.

Eine Authentifikation kann grundsätzlich mit Passwort erfolgen, das ist jedoch nur solange sicher, solange das Passwort niemand mitlesen kann.

Gerade innerhalb von nicht gesichterten Netzwerken (z.B. Internetzugänge in Studentenwohnheimen) kann prinzipiell jeder alles mitlesen (sniffen), da der gesamte Datenverkehr über das Kabel an der eigenen Netzwerkkarte anliegt. Die Netzwerkkarte wird dazu in den "Promiscious Mode" geschaltet, dann leitet diese alle Netzwerkpakete an den Netzwerkstack des Betriebssystems weiter, ansonsten nur die, die für sie bestimmt sind (wird über ARP gesteuert, bzw. die MAC-Adresse der NWKarte).

In solchen Netzen sollten Passwörter daher nur verschlüsselt übertragen werden. Nun kann man sich auf einen permanenten Schlüssel festlegen, was jedoch unsicher ist, da es immer nur eine Frage der Zeit ist, einen Schlüssel zu "knacken". Es ist daher wesentlich sicherer, von Zeit zu Zeit den Schlüssel zu ändern. Es versteht sich von selbst, daß ein Schlüssel mindestens genauso wichtig ist wie ein Passwort und daher nicht über das Netzwerk selbst übertragen werden darf. Noch sicherer ist, wenn die Kommunikationspartner den Schlüssel selbst nicht kennen. Aber wie soll das gehen?

Public Key

Beim Public-Key-Verfahren besitzt jeder Kommunikationspartner einen privaten Schlüssel, den er unter allen Umständen geheim halten muß. Zusätzlich besitzt er einen öffentlichen Schlüssel, der - wie der Name schon sagt - für alle bekannt sein darf. Beide Schlüssel haben einen streng mathematischen Bezug zueinander: Der öffentliche Schlüssel wird aus dem privaten Schlüssel generiert, umgekehrt ist das jedoch nicht möglich.

Am Anfang einer SSL-Verbindung werden nun die öffentlichen Schlüssel unter den zwei Kommunikationspartnern ausgetauscht, sodaß jeder den Public Key des anderen besitzt. Aus dem Public Key des anderen und dem eigenen privaten Schlüssel wird nun ein dritter Schlüssel errechnet, mithilfe dessen nun die Daten selbst verschlüsselt werden. Ein mathematischer "Trick" hat zur Folge, daß beide Partner im Prinzip den gleichen Schlüssel besitzen. Wer diese Kommunikation mitliest, kann diesen Schlüssel jedoch nicht rekonstruieren.

Ein kleines, unvollständiges Beispiel

Die beiden Public Keys ap und bp werden ausgetauscht, jeder errechnet einen "Zwischenwert" Z und sendet diesen dem Partner:

Jeder kann nun aus dem eigenen privaten Schlüssel und dem "Zwischenwert" des anderen einen gemeinsamen Schlüssel S errechnen:

Ein Angreifer, der nun mithört und so zu ap, bp, aZ und bZ kommt, kann daraus NICHT den Schlüssel S errechnen. (In diesem Beispiel wäre dies zwar möglich, weil die Potenzfunktion umkehrbar ist, in der Praxis wird jedoch eine nicht umkehrbare Funktion verwendet.)

Für das Public-Key-Verfahren zur Erzeugung eines sicheren Schlüssels (S) kann jederzeit ein neues Schlüsselpaar (private+public) erzeugt werden. Das Passwort für die Authentifikation z.B. ggü. dem Mailserver wäre ausreichend gegen Abhören verschlüsselt.

Man-in-the-middle Attacke

Was aber, wenn jemand die Verbindung unterbricht und sich "dazwischen klemmt"? Dann denkt A, er kommuniziere mit B, und andersherum; in Wirklichkeit kommuniziert aber jeder mit dem Angreifer, der die Identität des jeweils anderen vortäuscht. A bildet nun, ohne es zu wissen, einen gemeinsamen Schlüssel mit dem Angreifer, ebenso B. Der Angreifer sieht dann die tatsächlichen Daten und braucht sie nur jeweils weiterzuleiten, ohne daß A oder B etwas davon mitbekommen.

Um dies zu verhindern, hat man Zertifikate eingeführt. Ein Zertifikat ist ein signierter Public Key und weist u.a. den Hostnamen des Besitzers aus. Zielgedanke ist, daß B das (maßgeblich) von A gesendete Zertifikat überprüfen kann, und diese Überprüfung fehlschlägt, wenn ein Angreifer das Zertifikat von A fälscht.

Der Angreifer kann nicht das echte Zertifikat von A verwenden, da dies nur den Public Key von A enthält aber nicht den privaten Key. Der Angreifer braucht aber ein korrespondierendes Private/Public Key Paar, muß sich also selbst ein solches generieren. Er will sich aber dennoch als A ausgeben.

Grundsätzlich könnte der Angreifer nun seinen selbst erstellten Public Key mit falschem Hostnamen (host von A) auch selbst signieren. Selbst signierte Zertifikate sind daher wertlos. B wird daher nur Zertifikate akzeptieren, die von einer vertrauenswürdigen Zertifizierungsstelle wie Verisign o.ä. signiert wurden.

Vertrauenswürdig ist eine Zertifizierungsstelle natürlich dann, wenn diese selbst zertifiziert ist, usw. Hierdurch entsteht ein Pfad von Zertifizierungen, an dessen Ende soganannte Root-CAs stehen, d.h. einige wenige selbstsignierte Zertifikate von sogenannten "Root Certification Authorities". Auch Versign zählt hierzu. Jedes aktuelle Betriebssystem besitzt einen Zertifikatspeicher, in dem solche CAs gespeichert sind, d.h. durch den Benutzer als vertrauenswürdig eingestuft werden. Nur Zertifikate, deren "Pfad" zu einem dieser dort aufgeführten Root-CAs führen, werden als vertrauenswürdig anerkannt.

In allen anderen Fällen erfolgt eine Fehlermeldung. Beim IE typischerweise als Warnhinweis angezeigt: "Zertifizierungsinstitution/Datum/Name". Während ein abgelaufenes Datum das kleinere Problem darstellt, sind beide anderen Fälle ein dringender Grund, die weitere SSL-Verbindung abzubrechen! Man kann sich jedoch auch den Zertifizierungspfad anzeigen lassen, und ein ggf. neues Root CA installieren, wenn man sich sicher ist, daß man tatsächlich mit der korrekten Gegenseite redet.

Zertifikate lassen sich auch widerrufen, z.B. wenn diese mißbräuchlich verwendet werden. Daher gibt es auch die Möglichkeit, beim Aussteller "auf zurückgerufene Zertifikate" zu prüfen. Das ist ein zusätzlicher Sicherheitsgewinn.

Authentication

Bei SSL unterschiedet man nun zwischen der sehr häufigen "Server Authentication" und der äußerst seltenen "Client Authentication".

Um o.g. MITM-Attacken zu verhindern, benutzen SSL-Server eigentlich immer Zertifikate. Dies ist die "Server Authentication". Der Client hat damit die Möglichkeit zu prüfen, ob er auch mit dem richtigen Host verbunden ist. "Er hat die Möglichkeit" bedeutet jedoch, daß er kann aber nicht muß. Ihm steht es natürlich frei, das Zertifikat nicht zu überprüfen und den darin enthaltenen Public Key wie vorgesehen zu verwenden.

Bei der Client-Authentication authentifiziert sich der Client mit einem Zertifikat ggü. dem Server. Hierbei kann der Server natürlich überprüfen, ob das Client-Zertifikat ggf. durch den Serverbetreiber selbst ausgestellt wurde, was z.B. als Ersatz für eine Passwort-Anmeldung dienen kann. Nachteil ist jedoch, daß solche Client-Zertifikate vor ihrer Verwendung installiert werden müssen, was z.B. auf den PCs eines Internet-Cafes tunlichst unterlassen werden sollte! Zertifikate sollten also nur auf den Systemen installiert und verwendet werden, die der absoluten Kontrolle des Zertifikat-Besitzers unterliegen und zu denen kein anderer Zugang hat.

Ob, wie, und welche Zertifikate SSL verwenden soll, muß daher gut überlegt und konfiguriert sein.

Namenskonventionen

Private Keys werden meist als *.key gespeichert, Public Keys als *.pub und signierte Public Keys als *.crt.

Vollständige Zertifikate werden wegen besserer "Lesbarkeit" auch in anderen Formaten gespeichert, z.B. als PEM (*.pem), x509 (*.cer), pkcs7 (*.p7b).

Einige Formate, z.B. pkcs12 (*.p12) sind in der Lage, Public und Private Key aufzunehmen. (Das ist z.B. für den Im- und Export von Zertifikaten sinnvoll.)