Wenn Daten über das Internet zwischen einem Webserver und einem internetfähigen Gerät wie zum Beispiel einem Smartphone übertragen werden, sind diese standardmäßig unverschlüsselt. Für Angreifer*innen ist es dann leicht, diese Daten abzufangen oder Schadsoftware einzuschleusen. Damit das nicht passieren kann, senden und empfangen viele Webserver nur verschlüsselte Daten.

Webserver und Smartphone müssen dazu einen Schlüssel austauschen, mit dem die Daten verschlüsselt und dann wieder entschlüsselt werden können. Die Regeln und Vorgehensweisen dafür sind in sogenannten Protokollen festgeschrieben. TLS (Transport Layer Security) ist eines dieser Protokolle – und dasjenige, das standardmäßig für die Transportverschlüsselung von Daten genutzt wird.

Wo kommt TLS-Verschlüsselung zum Einsatz?

Üblicherweise tauchen TLS-Verbindungen beim Aufrufen von Internetseiten auf. Die Verschlüsselung wickelt dann ein Browser ab, zum Beispiel Chrome oder Firefox. Aber auch E-Mail-Verbindungen werden heute standardmäßig TLS-verschlüsselt.

Auf dem Smartphone bauen nicht nur Browser- und E-Mail-Apps TLS-Verbindungen auf. Auch für alle andere Apps gilt die Transportverschlüsselung mit TLS als Mindeststandard, um die Sicherheit der übertragenen Daten und der beteiligten Geräte zu gewährleisten.

Wie wird eine TLS-Verbindung hergestellt?

1. Authentifizierung des Webservers

Bevor Webserver und Smartphone sich auf einen gemeinsamen Schlüssel einigen, mit dem die verschlüsselte Verbindung aufgebaut wird, übermittelt der Webserver dem Smartphone einen Datensatz, der ihn als Inhaber der aufgerufenen Internetseite bestätigt. Dieser Datensatz ist das sogenannte TLS-Zertifikat (mehr dazu weiter unten).

Dieser Schritt soll verhindern, dass sich ein*e Angreifer*in als der Webserver ausgeben kann, zu dem jemand gerade eine verschlüsselte Verbindung aufbauen will. Auch Angreifer*innen, die sich zwischen Webserver und Smartphone schalten, um den Schlüsselaustausch abzufangen, sollen damit ausgesperrt werden.

2. Versand des gemeinsamen TLS-Schlüssels (asymmetrisch)

Mit den Informationen aus dem TLS-Zertifikat des Webservers erstellt das Smartphone nun den gemeinsamen (symmetrischen) Schlüssel, mit dem später der Datenverkehr mit dem Webserver verschlüsselt wird.

Im TLS-Zertifikat ist auch der öffentliche Schlüssel des Webservers enthalten. Mit diesem kann das Smartphone nun den symmetrischen Schlüssel asymmetrisch verschlüsselt an den Webserver schicken. Für die Entschlüsselung benötigt man den zugehörigen privaten Schlüssel, den nur der Webserver kennt.

3. Gesicherte TLS-Verbindung (symmetrisch)

Webserver und Smartphone sind jetzt im Besitz des symmetrischen Schlüssels, mit dem sie von nun an ihren gemeinsamen Datenverkehr verschlüsseln.

Was sind TLS-Zertifikate?

Wer zum Beispiel eine Website betreibt und dabei Daten TLS-verschlüsselt übertragen will, muss sich ein TLS-Zertifikat ausstellen lassen. Das bekommt man von einer Zertifizierungsstelle, auf englisch auch Certificate Authority, oder kurz CA genannt. Es gibt weltweit über tausend solcher Stellen.

Die Preise, die diese Stellen für ihre Zertifikate aufrufen, sind sehr unterschiedlich: von einigen wenigen, ganz kostenlosen Zertifikaten bis zu 2.500 Euro pro Domain bei den renommierten Zertifizierungsstellen ist auf dem Markt fast alles geboten.

Was macht die Zertifizierungsstelle?

Die Zertifizierungsstelle prüft, ob Kund*innen, die ein Zertifikat kaufen wollen, auch legitime Inhaber*innen der Internet-Adresse (Domain) sind, auf die das Zertifikat ausgestellt werden soll. Wie genau diese Prüfung abläuft, kann die Zertifizierungsstelle selbst entscheiden. Entsprechend unterschiedlich sind die Verfahren.

Dann stellt die Zertifizierungsstelle ein TLS-Zertifikat aus, in dem unter anderem Inhaber*in und Domain festgeschrieben sind, und unterschreibt es mit ihrem privaten Schlüssel. Das unterschriebene Zertifikat baut der*die Inhaber*in dann in seine Website ein.

Wer darf Zertifikate ausgeben?

In Deutschland werden die Zertifizierungsstellen von der Bundesnetzagentur überwacht und müssen sich dort melden, bevor sie den Betrieb aufnehmen.

In anderen Ländern ist das anders geregelt. Drei Viertel aller Zertifikate werden von nur drei renommierten Zertifizierungsstellen beglaubigt. Daneben gibt es sehr viele kleine Zertifizierungsstellen, die nach sehr unterschiedlichen Kriterien arbeiten.

