SSL: Wie sicher ist das Verschlüsselungsprotokoll noch?

Einer Studie des Münchner Sicherheitsunternehmens SecureNet zufolge sind 99 Prozent aller SSL-basierten Verschlüsselungen nicht sicher. Für ihre Untersuchung analysierten die Spezialisten rund eine Millionen Webseiten, bei denen vertrauliche Informationen durch das Netz transportiert werden. Darunter waren Online-Banking-Portale ebenso wie Webmail-Accounts. Das Kuriose dabei ist, dass die Studie bereits im November 2012 veröffentlicht wurde – also zehn Monate bevor Edward Snowden enthüllte, dass die NSA in der Lage sei, die SSL-Verschlüsselungstechnik zu knacken.

Zentrale Zertifikate

Das SSL-Protokoll (Secure Sockets Layer), das der Browser-Hersteller Netscape erstmals 1994 veröffentlichte und das seit Version 3.0 unter dem Namen TLS (Transport Layer Security) firmiert, stellt einen abhör- und mitlesesicheren Transportweg für die Datenübertragung durch das Netz bereit. Hierfür nutzt es ein Schlüsselpaar, bestehend aus einer öffentlichen und einer privaten Komponente (Public Key und Private Key). Darüber hinaus gibt es ein zentrales Element, das für eine vertrauenswürdige SSL-Verbindung sorgen soll: Das digitale Zertifikat. Dieses dient der Identifikation seines Inhabers – etwa des Webserverbetreibers eines Bankingportals.

Daher kann das digitale Dokument als eine Art virtueller Personalausweis aufgefasst werden, der als eindeutiges Identifizierungsmerkmal einen dem jeweiligen Server zugeordneten öffentlichen Verifikationsschlüssel enthält, der mittels eines weiteren, geheimen Schlüssels digital signiert und somit beglaubigt wird. Die virtuelle Unterschrift stammt dabei von einer autorisierten Zertifizierungsstelle (CA = Certificate Authority) – einer Organisation, die digitale Zertifikate vergibt und überprüft. In Deutschland zählt etwa die Deutsche Telekom zu den Zertifizierungsinstanzen, auf internationaler Ebene gehört Verisign zu den bekanntesten Herausgebern von SSL-Zertifikaten.

Der SSL-Verbindungsaufbau

Der Nutzer initiiert die SSL-Verbindung, indem er etwa die HTTPS-Webadresse seines Kreditinstituts in den Browser eingibt. In seiner Funktion als Client baut dieser dann den Kontakt zum Banken-Server auf. Daraufhin authentifiziert sich der Server gegenüber dem Client, indem er ihm sein Zertifikat mit dazugehörigem öffentlichen Schlüssel schickt. Da der Browser über eine Liste vertrauenswürdiger CA-Zertifikate verfügt, kann er den Webserver-Datensatz mit seinem Zertifikatsspeicher abgleichen und die Signatur auf Echtheit überprüfen. Der Client weiß dadurch, dass er auch tatsächlich mit der gewünschten Gegenseite und nicht etwa mit einer dubiosen Zwischenstelle kommuniziert.

Stimmen die jeweiligen öffentlichen Schlüssel überein, erzeugt ein Zufallsgenerator, der Teil der Verschlüsselungsbibliothek eines Betriebssystems ist (in Windows beispielsweise die Cryptography-API), eine geheime Zufallszahl. Sie chiffriert der Client mit dem Public Key des Webservers, generiert daraus einen Sitzungsschlüssel, der einmalig nur für die jeweilige SSL-Verbindung gültig ist, und leitet ihn an den Server weiter. Dieser dekodiert den Sitzungsschlüssel mit Hilfe seines privaten Keys.

Jener geheime Teil des Schlüsselpaares verbleibt immer auf dem Server und darf nie herausgegeben werden. Da der Sitzungskey nun sowohl Client als auch Server bekannt ist, können beide Parteien fortan ihre Daten symmetrisch mit diesem verschlüsseln und über einen gesicherten SSL-Tunnel verschicken.

