SSL-Grundlagen

Diese Seite widmet sich ganz kurz der Einführung in die Grundlagen einer SSL-Verbindung. Ich möchte hier nicht auf die einzelnen Verschlüsselungsoptionen etc. eingehen, sondern einfach und verständlich die Funktion "SSL" am Beispiel eines Webservers aufzeigen und die verschiedenen Komponenten in Zusammenhang bringen.

Was ist SSL und was hat das mit privaten und öffentlichen Schlüsseln zu tun ?

SSL steht für Secure Socket Layer und steht letztlich die sichere Übertragung von Daten zwischen zwei Systemen. für jede Art einer Verschlüsselung benötigt man aber einen Schlüssel und wenn beide Kommunikationspartner von einander entfernt sind, ist es ziemlich unpraktisch, eben diesen Schlüssel "unsicher" über das Netzwerk zu übertragen. Glücklicherweise haben ein paar pfiffige Mathematiker eine Formen gefunden, bei der diese Schlüsselübertragung ebenfalls sicher möglich ist.

Der Trick dabei ist, dass man ein Schlüsselpaar erstellt und die Nachricht mit einem Schlüssel codiert und mit dem anderen Schlüssel decodiert wird. Dazu braucht man unter anderem sehr große Primzahlen. So kann ich dann einen Schlüssel "öffentlich" machen,. d.h. meinem Kommunikationspartner geben. Er verschlüsselt seine Informationen an mich dann mit diesem Schlüssel und ich bin der einzige der diese wieder lesen kann. In die Gegenrichtung nutze ich einfach den öffentlichen Schlüssel, den mir mein Kommunikationspartner gegeben hat. Aufgrund der Rechenleistung für dieses RSA-Verfahren werden über den Weg meist nur einmal eine Zufallszahl sicher übertragen, um dann günstigere Verfahren der Verschlüsselung (DES, 3DES) einzusetzen.

Um nun sicher zu gehen, dass der öffentliche Schlüssel, den mir die Gegenseite gibt, auch wirklich von dort kommt, kann dieser Schlüssel "digital unterschrieben" werden. Vergleichen Sie dies einfach mit ihrer ersten Bewerbung, bei der sie ein beglaubigtes Schulzeugnis vorlegen mussten. Der Personalchef hat dann anhand des Dienstsiegels das Dokument als "vertrauenswürdig" angesehen. In der Papierwelt können solche Stempel" leider einfacher gefälscht werden. Bei Computern sind dazu Zertifizierungsstellen erforderlich, deren Dienstsiegel sie digital vergleichen können. 

SSL ist übrigens nicht auf Webserver beschränkt, Auch SMTP, POP3 und IMAP4-Verbindungen können ähnlich gesichert werden. Neben der Verschlüsselung ist natürlich auch die Möglichkeit einer Identifizierung der Gegenstelle (Signierung) nutzbar. 

Wie greift das ineinander ?

Auf dem Bild weiter unten finden Sie drei Systeme, die in den Prozess involviert sind.

  • Zertifizierungsstelle
    Diese Instanz stellt Zertifikate aus
  • Webserver
    Dieser Server möchte gerne ein SSL-Zertifikat haben, um seine Dienste per SSL anzubieten
  • Client
    Der Client möchte gerne verschlüsselt mit dem Webserver kommunizieren

SSL Grundlagen

Dreh und Angelpunkt sind die Zertifikate der Zertifizierungsstellen.

Schritt Beschreibung

Jede Zertifizierungsstelle hat ein Zertifikat mit einem Namen und einem öffentlichen Schlüssel. Die Zertifizierungsstelle hat den dazu passenden privaten Schlüssel. Diese Zertifikat wurde von der CA selbst unterschieben (SelfSigned). Verglichen mit dem Zeugnis bedeutet das so viel, als wenn die Gemeinde sich selbst bestätigt, dass ihr Dienstsiegel korrekt ist. Das hört sich erst einmal verrückt an, aber führt nun dazu, dass diese Zertifizierung selbst ein Zertifikat erstellen und verteilen kann. Ein Zertifikat ist also nichts anderes als eine Information (Name, Gültigkeitsdatum, Public Key etc), die von jemandem bestätigt ist. Im Fall der Zertifizierungsstelle bezeichnen wir dieses besondere Dokument als "Stammstellenzertifikat", weil es die "Wurzel" ist und nicht von einer darüber stehenden Zertifizierungsstelle signiert wurde.