Was ist die Vertrauenskette („Chain of Trust“)?

Jede Zertifizierungsstelle kann ihrerseits Unter-Zertifizierungsstellen ernennen. Die Vertrauenswürdigkeit dieser Unter-Stellen garantiert dann die jeweils darüberliegende Zertifizierungsstelle mit einem Zertifikat.

Der Webserver übergibt dem Smartphone beim Zertifikat-Austausch nicht nur sein Zertifikat, sondern auch die Zertifikate der darüberliegenden CAs bis zum Root-Zertifikat. Der Browser überprüft die Unterschrift des ersten Zertifikats mit dem öffentlichen Schlüssel auf dem darüberliegenden, bis zur obersten Zertifizierungsstelle.

Von dieser obersten Stelle sollte bei ihm ein Root-Zertifikat hinterlegt sein. Sonst wird der Browser das Zertifikat ablehnen.

Was sind Root-Zertifikate?

Normalerweise enthält ein Zertifikat den öffentlichen Schlüssel des Inhabers, und ist mit dem privaten Schlüssel der Zertifizierungsstelle unterschrieben. Root-Zertifikate stehen am Ende der Vertrauenskette, und sind "self-signed", also selbst unterschrieben.

Sie enthalten einen öffentlichen Schlüssel, der mit dem dazugehörigen privaten Schlüssel unterschrieben ist. Das Vertrauen in Root-Zertifikate muss daher auf einem anderen Weg hergestellt werden.

Woher hat mein Browser oder meine App die Root-Zertifikate?

Die Hersteller des Browsers geben dem Browser eine Liste mit Zertifizierungsstellen (CAs) mit, die sie für vertrauenswürdig halten. Die großen Browser vertrauen standardmäßig meist mehr als hundert verschiedenen CAs. Von jeder dieser CAs besitzt der Browser standardmäßig ein Root-Zertifikat.

Der Browser kann nun die Unterschrift auf dem TLS-Zertifikat mit dem öffentlichen Schlüssel vom zugehörigen Root-Zertifikat validieren. Das heißt, er entschlüsselt die Unterschrift, und sieht, ob das Ergebnis mit dem Inhalt des lesbaren Zertifikates übereinstimmt. Nutzer können auch manuell Root-Zertifikate von Zertifizierungsstellen installieren, wenn sie wollen, dass der Browser deren Zertifikate akzeptiert.

Was ist Certificate Pinning?

In manchen Apps ist festgelegt, von welcher Zertifizierungsstelle ein Zertifikat abstammen muss, damit es als gültig akzeptiert wird. Damit können die geschilderten Probleme mit gefälschten Zertifikaten vermieden werden. Dieses Vorgehen nennt man Certificate Pinning (deutsch etwa: „Zertifikate festnageln“).

Wie funktioniert Certificate Pinning?

Aus dem öffentlichen Schlüssel der betreffenden Zertifizierungsstelle wird eine Prüfziffer (der PIN) berechnet und von dem*der Entwickler*in in der App hinterlegt.

Verbindet sich die App später über TLS mit dem Server, kann sie prüfen, ob sich die gewünschte Zertifizierungsstelle in der Vertrauenskette befindet, und sonst die Verbindung ablehnen. Es ist auch möglich, direkt den öffentlichen Schlüssel des Kommunikationspartners zu pinnen.

Können auch Browser Certificate Pinning?

Ja, auch Webbrowser können Certificate Pinning betreiben. Dort wird vorausgesetzt, dass die erste Verbindung vertrauenswürdig ist.

Aus dem Zertifikat, welches beim ersten Kontakt übertragen wird, berechnet das Endgerät dann eine Prüfziffer und legt sie im Browser dauerhaft ab. So kann sich bei späteren Kontakten niemand dazwischen mogeln.

Weitere Fragen zu TLS

Was steht in einem TLS-Zertifikat?

Um die Funktion des Zertifikats zu verstehen, sind vier Bestandteile aus dem TLS-Zertifikat wichtig:

• Gültigkeitszeitraum. Es ist definiert, bis wann das Zertifikat gültig ist.
• Internet-Adresse (Domain), auf die das Zertifikat ausgestellt ist. Das Smartphone gleicht die Adresse auf dem Zertifikat mit der Adresse ab, die es gerade aufruft, und kann damit sicher sein, dass es mit dem richtigen Webserver verbunden ist.
• Der öffentliche Schlüssel des*der Zertifikat-Inhaber*in. Das ist der*die Besitzer*in der Internet-Adresse, auf die das Zertifikat ausgestellt ist.
• Die digitale Unterschrift der Zertifizierungsstelle. Eine solche Unterschrift macht das unterschriebene Zertifikat theoretisch fälschungssicher.

Was sind öffentliche und private Schlüssel?

Sie gehören zur asymmetrischen Verschlüsselung. Dabei wird zunächst ein Schlüsselpaar erzeugt. Die Schlüssel sind so gewählt, dass eine Zeichenfolge, zum Beispiel ein Passwort, nur mit dem ersten Schlüssel verschlüsselt werden kann, und nur mit dem zweiten Schlüssel wieder entschlüsselt werden kann.

