Herzbluten bei SSL

((i)) 12.04.2014 05:24 Themen: Indymedia Netactivism Repression
Mit dem Bug Heartbleed, der seit Dienstag bekannt gemacht wurde, isteine dramatische Sicherheitslücke bei SSL-Verbindungen über Open-SSlbekannt geworden. Ein kleiner Programmierfehler führt dazu, dass mitrelativ einfachen Mitteln und ohne Spuren auf demattackierten Server zu hinterlassen, ein kleiner Teil desArbeitsspeichers ausgelesen werden kann.Ein Versuch, die Sicherheitslücke und ihre Auswirkungen verständlich zumachen. (Vorsicht! Stark vereinfacht, nix für Fortgeschrittene!)

Warum Verschlüsselung so wichtig ist

Wenn wir im Internet surfen, Daten hoch- und herunterladen, Texte veröffentlichen und sonst so unseren Kram machen, muss unser Computer eine Verbindung zu dem Zielrechner, bspw. de.indymedia.org, aufbauen und über diese Verbindung all die Daten schicken, die es für unsere Wünsche übertragen muss. Beim Surfen wird beispielsweise eine Anfrage geschickt an den Rechner de.indymedia.org, bitte die Hauptseite oder Artikel nr. xy zu liefern. Diese Informationen wandern dabei nicht direkt vom eigenen Computer an de.indymedia.org, sondern gehen dabei über einen Haufen anderer Computer. Diese Computer leiten die Informationen weiter, wie in einer Menschenkette, bei der ein Eimer Wasser immer weiter gereicht wird, bis er schließlich am Feuer ankommt.
Auf diesem Weg können die Informationen, die wir z.B. beim Veröffentlichen von Texten oder schreiben von e-mails verbreiten, auch von all den anderen Computern auf dem Weg eingesehen werden - ähnlich wie in einer Menschenkette in den Eimer geguckt werden kann.
Das ist für viele Informationen nicht gewollt - schließlich geht es die anderen Computer nix an, was es für Informationen sind, sie sollen nur weiter gereicht werden.
Um dieses Problem zu lösen, werden sensible Informationen (Usernamen, Passwörter etc.) im Normalfall verschlüsselt verschickt. Dazu tauschen die beiden arbeitenden Rechner, also der eigene Browserund der Zielserver (de.indymedia.org), Schlüssel aus.
Wenn man es sich bildlich vorstellen will: Die Server geben dem Browser einen Tresor, dessen Tür noch offen ist. Der Browser packt all die schicken Informationen jetzt in den Tresor und macht ihn zu - selber öffnen kann er ihn nicht mehr. Das kann nur der Empfänger, dessen Tresor er bekommen hat, denn nur der hat den passenden Schlüssel dazu. Also in unserem Beispiel de.indymedia.org. Umgekehrt funktioniert es ebenso, de.indymedia.org bekommt vom Browser einen offenen Tresor, packt da die Sachen rein, macht den Tresor zu und schickt ihn auf die Reise. Jeder dieser Tresore hat darüber hinaus noch eine Kennzeichnung, die ihn einmalig macht. Dadurch kann der Browser wissen, dass ein Tresor, der folgende Kennung hat, auch wirklich von dem Ziel kommt, was er erreichen will - und sich niemand anders verkleidet hat und einen falschen Tresor andreht. (Dazu später mehr)
All die helfenden Hände, die den Tresor jetzt zu de.indymedia.org schleppen, sehen nur noch, dass sie einen Tresor zu de.indymedia.org transportieren. Nicht mehr, was sich darin befindet.

Was macht Heartbleed?