Was macht nun aber aus einem Zertifizierungsstellenzertifikat ein wertvolles Stammzertifikat? Hier kommen nun die Hersteller von Produkten ins Boot, die Zertifikate verwenden, Microsoft als Hersteller von Windows, Internet Explorer, Windows Mobile aber auch Firefox und diverse LINUX-Distributionen. Diese Hersteller nehmen solche Zertifikaten von Firmen, die Zertifikatsdienste anbieten und hoffentlich das entsprechend sicher betreiben, und packen Sie in das Produkt mit hinein. Sie als Anwender müssen davon ausgehen, dass die Hersteller sich dieses Stammzertifikat sicher von den Zertifizierungsstellen besorgt habe und diese gültig sind. Aus dem gleichen Grund sollten Sie z.B. nie einen Internet Explorer oder andere Programme aus unsicheren Quellen installieren. Ansonsten könnte jemand ihnen ja einen "veränderten" Browser mit falschen Zertifikaten unterschieben und letztlich die Sicherheit von SSL damit aufheben. Das "kann" für Firmen natürlich interessant sein, wenn der Proxy-Server auch SSL-Verbindungen aufbrechen soll und dazu dynamisch "passende" Zertifikate generiert. Aber das ist eine andere Sache und führt hier zu weit.

Damit die folgende Kette letztlich funktioniert, muss das Stammstellenzertifikat auf allen Systemen vorliegen. Beim Einsatz von "offiziellen" Zertifizierungsstellen ist dies in der Regel der Fall. Beim Einsatz einer eigenen privaten CA muss man als Administrator z.B. per Gruppenrichtlinien dafür sorgen, die Zertifikate zu Verteilen. Bei einer Windows "integrierten" CA ist das per Default schon so eingerichtet.

Nun beginnt die eigentliche Konfiguration:

Der Webserver benötigt einen privaten und einen öffentlichen Schlüssel, damit er an seine Clients den öffentlichen Schlüssel weitergeben kann. Dieser öffentliche Schlüssel muss aber signiert sein, damit der Client auch die Herkunft und Gültigkeit prüfen kann. Ansonsten sieht der Anwender eine Warnung. (Falscher Name, Zertifikat abgelaufen, nicht vertraute Zertifizierungsstelle). Ein solches Zertifikat kann der Server selbst errechnen und läßt isch nur den öffentlichen Schlüssel von einer CA signieren. Einige Zertifizierungsstellen erstellen ein komplettes Paar aus privatem Key und signiertem öffentlichen Schlüssel und übergeben dies an den Administrator. Erstes ist sicherer, da der private Schlüssel nicht übertragen werden muss während die zweite Option der Zertifizierungsstelle ein Speichern des Schüssel für spätere Wiederherstellungen erlaubt. Das ist besonders beim Einsatz für Dateiverschlüsselung oder Mailverschlüsselung ein Aspekt. (Stichwort Key Recovery)

Gehen wir davon aus, dass wir selbst ein Schlüsselpaar errechnen. Dasnn muss der öffentliche Schlüssel als Request zur Zertifizierungsstelle übermittelt werden. Die Anforderung enthält ihren Namen, die Firma aber auch den "Name des Webserver" (als DistinguishedName) und einige andere Daten.

Der Betreiber der Zertifizierungsstelle bürgt mit seinem guten Namen und wird daher diese Daten erst einmal prüfen und signiert dann die Daten. Sie holen sich die Antwort und verbinden Sie mit der ausstehenden Anforderung auf ihrem Webserver.

Das Zertifikat ist damit gültig, da ihr Webserver nun seinen privaten Schlüssel und einen durch eine Zertifizierungsstelle signierten öffentlichen Schlüssel hat.

Nun beginnt der Teil des Clients.

Der Browser macht eine HTTPS-Verbindung mit dem Webserver auf.

Der Webserver liefert nun zuerst sein Zertifikat zum Client. Das Zertifikat besteht aus dem signierten öffentlichen Schlüssel.

Der Client bekommt diesen Schlüssel und prüft die Signatur gegen die lokal vorhandenen "vertrauenswürdigen Stammzertifizierungsstellen". Je nach Konfiguration kann der Client noch die Rückrufliste (CRL) der ausstellenden CA prüfen.

