Wie funktioniert die Verschlüsselung bei HTTPS mittels SSL/TLS?

In diesem Blogbeitrag wollen wir den Unterschied zwischen HTTP und HTTPS aufzeigen und erklären, wie über das Protokoll SSL/TLS der Zugriff zu einer Website verschlüsselt werden kann.

Definition der Abkürzungen HTTP, HTTPS, SSL und TLS

Für das Abrufen von Websites im Internet wird das textbasierte Protokoll HTTP verwendet. HTTP stellt dabei die englische Abkürzung für HyperText Transfer Protocol dar. Es handelt sich bei HTTP also um ein Protokoll zum Übertragen von sogenanntem Hypertext. Hypertext ist wiederum eine spezielle Textform, die Referenzen auf andere Texte enthält. Die verbreitetste Sprache zum Definieren eines solchen Hypertexts ist HTML (HyperText Markup Language).

Bei dem Protokoll HTTPS (HyperText Transport Protocol Secure) handelt es sich nun um eine Art Erweiterung des Protokolls HTTP. Dabei wird der Datenverkehr des HTTP-Protokolls vor der Weitergabe an das unterliegende Protokoll TCP über das Protokoll SSL bzw. TLS verschlüsselt.

Die Protokolle SSL (Secure Sockets Layer) und TLS (Transport Layer Security) sind Verschlüsselungsprotokolle, um den Datenverkehr eines bestimmten Protokolls (z. B. HTTP oder SMTP) vor der Weitergabe zu verschlüsseln. Daraus entstehen dann im Regelfall neue Protokollbezeichnungen wie z. B. HTTPS oder SMTPS. Die aktuellste Version von SSL ist die Version 3.0 von 1996, welche jedoch seit 2015 als unzulässig gilt. Bereits im Jahr 1999 wurde TLS als Nachfolger von SSL vorgestellt, wovon die Unterschiede zwischen den beiden Protokollen sowie zwischen den Protokollversionen nur geringfügig sind. TLS 1.3 ist die aktuellste Version und wurde 2018 spezifiziert. Auch wenn die SSL-Versionen heute kaum bis gar mehr eingesetzt werden, werden die Begriffe SSL und TLS oft synonym verwendet.

Unterschied zwischen HTTP und HTTPS

Wie bereits oben bei den Begriffdefinitionen erwähnt, handelt es sich bei HTTPS um die mit SSL/TLS verschlüsselte Variante von HTTP. Bevor also der Webbrowser eine Anfrage an den Webserver sendet, wird die Anfrage mit SSL/TLS verschlüsselt. Der Webserver ist dann in der Lage, die Nachricht wieder zu entschlüsseln und intern als normale HTTP-Anfrage zu bearbeiten. Anschließend generiert der Webserver die Antwort, verschlüsselt diese und schickt diese zurück an den Webbrowser. Der Webbrowser kann die Antwort vom Server dann wiederum entschlüsseln.

Sowohl der Client (i. d. R. der Browser) als auch der Server müssen in der Lage sein, zwischen HTTP und HTTPS unterscheiden zu können. Auf der Clientseite wird die Unterscheidung durch die URL erzielt. Möchte man eine Website per HTTP abrufen, so lautet die URL z. B. http://www.homepage-webhilfe.de/. Für das Abrufen der gleichen Website per HTTPS lautet die URL https://www.homepage-webhilfe.de/. Die URL unterscheidet sich damit also im vorderen Teil, welche das sogenannte Schema angibt.

Bei der Angabe des Schemas http sendet der Webbrowser eine unverschlüsselte Anfrage an Port 80 des hinter dem DNS-Namen stehenden Webservers. Entspricht das in der URL angegebene Schema hingegen https, so wird über Port 443 eine verschlüsselte Verbindung aufgebaut und die Anfrage dann auch in verschlüsselter Form an den Webserver gesendet. Natürlich ist bei beiden Schemen auch die Angabe eines anderen Ports möglich. Letztendlich unterscheidet der Server aber im Regelfall mit Hilfe des Ports, ob es sich um eine HTTP- oder HTTPS-Anfrage handelt.

Übrigens: Auch wenn in der Zwischenzeit viele Websites nur noch über HTTPS erreichbar zu sein scheinen, wird oftmals HTTP noch weiterhin verwendet, um URLs mit dem Schema http auf das Schema https umleiten zu können.