Der Fehler, der als Heartbleed bekannt wurde, lässt einen 64kb großen Bereich des Arbeitsspeichers des Rechners einsehen - ohne Spuren zu hinterlassen. Dieser Bereich ist auch noch zentriert auf alles, was mit Verschlüsselung zu tun hat.
Also auf genau das, was eigentlich top secret sein soll.
Dadurch ist es erstaunlich schnell möglich, an verschiedene Informationen zu kommen. Passwörter, Usernamen - all das steht im Arbeitsspeicher im Klartext und kann so direkt benutzt werden wenn es zufällig gerade in dem Bereich auftaucht, der durch die Sicherheitslücke einsehbar ist.
64 Kilobyte hört sich zwar zunächst wenig an - doch wer mal zur Probe eine Textdatei erstellt mit einem Usernamen und dem dazugehörigen Passwort wird schnell sehen, dass 64 Kilobyte gar nicht so wenig ist. Da ist noch reichlich Platz.
Im schlimmsten Fall taucht sogar der sogenannte private Schlüssel des Servers auf, also die Kombination des Tresors, den nur der Rechner selbst kennen darf um den Tresor wieder öffnen zu können. Ist dieser bekannt kann natürlich jede helfende Hand auf dem Weg mal kurz vor dem Weitergeben den Tresor aufschließen und reingucken. Der Tresor ist somit wertlos geworden - nicht nur für eine Person sondern für alle Verbindungen zu diesem Rechner, da der Tresor immer gleich ist bzw. die gleiche Kombination hat. Da dieser Sicherheitsfehler zwei Jahre unbemerkt geblieben ist und der Angriff keine Spuren hinterlässt ist unklar, inwieweit die Verschlüsselung in der Vergangenheit überhaupt sinnvoll war und wie oft nicht doch heimlich reingeguckt wurde. Der NSA-Skandal zeigt auf, dass es von staatlicher Seite schon lange ein Interesse gibt, genau dies zu tun.

Und jetzt?

Der Fehler taucht nur in bestimmten Versionen des Programms Open-SSL auf, nämlich in den seit zwei Jahren aktuellen Versionen, also seit der Fehler in das Programm einprogrammiert wurde. Bekannt geworden ist er erst diese Woche. Inzwischen gibt es eine aktualisierte Version, die den Fehler behebt. Mit dem Update des Programms und dem Austausch der Schlüssel ist der Server wieder sicher. Die meisten Server haben recht schnell reagiert, viele haben erstmal ihre SSL-Verbindung geschlossen und erst nach dem Update wieder aufgemacht. Da es jedoch nicht nachvollziehbar ist, wer in der Zwischenzeit - also den vergangenen zwei Jahren - die Sicherheitslücke schon kannte und ausnutzte, ist es ratsam Passwörter zu ändern für alle Dienste die betroffen waren, sowie natürlich auch für alle anderen Konten, bei denen das gleiche Passwort genutzt wurde. Betroffen sind eine Unzahl an Webseiten, darunter Größen wie Google, Yahoo, Facebook, aber auch kleinere und politische Server wie riseup.net oder linksunten.indymedia.org. Eben alle, die das Programm Open-SSL für ihre SSL-Verschlüsselungen benutzt haben und dabei auf die fehlerhaften Versionen vertraut haben. Ironischerweise hat es also die zuerst getroffen, die ihre Seite besonders sicher gemacht und eigentlich vorbildlich gearbeitet haben.

Was ist mit Tor?

Tor ist ein System, was zusätzlich noch die eigene IP verschleiern soll. Dazu leitet es den Verkehr über mindestens drei Rechner des Tor-Netzwerkes, von denen der erste Rechner weiß, von wem die Anfrage kam und an wen sie zurück geleitet werden muss und der letzte Rechner nur weiß, an wen die Anfrage geschickt wird und die Antwort bekommt. Durch diese Technik ist es möglich, dass alle helfenden Hände nicht mehr wissen, wer z.B. den Artikel auf de.indymedia.org hochgeladen hat.
Denn in unserem obigen Beispiel wissen die Hände zwar nur, dass sie einen Tresor zu Indymedia transportiert haben und kennen nicht seinen Inhalt, aber sie wissen immer noch, dass etwas zu Indymedia transportiert wurde.
Dazu benutzt auch Tor wiederum eine Verschlüsselung, packt also den Tresor in einen weiteren Tresor. Durch dieses Schachtelsystem ist im Nachhinein nicht mehr festzustellen, von wem der Tresor kam der jetzt bei de.indymedia.org angeliefert und dort geöffnet wird. Doch hier gilt ebenso: wenn die Tresore nicht mehr schließen, dann bringt das ganze Verpacken nichts.
Auch das Tor-Netzwerk gilt seit dem Fehler als nicht mehr sicher, da es ebenso auf eine fehlerhafte Version von Open-SSL vertraut hat, diesen Job zu machen. Eine aktualisierte Version des Tor-Browser-Bundles behebt den Fehler und ist seit Mittwoch auf der Seite des Tor-Netzwerkes herunter zu laden. Allerdings warnen die Tor-Entwickler selbst, Tor momentan zu benutzen und lieber ein wenig zu warten, bis die Tor-Nodesalle nachgezogen haben.

