Die Geschichte der Protokolle SSL und TLS erstreckt sich über mehrere Dekaden und ist von ständigen Aktualisierungen geprägt. Diese zeichnen einen fortlaufenden Wettlauf mit immer raffinierteren Cyberkriminellen nach.
Secure Sockets Layer - Definition
SSL (Secure Sockets Layer) und sein Nachfolger TLS (Transport Layer Security) sind Protokolle zur Verschlüsselung des Internetverkehrs, die eine sichere Internetkommunikation und elektronischen Handel ermöglichen. SSL war der ursprüngliche Name des Protokolls, als es Mitte der 1990er Jahre von Netscape entwickelt wurde (dem Unternehmen, das den damals beliebtesten Webbrowser herstellte).
SSL 1.0 wurde nie für die Öffentlichkeit freigegeben,
SSL 2.0 wies gravierende Mängel auf, und
SSL 3.0, veröffentlicht im Jahr 1996, wurde vollständig überarbeitet und bildete die Grundlage für alles, was danach kam.
SSL "vs." TLS
Als 1999 die nächste Version des SSL-Protokolls veröffentlicht wurde, wurde es von der Internet Engineering Task Force (IETF) standardisiert und erhielt einen neuen Namen: Transport Layer Security (TLS). In der offiziellen TLS-Spezifikation heißt es: "Die Unterschiede zwischen diesem Protokoll und SSL 3.0 sind nicht dramatisch". SSL und TLS stehen sich also nicht konträr gegenüber - vielmehr bilden beide gemeinsam eine ständig aktualisierte Reihe von Protokollen, die auch oft unter dem Begriff "SSL/TLS" zusammengefasst wird.
Das TLS-Protokoll verschlüsselt jede Art von Internetverkehr. Dass Ihr Browser über TLS mit dem Netz verbunden ist, erkennen Sie daran, dass die URL mit "https" beginnt und die Adressleiste ein Vorhängeschloss anzeigt. Darüber hinaus kann TLS auch für andere Anwendungen zum Einsatz kommen, beispielsweise E-Mail oder Usenet.
SSL-Verschlüsselung - so funktioniert's
Um sicher über das Internet kommunizieren zu können, ist Verschlüsselung essenziell: Fehlt sie, können Datenpakete - und potenziell vertrauliche Informationen - von jedermann eingesehen werden.
Die sicherste Methode, Daten zu verschlüsseln, ist die so genannte asymmetrische Kryptografie. Diese erfordert zwei kryptografische Schlüssel - einen Public und einen Private Key. Im Wesentlichen dient erstgenannter dazu, die Daten zu verschlüsseln. Der Private Key ist hingegen nötig, um die Informationen wieder entschlüsseln zu können. Die beiden Schlüssel sind durch eine komplexe mathematische Formel miteinander verbunden, die sich nur schwer mit Brute-Force-Methoden knacken lässt. Stellen Sie sich den Public Key als Information über den Standort eines gesicherten Briefkastens mit Einwurfschlitz vor und den Private Key als dessen Zugangsschlüssel: Jeder, der den Standort kennt, kann Nachrichten einwerfen - um diese zu lesen, wird Zugang benötigt.
Wegen der komplexen Mathematik dahinter ist die asymmetrische Kryptografie sehr ressourcenhungrig. Würde Sie jede einzelne Information innerhalb einer Kommunikationssitzung verschlüsseln, würden Rechner und Verbindung zum Stillstand kommen. SSL/TLS umgeht dieses Problem, indem es nur zu Beginn einer Kommunikationssitzung asymmetrische Kryptografie anwendet, um die Konversation zu verschlüsseln. Dazu müssen sich Server und Client auf einen einzigartigen Sitzungsschlüssel einigen, den beide für die Verschlüsselung ihrer Datenpakete verwenden.
Der Prozess, bei dem dieser Sitzungsschlüssel vereinbart wird, wird als Handshake bezeichnet: Es ist quasi der Moment, in dem sich die beiden kommunizierenden Rechner einander vorstellen - und das Herzstück von SSL/TLS.
SSL/TLS Handshake - Verfahren
Der Handshake-Prozess ist komplex und das Protokoll lässt eine Reihe von Variationen zu. Die folgenden Schritte sollen Ihnen ein grundlegendes Verständnis der Abläufe vermitteln.
Der Client kontaktiert den Server und fragt eine sichere Verbindung an. Der Server antwortet mit einer Liste von "Cipher Suites" - quasi Algorithmen, die verschlüsselte Verbindungen herstellen. Der Client vergleicht diese Liste mit seiner eigenen, wählt eine Cipher Suite aus und teilt dem Server mit, dass diese von beiden Seiten verwenden wird.
Der Server stellt dann sein digitales Zertifikat zur Verfügung, ein elektronisches Dokument, das von einem vertrauenswürdigen Dritten ausgestellt wird und die Identität des Servers bestätigt. Wichtig zu wissen ist dabei, dass die digitalen Zertifikate die kryptografischen Public Keys des Servers enthalten. Sobald der Client das Zertifikat erhält, bestätigt er dessen Echtheit.
Mit Hilfe des serverseitigen Public Key erstellen Client und Server einen Sitzungsschlüssel, neudeutsch Session Key. Dieser wird von beiden Seiten verwendet, um die Kommunikation innerhalb der Session zu verrschlüsseln. Hierfür gibt es verschiedene Techniken - eine ist der sogenannte Diffie-Hellman-Schlüsselaustausch.
Wie der Name schon sagt, ist der Session Key nur für eine einzige, ununterbrochene Kommunikationssitzung gültig. Wird die Kommunikation zwischen Client und Server aus irgendeinem Grund unterbrochen (zum Beispiel aufgrund eines Netzwerkproblems oder weil der Client zu lange inaktiv ist) ist ein neuer Handshake erforderlich. Weitere Einzelheiten zum Thema SSL/TLS Handshake finden Sie zum Beispiel auf SSL.com.
SSL-Zertifikate erstellen und prüfen
Ein SSL-Zertifikat ist ein elektronisches Dokument, das die Identität eines Servers bestätigt und verschlüsselte Kommunikation ermöglicht. Wie eben gelesen, ist das SSL-Zertifikat das Herzstück des SSL/TLS-Protokolls: Es liefert dem Client den öffentlichen kryptografischen Schlüssel, der zum Aufbau einer sicheren Verbindung erforderlich ist. Allerdings geht der Zweck von SSL/TLS-Zertifikaten darüber hinaus: Sie stellen auch sicher, dass der Key tatsächlich mit der Organisation verbunden ist, die ihn dem Client anbietet.
SSL/TLS-Zertifikate werden von Zertifizierungsstellen (sogenannte Certificate Authorities oder CAs) ausgestellt, die ein Äquivalent zu einer Passbehörde bildet - nur für digitale Identitäten. Organisationen, die mit TLS verschlüsselte Dienste anbieten wollen, müssen Zertifikate von CAs erwerben, die wiederum überprüfen, ob alles mit rechten Dingen zugeht. Wollen Sie beispielsweise ein Zertifikat für die Website "example.com" erwerben, müssen Sie bei der Zertifizierungsstelle nachweisen, dass Sie diese Domäne kontrollieren. Verbindet sich jemand mit "example.com" und erhält ein gültiges, von einer vertrauenswürdigen Zertifizierungsstelle signiertes SSL-Zertifikat, ist sichergestellt, dass die Kommunikation rechtmäßig abläuft. Zudem können SSL/TLS-Zertifikate Man-in-the-Middle-Angriffe verhindern.
Eventuell sind Sie im gerade gelesenen Abschnitt über den Ausdruck "vertrauenswürdige Zertifizierungsstelle" gestolpert. Denn in der Theorie kann sich Jedermann selbst zur Zertifizierungsstelle erklären. Glücklicherweise springen die Softwarehersteller an dieser Stelle ein: Die Mozilla Foundation führt beispielsweise eine Liste von Zertifizierungsstellen, denen Firefox vertraut - und auch Apple und Microsoft führen solche Listen. Bei der Entscheidung darüber, welchen Zertifizierungsstellen man vertraut, steht viel auf dem Spiel. Das zeigte etwa eine Auseinandersetzung zwischen Google und dem Sicherheitsanbieter Symantec im Jahr 2017. Der Stein des Anstoßes: Die nach Auffassung von Google zu laxen Standards von Symantec.
SSL-Zertifikate werden vom Standard X.509 definiert. Dieser ermöglicht es, Zertifikate mit Informationen anzureichern, die über Public Key und Identitätsbestätigung des Zertifikatsinhabers hinausgehen.
SSL Checker - online und kostenlos
Der eben beschriebene Austausch und die Bestätigung von Informationen läuft im Hintergrund ab, wenn Sie mit Servern kommunizieren, die TLS-verschlüsselte Verbindungen anbieten. Wenn Sie diesbezüglich mehr Transparenz wünschen, können Sie die URL einer SSL/TLS-verschlüsselten Website mit Hilfe einer SSL-Checker-Webseite analysieren. Diese liefern eine Vielzahl von Informationen über das Zertifikat der betreffenden Seite, etwa den Servertyp oder welche Webbrowser dem Zertifikat vertrauen beziehungsweise nicht vertrauen.
Die meisten SSL Checker sind kostenlose Dienste, die von den Zertifizierungsstellen als Marketinginstrumente angeboten werden. Eine etwas weniger kommerzielle Alternative bietet der SSL Checker von Qualys SSL Labs, der eine besonders zuverlässige Sammlung von Informationen über geprüfte Websites bietet.
TLS - Sicherheitslücken
TLS 1.2
Die TLS-Version 1.2 ist schon seit mehreren Jahren aktuell. Mit ihr wurden zahlreiche neue, kryptografische Optionen für die Kommunikation eingeführt. Wie einige frühere Versionen des Protokolls erlaubt jedoch auch TLS 1.2, ältere kryptografische Techniken einzusetzen, um auch betagtere Rechner zu unterstützen. Das hat allerdings auch dazu geführt, dass das Protokoll immer anfälliger für Schwachstellen wurde.
Insbesondere Man-in-the-Middle-Angriffe wurden mit TLS 1.2 zum Problem. Auch die Angriffstechniken POODLE, SLOTH und DROWN sind im Rahmen von TLS 1.2 relevant und verdeutlichen, dass das Protokoll dringend aktualisiert werden muss.
TLS 1.3
Version 1.3 des TLS-Protokolls befindet sich derzeit im Entwurfsstadium und verspricht viele Sicherheitlücken zu schließen, indem es den Support für ältere Kryptografieverfahren einstellt. Rückwärtskompatibilität besteht in dem Sinne, dass Verbindungen auf TLS 1.2 zurückgestuft werden, wenn ein Kommunikationspartner nicht in der Lage ist, TLS 1.3 zu verwenden. Wird jedoch beispielsweise im Rahmen eines Man-in-the-Middle-Angriffs versucht, einen Rückgriff auf TLS 1.2 zu erzwingen, um Pakete auszuspionieren, wird das erkannt und die Verbindung terminiert.
Es gibt immer noch Server, die auf älteren TLS-Versionen als 1.2 laufen - einige verwenden sogar noch das ursprüngliche SSL-Protokoll. Wenn Ihr Server in diese Kategorie fällt, sollten Sie jetzt umsteigen - am besten direkt auf den TLS-1.3-Entwurf.
TLS-Crimeware
Viele Cyberkriminelle nutzen TLS, um den Command-and-Control-Traffic zwischen ihren Servern und den mit Malware infizierten Rechnern ihrer Opfer zu verschlüsseln. Das führt zu einer Umkehrung der üblichen Verhältnisse und lässt die Opfer von Cyberkriminalität nach einer Möglichkeit suchen, den Datenverkehr zu entschlüsseln. Es gibt eine Reihe von Techniken, um mit dieser Art von Angriffen umzugehen - zum Beispiel die Verwendung von Netzwerk-Metadaten.
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.