SSL-Zertifikate | Verschlüsselte Kommunikation im Internet

Die Umstellung von HTTP auf eine verschlüsselte Verbindung mit HTTPS ist ein wichtiges Thema für Seitenbetreiber und wird zum Beispiel durch Let’s Encrypt stark vereinfacht. Auf der ersten Seite bei einer Google-Suche sollen die Ergebnisse zu mehr als 50% eine HTTPS-Verschlüsselung aufweisen und Browser wie Google Chrome oder Firefox warnen inzwischen vor ungesicherten Verbindungen. In diesem Artikel möchte ich aufzeigen, wie diese Verschlüsselung funktioniert und wie der Client mit dem Server kommuniziert.

Grundlegendes zum Public-Key-Verschlüsselungsverfahren

Ein wichtiger Teil des SSL-Verfahrens ist die Verschlüsselung mit einem Public und einem Private Key. Wie schon die Namen sagen, ist der Public Key öffentlich und diesen darf auch jeder kennen, den Private Key muss man hingegen schützen und darf diesen nicht preisgeben. Wenn man eine Nachricht verschicken möchte, benutzt dieser den öffentlichen Schlüssel des Empfängers, um die Nachricht zu verschlüsseln. Eine Entschlüsselung dieser Nachricht ist jetzt nur noch mit dem Private Key des Empfängers möglich.

Public-Private-Key-Verfahren

Ermittlung der IP-Adresse

Der erste Schritt, der vom Browser getätigt werden muss, wenn man eine URL eingegeben hat (z.B. google.de), ist, herauszufinden, welcher Web-Server angesprochen werden muss. Dazu muss die zu der Web-Adresse zugeordnete IP-Adresse bestimmt werden. Eine lokale Speicherung dieser Zuordnung für alle Internet-Seiten würde viel zu viel Speicherplatz kosten und es müsste eine ständige Aktualisierung geben.

Deswegen gibt es für diese Namensauflösung DNS-Server (Domain Name System). Die IP-Adresse des Servers, den man nutzen möchte, muss dazu im Router eingetragen werden, beispielhaft zu erwähnen wäre der DNS-Server von Google mit der IP 8.8.8.8. Der Client stellt diesem eine Anfrage mit der eingebenen Internet-Adresse und erhält als Antwort die dazu passende IP-Adresse.

Unverschlüsselte Kommunikation zwischen Client und Server

Der Verbindungsaufbau zwischen dem Client und dem Server findet noch unverschlüsselt statt. Der Client versucht sich zu verbinden und startet einen Request an die Server-IP-Adresse.

Der Server antwortet darauf und gibt verschiedene Informationen an den Client. Darunter fallen zum Beispiel, das Protokoll, das benutzt werden soll sowie die Session ID, die der Web-Server festlegt. Zusätzlich versendet der Server seinen Public Key. Diese Kommunikation findet bisher noch unverschlüsselt statt.

Der Public Key des Servers wurde jedoch vorher noch von einer sogenannten Certification Authority signiert.

Was ist eine Certification Authority?

Der Browser muss in der Lage sein zu prüfen, ob der übermittelte Public Key vertrauenswürdig ist und zu der angeforderten Domain passt. Es könnte sein, dass ein Angreifer dem Browser einen fehlerhaften Schlüssel liefert und so eine Kommunikation mit dem Web-Server nicht möglich ist, sondern nur der Angreifer die verschlüsselte Kommunikation entschlüsseln kann.

Dafür gibt es sogenannte Certification Authoritys, auf deutsch Zertifizierungsstellen. Beispiele für CAs sind unter anderem Comodo, Symantec oder GoDaddy. Die Zertifikate der Zertifizierungsstellen sind im Browser gespeichert und werden vorgeladen. Hier ist die einzige Schwachstelle, da diesen Zertifikate ohne weitere Überprüfungsmöglichkeit vertraut werden muss. Ein solches Zertifikat besteht aus dem öffentlichen Schlüssel der CA und einer digitalen Signatur mit dem privaten Schlüssel der CA. Das bedeutet, dass aus der eigentlichen Information, also dem Public Key, ein Hash-Wert ermittelt wurde. Dieser Hash wurde dann mit dem Private Key der CA verschlüsselt.