Ist Indymedia jetzt auch betroffen?

de.indymedia.org ist von Heartbleed nicht betroffen - einfach weil wir unsere alte Software nicht mehr gepflegt bekommen. Das hat sich jetzt als Glücksfall erwiesen, ist aber kein Grund Freudensprünge zu machen. Denn auch unsere Verschlüsselungstechniken entsprechen nicht mehr dem Stand der Zeit, auch wenn wir sie noch als sicher einstufen.
Problematisch ist für uns, dass das alte System eben nicht mehr so leicht gepflegt werden kann, das heißt es wäre viel Arbeit. Und da wir nur sehr begrenzte Arbeitskraft zur Verfügung haben stecken wir die lieber in das neue System. Bei unserem Beta-Test mussten wir ebenfalls das Update machen und neue Schlüssel generieren.

Was ist mit der Warnung? Firefox sagt mir, ihr wärt nicht sicher!

Die Warnmeldung, die im Browser wie Firefox kommt, sagt aus, dass der Browser nicht erkennen kann, ob du wirklich mit de.indymedia.org verbunden bist. Das hat folgenden Hintergrund:
Um bei obigem Bild mit den Tresoren zu bleiben ist es so, dass der Tresor, der von de.indymedia.org geliefert wird, eine bestimmte Kennzeichnung hat - eben die Kennzeichnung, dass er nur von de.indymedia.org geöffnet werden kann. Diese Kennzeichnung ist der sogenannte "Fingerprint".
Da nicht jeder zu Hause eine Liste mit Kennzeichnungen der Tresore von allen Seiten liegen hat mit denen er sich verbindet und die dann bei jeder Verbindung nachprüft, gibt es sogenannte Zertifizierungsstellen. Diese sind im Endeffekt nichts anderes als Verwalter von Kennzeichnungen, also ein Archiv, in dem die Kennzeichnungen hinterlegt sind. Verbindest du dich mit einer Webseite über SSL prüft der Browser, ob die Kennzeichnung in einem Archiv hinterlegt ist und wem diese Kennzeichnung gehört (stark vereinfacht ausgedrückt!). In unserem Fall also müssten wir bei einem Archiv anfragen, ob sie für uns die Kennzeichnung zertifizieren wollen zusammen mit dem Domain-Namen de.indymedia.org.
Dann würde dein Browser erkennen, dass die Kennzeichnung wirklich zu der domain de.indymedia.org gehört und somit kein anderer so tut als ob er de.indymedia.org sei. Für den Browser wäre dann alles in Ordnung und er verbindet ohne Warnmeldung.
Leider gibt es keine unkommerziellen und progressiven Stellen im Netz, die diesen Service so anbieten, dass er auch von dem Browser erkannt und akzeptiert wird. In der Vergangenheit haben wir Cacert als Zertifizierungsstelle benutzt. Doch diese ist nicht Standardmäßig im Firefox als Zertifizierungsstelle eingetragen (aus unterschiedlichen Gründen, die alleine einen eigenen Artikel über das Thema wert wären).
Das heißt: erst wenn im Browser Cacert als Zertifizierungsstelle eingetragen wurde (installieren eines sogenannten Root-Zertifikats) würde die Warnmeldung verschwinden. Es brachte uns also nicht um diese Warnmeldung herum.
In der Vergangenheit gab es darüber hinaus mit kommerziellen Zertifizierungsstellen erhebliche Bauchschmerzen - es wurde bekannt, dass verschiedene Zertifizierungsstellen zum Beispiel mit der NSA kooperierten - was für uns den Sinn der Zertifizierung sinnlos macht. Und sie sind in der Regel teuer.
Leider gibt es bis heute keine Zertifizierungsstelle, der wir wirklich vertrauen können. Daher haben wir bisher ein selbstsigniertes Zertifikat benutzt, also auf Zertifizierungsstellen verzichtet.
Das führt dazu, dass der Browser diese Warnmeldung ausspuckt - er kann einfach nicht wissen, ob er der Seite vertrauen soll, da sie bei seinen Zertifizierungsstellen nicht eingetragen ist. Wenn die "Ausnahmeregel" benutzt wird, kann die Kennzeichnung (Fingerprint) vom Browser selbst gespeichert werden - ab da warnt er nur noch, wenn die Kennzeichnung von der abgespeicherten Ausnahmeregel abweicht.
Dein Browser wird also zu solch einer Zertifizierungsstelle. Wenn du also den Fingerprint vor dem Abspeichern der Ausnahmeregel überprüfst und fest stellst, dass es übereinstimmt mit dem Fingerprint den wir veröffentlichen dann bist du genauso sicher (wenn nicht noch sicherer) als wenn du dich auf eine Zertifizierungsstelle verlässt. (Wenn du sicher gehen willst holst du dir den Fingerprint zum Überprüfen lieber über einen anderen Kanal als über die Webseite - z.B. fragst du uns per e-mail nach dem Fingerprint.)
Inzwischen gibt es kommerzielle und im Firefox eingetragene Zertifizierungsstellen, die auch kostenlos (oder zumindest fast) diesen Dienst für non-profit-Unternehmen anbieten. Wir überlegen, ebenfalls auf eine solche Zertifizierungsstelle zurück zu greifen, da wir in Zukunft auch das Surfen auf unserer Seite verschlüsselt anbieten wollen. Und da die Warnmeldung so stark verschreckend ist, würde das vermutlich bedeuten, einen großen Teil abzuschrecken - einfach weil sie nicht verstehen, was Firefox sagt. Alles was sie lesen ist "Gefahr!".
Der Vorteil wäre, dass die Warnmeldung verschwindet, die Sicherheit basiert dann aber leider auch auf dem Vertrauen zu dieser Zertifizierungsstelle. Eine heikle Entscheidung die mit Bauchschmerzen verbunden ist, egal für welche Lösung wir uns entscheiden.