Der erste Schlüssel ist daher der öffentliche Schlüssel. Er muss nicht geheim gehalten werden. Der zweite Schlüssel ist der private, oder auch geheime Schlüssel. Nun kann jede*r Fremde eine Nachricht mit dem öffentlichen Schlüssel verschlüsseln.

Aber nur der*die Besitzer*in des dazugehörigen privaten Schlüssels kann sie auch wieder entschlüsseln. Auf dieser Tatsache beruht die Sicherung von TLS-Zertifikaten und auch Teile der verschlüsselten Kommunikation.

Warum ist oft von TLS/SSL die Rede?

SSL war der Vorläufer von TLS. Die älteste Version von SSL, auch SSLv3 (v3 steht für Version 3) genannt, war der ersten Version von TLS sehr ähnlich. Deshalb werden SSLv3 und TLS manchmal synonym verwendet.

Was hat TLS mit https zu tun?

Die meisten Adressen von Webseiten im Internet beginnen mit "http". Wenn die Adresszeile mit "https" beginnt, wird für die Kommunikation zwischen dem Webserver, auf dem die Webseite liegt, und dem Gerät des Nutzers TLS-Verschlüsselung eingesetzt. Das S in "https" steht für Security (Sicherheit).

Was nützt die Unterschrift der Zertifizierungsstelle?

Wenn Angreifer*innen das Zertifikat unterwegs manipulieren würde, wäre die Unterschrift von der Zertifizierungsstelle nicht mehr gültig. Warum? In der Kryptographie bedeutet Unterschreiben (vereinfacht) folgendes: Die Daten in dem Zertifikat werden diesmal mit dem privaten Schlüssel der Zertifizierungsstelle verschlüsselt, also umgekehrt wie bei der Verschlüsselung.

Unter dem lesbaren Zertifikat befindet sich also der Inhalt des Zertifikats nochmal, nur in verschlüsselter Form. Diese verschlüsselten Zeichen lassen sich nur mit dem zugehörigen öffentlichen Schlüssel wieder entschlüsseln.

Angreifer*innen könnten zwar den lesbaren Inhalt des Zertifikates ändern. Doch bei der Entschlüsselung der Unterschrift mit dem öffentlichen Schlüssel der Zertifizierungsstelle wird die Information, die der Empfänger daraus erhält, nicht mit dem (manipulierten) Inhalt des Zertifikates übereinstimmen.

In der Folge würde der Empfänger – beispielsweise der Webbrowser – den Betrug bemerken und eine Warnmeldung ausgeben. Wie es in der Vergangenheit trotzdem immer wieder zu gefälschten Zertifikaten kam, erklären wir weiter unten.

Kann ich das TLS-Zertifikat von einem Webserver sehen?

Es gibt verschiedene Möglichkeiten, das Zertifikat sichtbar zu machen. Bei https-Verbindungen kann im Webbrowser wie Firefox oder Chrome durch einen Klick auf das grüne kleine Schloss in der Adresszeile das Zertifikat eingesehen werden. Es gibt auch Prüfseiten im Internet, zum Beispiel von der IT-Sicherheitsfirma Symantec. Dort kann man einfach die gewünschte Adresse eingeben.

Schwieriger wird es bei TLS-Verbindungen, die von Apps auf Smartphone oder Tablet aufgebaut werden. Normalerweise bekommen die Nutzer*innen von diesen Verbindungen nichts mit, denn es öffnet sich kein Browserfenster oder ähnliches. Das TLS-Zertifikat lässt sich nicht einsehen – man ist hier auf die Sorgfalt der App-Anbieter angewiesen.

Wieso kam es immer wieder zu gefälschten Zertifikaten?

In den letzten Jahren gab es immer wieder Fälle von gefälschten Zertifikaten, wodurch das Zertifizierungssystem in die Kritik geriet. Es fanden zum Beispiel Einbrüche in renommierte Zertifizierungsstellen statt, bei denen über einen längeren Zeitraum unbemerkt der private Schlüssel der Zertifizierungsstelle kopiert wurde und damit Fälschungen unkompliziert möglich waren.

Andere Sicherheitsschwächen sind die Zertifizierungsstellen selbst: Es gibt unseriöse Anbieter, denen entweder grobe Fahrlässigkeit in der Sicherheit oder willentliche Zusammenarbeit mit Geheimdiensten oder anderen unautorisierten Akteuren nachgewiesen werden konnte.

So wurden 2015 massenhaft Zertifikate entdeckt, deren Inhaber angeblich Google war. Sie wurden von der chinesischen Zertifizierungsstelle CNNIC ausgestellt. Formal waren diese Zertifikat gültig, das heißt, die Unterschrift der Zertifizierungsstelle passte zum Zertifikat. Daher wurde es von vielen Browsern akzeptiert.

Doch die Internetadressen auf den Zertifikaten gehörten gar nicht Google. Jemand versuchte, sich als vertrauenswürdiger Google-Server auszugeben. Um dem entgegen zu wirken, wird das aktuelle Zertifizierungssystem derzeit reformiert.