TSL/SSL-Sicherheitslücken vermeiden
Rettungsring für SSL
Das Verschlüsselungsverfahren SSL (Secure Sockets Layer) steht unter Druck: Schwachstellen und erfolgreiche Angriffe haben die Schutzwirkung des allgegenwärtigen Protokolls in den letzten Monaten in Frage gestellt. Bis die derzeit nur als Entwurf vorliegende Version 1.3 des SSL-Nachfolgers Transport Layer Security (TLS) die meisten Sicherheitslücken behebt, sind eine schnelle Reaktion und korrekte Konfiguration durch die Administratoren von großer Bedeutung.Das im Internet fast überall als Basisschutz eingesetzte SSL-Protokoll hat es im Moment nicht leicht. Mit Drown (Decrypting RSA with Obsolete and Weakened Encryption) ist innerhalb kürzester Zeit ein weiterer erfolgreicher Angriff auf das Protokoll aufgetaucht, der viele Administatoren zum Handeln zwingt. Drown nutzt eine Schwachstelle in der eigentlich seit vielen Jahren nicht mehr verwendeten Version 2.0 von SSL, um an den privaten Teil von RSA-Schlüsseln heranzukommen. Das funktioniert selbst dann, wenn die Verbindung eigentlich das aktuellere TLS verwendet. Insbesondere OpenSSL leidet unter diesem Angriff, denn er ist durch zwei weitere Schwachstellen im Code der beliebten SSL-Implementierung noch einfacher umsetzbar als bei anderen SSL-Implementierungen. Ein zeitgemäßer PC soll den Angriff in weniger als einer Minute absolvieren können. SSL als Basis für zahlreiche Dienste Dass SSL im Mittelpunkt so vieler Angriffe steht, ist kritischer, als viele annehmen. Die meisten bringen mit SSL ausschließlich sicheres Web-Surfen in Verbindung. Das ist eine Anwendung, die zwar Schutz bedarf, die aber (meist) keine katastrophalen Folgen nach sich zieht, wenn der Schutz brüchig wird. Doch SSL beziehungsweise sein Nachfolger TLS sind auch für die Sicherung einer ganzen Reihe weiterer Dienste im Internet zuständig. Die meisten E-Mail- und FTP-Clients unterstützen beispielsweise eine SSL/TLS-Variante, und für VPNs auf SSL-Basis sind solche Sicherheitslücken absolut unakzeptabel. Die sind durchaus relevante Dienste, deren Verlust der Vertraulichkeit für viele Menschen und Organisationen drastische Folgen haben könnte. Aber eigentlich ist es ohnehin ein Wunder, dass erst jetzt gehäuft Probleme auftreten. SSL wurde in den Neunzigern von Programmierern bei Netscape entwickelt, im Rahmen der Arbeiten am ersten massentauglichen Browser Mosaic. Zeitdruck und ein gänzlich anderes Sicherheitsverständnis als heute sorgten dafür, dass SSL ein relativ simples Protokoll wurde. Die erste Version von SSL wurde 1994 vorgestellt, SSL 2.0 folgte fünf Monate später, zusammen mit dem Netscape Navigator. Die Umbenennung zu Transport Layer Security im Jahr 1999 war eine Folge der Standardisierung durch die IETF (RFC 2246). Darum meldet sich heute auch TLS 1.0 im Header mit SSL 3.1. Die ersten Angriffe auf SSL zielten vor allem auf die Authentisierung ab. Beim Design von SSL wurde beschlossen, Zertifizierungsstellen (Certificate Authorities, CAs) als Kernelement zu verwenden. Das war theoretisch eine gute Idee, hat aber wahrscheinlich der Verbreitung des Protokolls nicht gut getan. In den Anfangsjahren von SSL waren die Zertifikate ausgesprochen teuer, und der bürokratische Aufwand, um ein Zertifikat zu erhalten, wirkte ebenfalls abschreckend. Erst in letzter Zeit wurden Anbieter aktiv, die sowohl den Prozess als auch die Kosten attraktiver gestalteten. Leider kam über die Jahre ein anderes Problem mit Zertifizierungsstellen hinzu: Die Sicherheit war nicht immer so, wie sie sein sollte, wenn man die Schlüsselstellung der wenigen Institute bedenkt. Durch die "letzte Instanz"-Stellung sind Verbindungen, die sich auf ein gefälschtes oder kompromittiertes Zertifikat berufen, kaum zu erkennen und gefährden die Kommunikation nachhaltig. Beispiele gibt es genügend: Ein von Bit9 gestohlenes Zertifikat wurde benutzt, um Malware zu legitimieren, Turktrust gab Zertifikate aus, mit denen Kriminelle Googles Server nachahmen konnten, und etwas Ähnliches passierte auch Comodo mit neun Zertifikaten, darunter mail.google.com und login.yahoo.com. Die Liste ließe sich noch um einige Fälle erweitern. Doch in letzter Zeit steht nicht mehr das Zertifikat im Mittelpunkt der SSL-Gefahren, sondern das Protokoll und seine Implementierung selbst. Drown ist nur das aktuellste Beispiel aus einer recht umfangreichen Liste von Schwachstellen, die meisten kamen in den letzten 24 Monaten zum Vorschein. Heartbleed (CVE-2014-0160) dürfte die bekannteste sein, nach ihrer Entdeckung war das öffentliche Interesse riesig. Bei Heartbleed können Angreifer die Keep-Alive-Nachricht (Heartbeat) zweier Kommunikationspartner missbrauchen, wenn OpenSSL als SSL-Implementierung zum Einsatz kommt. Eigentlich tauschen die beiden Kommunikationspartner nur ein Fragment der Session aus, das identisch sein muss. Durch den Fehler kann OpenSSL dazu gebracht werden, einen beliebigen, 64-kByte großen Speicherbereich mit Daten zu füllen und mit dem Angreifer auszutauschen. So wurde der Speicher in 64 kByte-Häppchen zum Angreifer übertragen, einschließlich der geheimen Schlüssel des Server-Zertifikats, Benutzernamen, Passwörter und verschlüsselt übertragene Daten wie E-Mails - und dies alles, ohne irgendwelche Spuren auf dem Server zu hinterlassen. Auf Heartbleed folgte Poodle (Padding Oracle On Downgraded Legacy Encryption), ein Man-in-the-Middle-Angriff auf den Client. Zudem gibt es Beast (Browser Exploit Against SSL/TLS), Lucky 13 und zwei weitere Man-in-the-Middle-Angriffe namens Freak (Factoring Attack on RSA-Export Keys) und Bar Mitzvah. Letztere Angrifssvariante nutzt den veralteten und unsicheren RC4-Verschlüsselungsalgorithmus aus. Die Häufung all dieser Schwachstellen hat zum einen mit verstärktem Interesse an Verschlüsselungs- und Datenschutzthemen zu tun, liegt zum anderen aber auch ganz banal an den veränderten technischen Möglichkeiten. Vor 20 Jahren stand die heutige Rechenleistung einer Amazon-S3-Cloud-Instanz vielleicht Regierungsorganisationen zur Verfügung, aber sicher keinem der damals ohnehin deutlich harmloseren Cyberkriminellen. Probleme und Abhilfe Grundsätzlich kämpft SSL im Moment an drei Fronten: Da sind erstens die ohnehin bekannten Schwächen des SSL-Protokolls. Obwohl die Schwachstellen bekannt sind, lassen sich fehlerbehaftete Versionen nur langsam abschalten, zu viele Nutzer verwenden noch Software, die auf den alten Standards beruht. Zweitens hat vor allem Heartbleed zu einer verstärkten Aufmerksamkeit für SSL geführt. Viele sehr kompetente Sicherheitsforscher beschäftigen sich seit einiger Zeit mit SSL und finden neue, bisher unbekannte Fehler. Und drittens hat auch SSL unter menschlichen Schwächen zu leiden: Schludrigre Administratoren, die ihre Server entweder nicht so sicher konfigurieren, wie sie könnten, oder schlicht Updates versäumen, tragen ebenfalls ihren Anteil zu geglückten Angriffen bei. Gegen Drown beispielsweise würde es schon genügen, SSL v2 und SSL v3 abzuschalten, die Protokolle sind hoffnungslos veraltet. Eine Studie von High-Tech Bridge, einem Pen-Testing-Anbieter, unterstützt diese Annahme. Deren Untersuchungen von im Internet erreichbaren SSL-VPN-Gateways fand eine erschreckend hohe Anzahl angreifbarer Server: Bis zu 77 Prozent der über 10.000 VPN-Server unterstützten nach wie vor SSL 3.0 und waren damit gleich für mehrere Schwachstellen empfänglich. Und obwohl die Studie Anfang 2016 durchgeführt wurde, waren zehn Prozent der OpenSSL-Server nach wie vor durch den Heartbleed-Bug verwundbar. Selbst wenn man Methodologie und Schlussfolgerungen der Studie mit Vorsicht genießt, scheinen Fehlkonfigurationen bei einem so sicherheitsträchtigen Dienst wie einem SSL-VPN ein großes Problem zu sein. Dies sind keine guten Aussichten für die Zukunft, zumal Gartner in seiner Studie "Security Leaders Must Address Threats From Rising SSL Traffic" schon 2013 eine jährliche Zunahme des SSL-Datenverkehrs von 20 Prozent voraussagte. Standardmaßnahmen einsetzen So richtig wird sich das Problem wahrscheinlich erst mit der flächendeckenden Einführung von TLS 1.3 lösen lassen. Im Moment befindet sich TLS 1.3 im Draft-Status und wird das noch bis Ende September 2016 bleiben. Der Entwurf ist auf Github abrufbar. Obwohl TLS 1.3 auf den Vorgängerversionen 1.1 und 1.2 basiert, wird sein Sicherheitsniveau deutlich höher sein, da man viele Altlasten wie Komprimierung und Cipher ohne AEAD (Authenticated Encryption with Associated Data) wegließ. RSA-basierter Schlüsselaustausch wurde ebenfalls zugunsten von Protokollen abgelöst, die Perfect Forward Secrecy (PFS) unterstützen und sich leichter analysieren lassen. RSA-Zertifikate werden auch in TLS 1.3 erlaubt sein, aber der Schlüsselaustausch wird mittels Diffie-Hellman oder Diffie-Hellman auf Basis elliptischer Kurven erfolgen. Dadurch wird ein neuer Schlüssel für jeden Austauschvorgang erzwungen, was abgefangene Session-Schlüssel nur für eine einzige Session brauchbar macht, hingegen nicht für das komplette Material, das Client und Server ausgetauscht haben. HMAC-SHA256-Verschlüsselung ist neu dazugekommen, IDEA und DES werden als veraltet eingestuft. TLS 1.3 ist die richtige Lösung, aber was tun, bis der neue Standard verabschiedet wurde und sich durchgesetzt hat? Für alle explizit benannten Schwachstellen gibt es in der Regel auch eine direkte Abhilfe. Ob die eigenen Server von Drown betroffen sind, lässt sich beispielsweise mit SSLyze herausfinden. Auf die IP-Adresse und den Port eines SSL-Servers angewendet, erhält man eine Liste der unterstützten Verschlüsselungseinstellungen, eben auch, ob SSL v2 unterstützt wird. Dieses sollte man dann - ebenso wie SSL v3 - tunlichst deaktivieren. Zur Heartbleed-Abwehr haben alle namhaften Hersteller, deren Software davon betroffen war, neue Versionen veröffentlicht. Sie basieren auf einem von OpenSSL bereitgestellten Patch. Qualys hat ein frei verfügbares API veröffentlicht, mit dem sich Server ebenfalls auf mehrere SSL-Schwachstellen testen lassen. Es ist bereits in Tools wie Metasploit, Seccubus und ein WordPress-Plug-in integriert. Eine sehr interessante weltweite Statistik stammt ebenfalls von Qualys: SSL Pulse gibt einen Überblick über mehr als 200.000 wichtige SSL-Websites. Sicherheitserweiterungen nutzen Die gute Nachricht in all den Schreckensmeldungen ist, dass die Entwicklung auch auf der Sicherheitsseite nicht stehengeblieben ist. Seit 2008 hat es immer wieder Erweiterungen und neue Features für SSL gegeben, die dabei helfen, das Protokoll sicherer einzusetzen. Dazu gehören HTTP Strict Transport Security, Content Security Policy, Public Key Pinning und Certificate Transparency. Gerade HTTP Strict Transport Security stellt sicher, dass eine bestimmte Website nur verschlüsselte Inhalte übertragen kann; dies ist auch eine wirksame Abhilfe für das beliebte Wegklicken von Sicherheitswarnungen wegen verdächtiger Zertifikate. Darüber hinaus sollten IT-Organisationen Regeln für den Umgang mit Zertifikaten aufstellen und einhalten. So müssen für den Host mit der CA, falls eine interne CA genutzt wird, besonders strenge Zugangsregeln gelten. Das Login sollte auf die Administratoren beschränkt sein, und Arbeiten am System müssen mit einem Nicht-Root-Account erfolgen. Die privaten Schlüssel sollten auf den Zielsystemen selbst generiert und verlorene oder abgelaufenen Schlüssel müssen schnell entfernt werden. Experten gehen zurzeit davon aus, dass die Schlüssellänge mindesten 2.048 Bit betragen muss. 4.096 Bit führen bei der meisten Hardware zu enorm langen Generierungszeiten, Handshakes und CPU-Auslastung. Der Nutzeffekt dürfte diese Nachteile in den meisten Fällen nicht rechtfertigen. In einer Studie der ENISA über Schlüssellängen und Algorithmen vom Oktober 2013 gehen die Autoren für die nächsten zehn Jahre von einer sinnvollen RSA-Schlüssellänge von 3.072 Bit aus. Bis dahin hat sich hoffentlich TLS 1.3 durchgesetzt, und die Schwachstellenparade von SSL hat endlich ein Ende gefunden. Ansonsten gelten für die Konfiguration von SSL-Servern und SSL-VPNs die gleichen Best Practices wie für jeden anderen via Internet erreichbaren Dienst. Zentrale Management-Konsolen erleichten dabei die Arbeit der Administratoren erheblich. Mindestanforderungen an Verschlüsselung und Protokollversionen sollten so hoch wie möglich sein, das Betriebssystem gehärtet und auf die Dienste reduziert, die wirklich unbedingt auf diesem Host erforderlich sind.
Lesen Sie mehr zum Thema