Ablauf einer Verschlüsselung mittels SSL/TLS

Zunächst muss erwähnt werden, dass es zwei unterschiedliche Arten von Verschlüsselung gibt: symmetrische Verschlüsselung und asymmetrische Verschlüsselung. Bei der symmetrischen Verschlüsselung kann eine Nachricht mit dem gleichen Schlüssel verschlüsselt und entschlüsselt werden. Diese Verschlüsselungsart ist für den direkten Einsatz im Internet weniger nützlich, da sowohl Client als auch Server den Schlüssel zuvor kennen müssen. Würde der Schlüssel nun ebenfalls über das Internet übertragen werden, so könnte ein Angreifer diesen Schlüssel ebenfalls mitlesen und somit den Datenverkehr problemlos entschlüsseln. Dies würde dann zum Verlust aller Vorteile von einer Verschlüsselung führen.

Im Vergleich dazu gibt es bei der asymmetrischen Verschlüsselung einen privaten und einen öffentlichen Schlüssel. Eine Nachricht, die mit dem privaten Schlüssel verschlüsselt wurde, kann im Nachhinein nur noch mit dem privaten Schlüssel wieder entschlüsselt werden. Diese Art der Verschlüsselung könnte somit direkt eingesetzt werden, denn Client und Server hätten jeweils ein Schlüsselpaar, wovon der öffentliche Schlüssel der Gegenseite ohne Gefahren mitgeteilt werden könnte. Ein großer Nachteil der asymmetrischen Verschlüsselung ist jedoch, dass die Verschlüsselung deutlich zeitaufwendiger ist.

Das Protokoll SSL/TLS löst dieses Problem, indem zunächst mittels einer asymmetrischen Verschlüsselung ein Schlüsselaustausch stattfindet, bevor dann eine symmetrische Verschlüsselung für den eigentlichen Datenaustausch verwendet wird. Ein etwas detaillierter Ablauf lässt sich wie folgt beschreiben:

1. Der Client sendet dem Server die Nachricht Client Hello. Diese enthält neben einem Zufallswert auch die vom Client unterstützten Kombinationen aus Verschlüsselungs- und Hashing-Verfahren (Cipher Suites).
2. Der Server sendet daraufhin ein Server Hello zurück. Diese Nachricht enthält ebenfalls Zufallswerte sowie die vom Server ausgewählte Kombination aus Verschlüsselungs- und Hashing-Verfahren.
3. Anschließend sendet der Server noch zusätzlich sein Zertifikat inkl. des öffentlichen Schlüssels an den Client, sodass der Client den Server identifizieren kann.
4. Der Client kann nun das Zertifikat des Servers auf Gültigkeit prüfen und entscheiden, ob er dem Zertifikat vertraut oder nicht.
5. Anschließend generiert der Client aus Zufallswerten das Pre-Master-Secret und verschlüsselt diesen mit dem erhaltenen öffentlichen Schlüssel des Servers und schickt die asymmetrisch verschlüsselte Nachricht an den Server.
6. Der Server ist nun mit Hilfe seines geheimen privaten Schlüssels in der Lage, die vom Client erhaltene Nachricht zu entschlüsseln und somit das vom Client erzeugte Pre-Master-Secret zu kennen.
7. Als nächstes kann sowohl der Client als auch der Server aus den am Anfang ausgetauschten Zufallszahlen sowie dem Pre-Master-Secret das Master-Secret erzeugen. Dies ist ab nun der einmalig verwendete symmetrische Schlüssel, der für die Verschlüsselung der Verbindung genutzt wird.
8. Zum Abschluss sendet der Client an den Server noch eine Nachricht, um mit der verschlüsselten Kommunikation zu beginnen. Das Gleiche wiederholt dann auch noch der Server. Anschließend kann der verschlüsselte Datenaustauch erfolgen.

Wie bereits oben erwähnt, sendet der Server dem Client sein Zertifikat. Die Übertragung des Zertifikats vom Server dient nicht nur dazu, dem Client den öffentlichen Schlüssel mitzuteilen, sondern auch dazu, dem Client die Möglichkeit zu geben, den Server zu identifizieren. So kann der Client zum einen an Hand des Domainnamens prüfen, ob das Zertifikat auch wirklich für diesen Server ausgestellt wurde und entscheiden, ob er dem Zertifikat bzw. vielmehr der Zertifizierungsstelle, die das Zertifikat ausgestellt hat, vertraut.