Und nun? Kann ich noch Artikel veröffentlichen?

Prinzipiell hat sich nichts geändert. Es kann nach wie vor veröffentlicht werden, Heartbleed betrifft de.indymedia.org nicht. Auch linksunten.indymedia.org hat open-ssl bei sich bereits auf den neuesten Stand gebracht und seine Schlüssel ausgetauscht, es gilt also auch wieder als sicher (von hier mal ein anerkennendes Lob an die Techies von linksunten, dass sie das so schnell und reibungslos geschafft haben!).
Da aber das Tor-Netzwerk zur Zeit als nicht sicher gilt bitten wir euch, dringenst auch andere Methoden zur Verschleierung eurer Identität zu benutzen wenn ihr sensible Sachen veröffentlichen wollt oder einfach nicht wollt, dass die NSA euch über die Schulter schauen kann. Auch wenn wir keine IP-Adressen speichern und von uns aus alles so sicher und anonym machen wie es geht - die Aufgabe, euch sicher im Netz zu bewegen können wir euch nicht abnehmen. Dazu gehören z.B. Internetcafes ohne Überwachung, das Benutzen von größeren WLans bei denen nicht abgespeichert wird, wer was wann macht oder auch einen VPN-Proxy eurer Wahl zu benutzen. Vielleicht hat der Artikel aber auch einfach noch ein paar Tage Zeit, bis das Tor-Netzwerk wieder sicher ist. Nur weil wir meinen, dass uns vertraut werden kann, meinen wir nicht, dass ihr dem Weg bis zu uns trauen könnt.



Neuer Fingerprint von Linksunten:https://linksunten.indymedia.org/de/node/110407
Unser aktueller sha1-Fingerprint lautet:
D4:F9:2F:2B:06:16:93:FD:E0:F7:F7:BC:5B:52:6D:3A:64:3A:B4:7E

Creative Commons-Lizenzvertrag Dieser Inhalt ist unter einer
Creative Commons-Lizenz lizenziert.
Indymedia ist eine Veröffentlichungsplattform, auf der jede und jeder selbstverfasste Berichte publizieren kann. Eine Überprüfung der Inhalte und eine redaktionelle Bearbeitung der Beiträge finden nicht statt. Bei Anregungen und Fragen zu diesem Artikel wenden sie sich bitte direkt an die Verfasserin oder den Verfasser.
(Moderationskriterien von Indymedia Deutschland)

Ergänzungen