Weiter oben wurde schon gesagt, dass der übermittelte Public Key des Servers von einer Zertifizierungsstelle signiert wurde. Dazu sendet der Webserver seinen öffentlichen Schlüssel mit der Anforderung zur Ausstellung des Zertifikates an die CA und erhält als Antowort das Zertifikat bestehend aus dem öffentlichen Schlüssel, der mit dem privaten Schlüssel der CA signiert ist. Auch hier bedeutet die Signatur wieder, dass der Hash, der sich aus dem Public Key des Servers ergibt, mit dem privaten CA-Schlüssel codiert und dann angehängt wurde.

Überprüfung des Webserver-Zertifikates

Das Zertifikat ist im Browser wie schon erwähnt automatisch vorhanden. Es ist möglich, den öffentlichen Schlüssel der CA aus der Zertifikat vom verschlüsselten Hash zu trennen, sodass der Public Key der CA vorhanden ist.

Mithilfe dieses Schlüssels lässt sich das Webser-Zertifikat nun folgendermaßen auf Echtheit überprüfen:

  1. Der Browser nimmt aus dem Webserver-Zertifikat den Hash, der mit dem privaten Schlüssel der CA verschlüsselt ist und entschlüsselt diesen mit dem vorhandenen öffentlichen Schlüssel der CA.
  2. Als nächstes berechnet der Browser über das selbe Verfahren, das auch die CA bei der Ausstellung benutzt hat, den Hash-Wert, der sich aus dem öffentlichen Schlüssel des Web-Servers ergibt.
  3. Diese beiden Hashes werden darauf untersucht, ob sie identisch sind. Zusätzlich liest der Browser noch aus dem Webserver-Zertifikat Informationen aus. Dabei wird untersucht, ob das Zertifikat für die Domain ausgestellt wurde, die abgerufen wurde.

Verschlüsselte Kommunikation zwischen Client und Server

Der Client weiß nun, dass der empfangene Public Key vom Server valide ist und könnte nun alle zu versendenden Nachrichten mit diesem verschlüsseln und der Server könnte den Text dann mit seinem Private Key entschlüsseln. Das Problem hierbei ist jedoch, dass eine asymmetrische Verschlüsselung deutlich länger dauert als ein symmetrisches Verfahren. Um trotzdem die höhere Sicherheit des Public-Key-Verschlüsselungsverfahrens zu nutzen, wird folgende Technik benutzt.

Der Client generiert einen zufälligen Schlüssel. Dieser wird mit dem Public Key des Servers codiert und man erhält den verschlüsselten Schlüssel, welcher dann an den Server geschickt wird. Dort findet mit dem Server-Private Key eine Entschlüsselung statt, sodass sowohl der Client als auch der Server über den decodierten, generierten Schlüssel verfügen. Nun ist es möglich, die Nachrichten mithilfe dieses Keys symmetrisch verschlüsselt zu übertragen, ohne dass die Verbindung abgehorcht werden kann, da nur Sender und Empfänger den symmetrischen Schlüssel kennen können.

Würden die vorherigen Schritte fehlen, würde der Schlüssel für die symmetrische Verschlüsselung decodiert an den Server übertragen werden. Auf diesem Weg könnte er von einem Angreifer abgefangen werden. Zwar kann ein solcher Angriff auch auf den verschlüsselten Key stattfinden, ohne den Private Key des Server könnte jedoch die Kommunikation zwischen Client und Server trotzdem nicht abgehört werden.

Abschließend ist hier noch einmal eine übersichtliche Grafik zu finden, die den kompletten Vorgang nach der Ermittlung der IP-Adresse übersichtlich darstellt und zusammenfasst.

Schreiben Sie einen Kommentar

Ihre E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.