Wenn das Zertifikats noch gültig ist (Zeit), der Name in der URL mit dem Zertifikatnamen übereinstimmt und der die Signatur bestätigt werden konnte, dann hat der Client nun einen gültigen öffentlichen Schlüssel, mit dem er nun seine Daten verschlüsselt an den Webserver senden kann. Er kann damit auch seinen Schlüssel sicher an den Webserver senden, mit dem die weitere Kommunikation verschlüsselt wird

War das alles ?

Diese Beschreibung ist absichtlich einfach. Ich habe auf einige Dinge verzichtet wie:

  • Zertifikatketten
    Die meisten Zertifizierungsstellen arbeiten mit Root-CAs, die ihrerseits so genannte "Issuer-CA" signieren, die dann die Zertifikate ausstellen
  • Zertifikatsrückruflisten
    Wird ein Zertifikat "veruntreut", gibt es Wege dieses als ungültig zu kennzeichnen. Dazu fragt der Client die im Zertifikat hinterlegte "Certificate Revokation List" (CRL) ab. Dies ist hier nicht weiter beschrieben
  • Kryptografische Verfahren
    Ich bin auch nicht weiter auf die eigentliche Schlüsselerstellung und die Verfahren wie RSA, MD5, DES, SHA etc. eingegangen.
  • Externer Private-Key
    Einige Zertifizierungsstellen erwarten von ihnen gar keinen Public Key sondern senden ihnen gleich einen kompletten Satz aus privatem Schlüssel, öffentlichem Schlüssel und Signatur.

SSL und Sicherheit

Eine Verbindung, welche per SSL verschlüsselt ist, sollte eigentlich sicher sein. Auch wenn das in den meisten Fällen so ist, ist es dennoch denkbar, dass die Daten von anderer Stelle mitgelesen werden. Natürlich sendet ihr WebServer mit seinem Zertifikat auch seinen öffentlichen Schlüssel mit und der private hat im Idealfall nie ihr System verlassen. Aber als Betreiber können Sie nicht sicherstellen, dass die Gegenstelle auch "ihr" Zertifikat erhält. Hier ein fiktives Beispiel eines "Man in the Middle" Zugangs.

Eine uS-Ermittlungsbehörde (z.B. FBI) zu einer amerikanischen CA (z.B:Verisign) geht und sagt „ gebt uns ein Zertifikat für „owa.netatwork.de“, und sie dann noch per DNS-Manipulationen die Clients auf deren Server leiten und das „falsche“ aber dennoch öffentliche gültige Zertifikat verwende, bekommt der Client keinerlei Warnung. Die Daten können Sie dann entschlüsseln und sogar an den „richtigen“ Service weiter leiten und quasi „mithören“  (sogar Kennworte, da Formulardaten oder Basic Authentication)

In der Hinsicht ist eine „Private CA“ in Verbindung mit eigenen Clients aber auch kein Vorteil. Zwar kann die Firma ihre Zertifikate selbst erstellen unddas Stammzertifikat auf den verwalteten Systemen installieren. Aber auch dann kann natürlich der Client nicht erkennen, wenn ein Angriff mit einem „öffentlichen“ Zertifikat gefahren wird.

Übrigens ist das auch bei Firmen „intern“ durchaus üblich. ProxySysteme wie WebWasher können SSL Anfragen derart abfangen, dass sie „on the fly“ ein Zertifikat für die angesurfte Adresse erstellen und dem Client geben. Die ausstellende CA ist dann die Firmen-CA, die per GPO auf allen Clients als „Trusted“ addiert ist. Damit erkennt der Client auch nicht, dass er seine Daten mit der falschen Gegenstelle verschlüsselt.
Das fällt nur auf, wenn ich als externer Consultant mit einem PC, der natürlich nicht der CA vertraut, die diese Zertifikate ausstellt. Ich bekomme dann wieder die Zertifikatwarnung.

Für SMIME oder TLS kann man sich derart behelfen, dass man auf NoSpamProxy Encryption das Zertifikat vorschreibt, welches auf der Gegenseite erwartet wird. Bei dieser Kommunikation fällt ein „Fremdzertifikat“ auf, da es zwar den gleichen Name, gültigen Aussteller und gültiges Datum hat, aber eben doch einen anderen Fingerprint.

Weitere Links