Sicherheitsrisiken der SSL-Verschlüsselung

Doch an welchen Stellen im SSL-Verbindungsaufbau befinden sich nun potenzielle Sicherheitslecks, die sich Geheimdienste zunutze machen könnten? Laut den Steganos-Experten können diese bereits vor dem Beginn des eigentlichen Verschlüsselungsprozesses ansetzen – das heißt, die Daten werden abgefangen, bevor sie überhaupt chiffriert werden. So sei die beste Verschlüsselung nichts wert, wenn die NSA mittels eines Trojaners den PC kompromittiert und dessen Daten mitschneidet.

Steganos zufolge könne die NSA auch die Hersteller von Sicherheitssoftware durch Geldzahlungen dazu veranlassen, zu Spionagezwecken absichtlich Schwachstellen und Hintertüren in ihre Programme einzubauen. Davon abgesehen verschlüssele das SSL-Protokoll nur den Transportweg der Daten, nicht aber deren Ziel. Die Folge davon sei, dass etwa der Internetprovider auf der anderen Seite sowieso mitlesen könne.

Ein weiteres Sicherheitsproblem liegt auch auf der ersten Meile einer Datenkommunikation zwischen Client und Server. Da die Initialisierung einer solchen Verbindung in der Regel noch unverschlüsselt abläuft, kann ein Angreifer – der sogenannte Man in the Middle noch vor dem beiderseitigen Austausch des Sitzungsschlüssels mittels Sniffing Paketdaten mitschneiden und die jeweilige Sitzung kapern, indem er beispielsweise – wie in der erwähnten Studie beschrieben – den vom Server verschickten HTTPS-Link in einen HTTP-Link umwandelt und somit die gesamte Kommunikation im Klartext mitliest.

Daher empfiehlt Steganos, nicht nur den Transportweg der Daten zu verschlüsseln, sondern auch die Daten selbst – und zwar bereits auf der lokalen Festplatte bevor sie ins Internet gelangen. Hierbei verweist das Unternehmen auf sein Software-Paket Privacy Suite, mit dem der Nutzer beispielsweise E-Mails und Cloud-Inhalte chiffrieren kann.

Selbst die zentrale Komponente der SSL-verschlüsselten HTTPS-Verbindungen – die zertifikatsbasierte Authentifizierung des Servers – stellt laut Steganos einen Unsicherheitsfaktor und möglichen Angriffspunkt für die NSA dar. So glauben die Verschlüsselungsexperten auch an eine Kompromittierung der eigentlich vertrauenswürdigen Zertifizierungsstellen durch den US-Geheimdienst, da das Geschäft mit den digitalen Dokumenten intransparent sei.

Normalerweise müsse man sich selbständig Zertifikate erstellen und signieren. Dies ist allerdings nicht möglich, da der Browser anhand seiner CA-Liste nur diejenigen Zertifikate als gültig anerkennt, die tatsächlich von öffentlichen und vertrauenswürdigen Zertifizierungsstellen wie Verisign stammen. Eine Ausnahme bildet hier allerdings die interne Datenkommunikation – etwa in Unternehmen. Dort sei es nach Steganos-Angaben durchaus möglich, eigene, selbst-signierte Zertifikate im Browser einzutragen und zu nutzen.

Einen weiteren Unsicherheitsfaktor sieht Steganos in den eingesetzten Zufallszahlengeneratoren. Erzeugen diese etwa aufgrund einer fehlerhaften Implementierung schwache Zufallszahlen, die gar nicht zufällig, sondern vielmehr vorhersagbar sind, lassen sich die daraus abgeleiteten geheimen Sitzungsschlüssel innerhalb weniger Tage berechnen. SSL-Verbindungen, die schwache Schlüssel verwenden, werden dadurch anfällig für Man-in-the-Middle-Angriffe. Das ist keine nur theoretische Möglichkeit: Es gab bereits eine solche Sicherheitslücke in einem Debian-Patch für die Verschlüsselungssoftware OpenSSL.