So schlimm?! Was können Alice und ich jetzt machen?

Die zentrale Idee für informationelle Selbstbestimmung im Internet ist, Datenschutz aktiv durch digitale Selbstverteidigung zu betreiben. Dazu muss Alice erstens selbst entscheiden, wann sie anonym bleiben möchte, wann sie ihre Handlungen z. B. durch Cookies für welche Zeiträume protokollieren lässt, und wann sie ihre Anonymität wem gegenüber aufgibt, um Dienste in Anspruch zu nehmen. Zweitens muss Alice geeignete Software installieren und konfigurieren, um ihre Entscheidungen auch durchsetzen zu können. Auf Schutz durch andere sollte sie nicht warten. In diesem Abschnitt erläutere ich grundlegende Techniken (Grundsicherung des PCs, asymmetrische Kryptographie als Grundlage der Verschlüsselung im Internet, Proxy-Verfahren als Grundlage von Anonymität im Internet), bevor nachfolgend konkrete Software-Projekte thematisiert werden. Wie in der Einleitung bereits angedeutet, halte ich den Einsatz eigener Hardware entsprechend der ↑FreedomBox-Vision für ratsam; die Verwendung unfreier, versklavender Cloud-Dienste in den USA mit fragwürdigen Datenschutz- Datenschatz- und Nutzungsbedingungen ist keine gute Idee.

Inhalt der folgenden Unterabschnitte:

Grundsicherung des PCs

Jeder mit dem Internet verbundene Computer (also PCs, Router, Telefone, Tablets, E-Books, smarte Brillen, Uhren, Glühbirnen, Stromzähler und TVs, digitale Puppen, Autos usw.) ist Angriffsversuchen ausgesetzt, durch die Unbekannte Zugriff auf unsere Geräte, unsere Daten (Passwörter, Kontodaten, Kreditkarteninformationen, Lebensumstände und Vorlieben, Forschungsergebnisse, strategische Informationen) oder einfach auf unsere Rechenleistung und Bandbreite erhalten wollen (der Computer wird beispielsweise zum ↑Bot/Zombie [↑Erläuterungen vom Bundesamt für Sicherheit in der Informationstechnik mit 6-minütigem Animationsfilm], der Spam versendet, an DDoS-Angriffen teilnimmt, illegale Inhalte verteilt, Bitcoins schürft etc.).

Jeder Computer wird mit fehlerhafter Software ausgeliefert, die anfällig für ↑Zero-Day-Exploits ist, also für Angriffe, gegen die es keinen Schutz gibt. Das betrifft PCs, Router, Telefone, Tablets, E-Books, smarte Brillen, Uhren, Glühbirnen, Stromzähler und TVs, digitale Puppen, Autos usw.

Ich hatte bereits erwähnt, dass „offline“ ein starkes Qualitätsmerkmal ist. Ich möchte dies wiederholen: Offline ist ein starkes Qualitätsmerkmal.

Darüber hinaus wissen wir spätestens seit den Snowden-Enthüllungen, dass Geheimdienste Geräte mit Hintertüren ausstatten (lassen), wie der vom Spiegel im Jahre 2013 dokumentierte ↑50-seitige ANT-Katalog gezeigt hat. Lesen Sie den ↑Spiegel-Artikel nochmal nach: Es geht nicht um Terrorabwehr, sondern Spionage mit Zielen in Politik und Wirtschaft. Hardware aus den USA wird schon auf dem Postwege mit Hintertüren versehen.

Natürlich gehen nicht nur die USA so vor. Jeder gute Auslandsgeheimdienst dürfte ähnliche Programme verfolgen, nur sind die fähigeren bisher noch nicht in die Schlagzeilen geraten. Beispielsweise erfordert ein chinesisches Gesetz aus dem Jahr 2015, dass ↑Technologie für kritische Sektoren (wie Banken und Versicherungen) „sicher und kontrollierbar“ sein müsse, was mit dem Einbau von Hintertüren und der Herausgabe von Verschlüsselungsschlüsseln interpretiert wird. China und USA. Wo kommen unsere Hard- und Software nochmal her?

Hintertüren können generell (von Geheimdiensten wie anderen Kriminellen) in der Hardware, im ↑BIOS, in ↑Firmware (z. B. von Prozessor, Festplatten oder Netzwerkkarten), im Betriebssystem oder in anderer Software eingebaut werden. Eine schockierende, aber faszinierende Forschungsarbeit zeigte im Jahre 2013, wie ↑Trojaner in der Hardware durch eine Änderung der Dotierung von Transistoren verborgen werden können. Weil diese Art von Hardware-Trojanern keine zusätzlichen Schaltkreise benötigt, ist es nahezu unmöglich, sie zu entdecken.

Kriminelle, die uns über das Internet angreifen, verfügen nicht über die Möglichkeit, unsere Hardware mit Hintertüren bzw. ↑Trojanern auszustatten. Sie müssen daher auf die nächstbeste Möglichkeit zurückgreifen, nämlich ↑Firmware-Trojaner, die auch in oben zitiertem ↑Spiegel-Artikel erwähnt werden. Diese Trojaner überleben in der ↑Firmware naturgemäß selbst die Neuinstallation des Betriebssystems. Als Reaktion auf die im Zuge von ↑„Vault 7“ enthüllten CIA-Angriffswerkzeuge hat ↑Intel im März 2017 das Werkzeug CHIPSEC veröffentlicht, mit dem man sein BIOS auf unbefugte Modifikationen prüfen kann.

Die IT-Sicherheitsexpertin und ↑Qubes-OS-Entwicklerin Joanna Rutkowska hat im Jahre 2015 detailliert aufgeschlüsselt, dass ↑praktisch keine Aussicht besteht, Rechner mit modernen Intel-Prozessoren abzusichern. Besonders gravierend ist, dass Intel-Prozessoren seit 2008 eine sogenannte Management Engine (ME) beinhalten. Diese ME ist ein eigener Computer innerhalb des Prozessors, der Zugriff auf die gesamte Hardware besitzt (einschließlich Hauptspeicher- und Netzwerkzugriff) und der durch außerhalb von Intel unbekannte, in der Firmware fest verdrahtete Software gesteuert wird. Mir als Informatiker erscheint das schon bemerkenswert: Im Allgemeinen steuern wir Programmierer, was der Prozessor als Gehirn eines Rechners macht. Im Falle von Rechnern mit modernen Intel-CPUs sind uns diese Steuerung und Kontrolle entzogen. Bei AMD ist die Lage übrigens auch nicht besser – mit dem Platform Security Processor (PSP) gibt es dort ein Äquivalent zur ME.

Ich hatte bereits erwähnt, dass freie Software empfehlenswert ist, um Kontrolle über unsere Geräte zu erhalten. Ich möchte dies wiederholen: Verwenden Sie freie Software.

Die Free Software Foundation führt Zertifizierungen für Hardware durch, die unsere Freiheit respektiert. (Das sind natürlich keine schicken Bleeding-Edge-Geräte mit modernen Prozessoren, sondern solide Geräte mit älteren Prozessoren, die noch keine oder eine deaktivierte Management Engine beinhalten. Wie gesagt, unsere Marktmacht entscheidet.)

Nach dieser deprimierenden Einleitung hoffe ich, dass Sie noch nicht verzweifelt sind, und versuche nun, Sie zur Absicherung Ihres PCs zu motivieren. Lassen Sie mich zu einer Analogie greifen. Vermutlich verschließen Sie die Tür, wenn Sie Ihr Haus oder Ihre Wohnung verlassen. Warum eigentlich? Schlüsseldienste bzw. Kriminelle mit deren Werkzeugen können die Tür wahrscheinlich in kurzer Zeit öffnen. Und wenn die nicht, dann jeder, der mit einem Vorschlaghammer oder einer Abrissbirne einen neuen Eingang anlegt. Der entscheidende Punkt ist, dass Sie sich durch die verschlossene Tür nicht als Opfer aufdrängen, auch wenn Ihnen klar ist, dass Sie Einbrüche nicht verhindern können. Ähnlich sollte es auch im Internet sein: Lassen Sie Ihre Türen nicht geöffnet stehen, drängen Sie sich nicht als Opfer auf.

Die folgenden Maßnahmen sind für private Rechner gedacht, um deren Angriffsfläche zu reduzieren und um den von einem Angriff verursachten Schaden zu reduzieren. Im Unternehmenskontext ist stattdessen ein systematisches Sicherheitsmanagement erforderlich, wie es beispielsweise nach den ↑BSI-Vorgaben zum IT-Grundschutz aufgebaut werden kann.

Live-CD. Die einfachste Art, den Rechner zu schützen, ist der Einsatz einer Live-CD. Hier wird das Betriebssystem von einer CD/DVD gestartet, die nur lesbar ist (oder von einem USB-Stick mit Schreibschutzschalter). Selbst wenn ein Angreifer eindringen kann, kann er das Betriebssystem nicht verändern, so dass Alice beim nächsten Start wieder ein sauberes System nutzt. (Nach den einleitenden Erläuterungen sollte klar sein, dass es auch hier keine garantierte Sicherheit gibt. Schadsoftware kann sich nicht nur im Betriebssystem einnisten, sondern auch im BIOS oder in Firmware. Sie kann auch ab Werk oder seit einer Zwischenstation bei der Lieferung in der Hardware eingebaut sein. Dennoch verschaft ein Live-System einen deutlichen Sicherheitsvorsprung gegenüber einem „normalen“ PC.)

Ein bekanntes GNU/Linux-Live-System ist ↑Knoppix. Darüber hinaus können viele verbreitete ↑GNU/Linux-Distributionen wie ↑Ubuntu und ↑Fedora als Live-CDs gestartet werden. ↑Tor ist hier allerdings nicht enthalten.

Demgegenüber ist ↑Tails ein sowohl von CD als auch USB-Stick ausführbares Live-↑Debian-GNU/Linux, das verspricht, sämtliche Netzwerkdaten automatisch durch ↑Tor zu leiten und keinerlei Spuren auf der Festplatte zu hinterlassen. Weder Alice noch ich haben diese CD bisher getestet. Die durch ihre Arbeit mit Edward Snowden bekannt gewordene ↑Laura hält ↑Tails für ein hervorragendes Werkzeug.

Speziell für ihr Online-Banking verwendet Alice ↑Bankix, ein mittlerweile eingestelltes Projekt des Heise-Verlags, das als Live-System sowohl von CD als auch vom USB-Stick mit mechanischem Schreibschutzschalter gestartet werden kann. Das Booten vom USB-Stick funktioniert allerdings nicht auf „älteren“ Rechnern, und selbst bei neueren kann es sein, dass diese bei aktiviertem Schreibschutz nicht mehr vom USB-Stick starten wollen (dann bleibt nur die Nutzung der Live-CD). Nach dem ersten Boot-Vorgang installiert Alice zunächst die Online-Updates. (Wenn der Vorgang mit Hinweis auf mangelnden Speicher abbricht, kann es helfen, die Anwendung Thunderbird zu deinstallieren und den Update-Vorgang erneut zu starten. Wenn auch das nicht reicht, muss das Dateisystem vergrößert werden: Bankix nutzt das Dateisystem overlayfs, um Änderungen am Betriebssystem in den Hauptspeicher „umzuleiten“, so dass beim nächsten Neustart wieder das unveränderte System geladen wird. Beim Einrichten können Änderungen einmalig festgeschrieben werden. Die Größe des Overlay-Dateisystems, das als tmpfs-Dateisystem unter /cow im Hauptspeicher liegt, wird standardmäßig auf die Hälfte des Hauptspeichers gesetzt. Bei 1GB Hauptspeicher sind 500MB für Updates dann zu knapp, und bei mir hat Folgendes geholfen: sudo mount -o remount,size=700M tmpfs /cow) Nach Lektüre des Unterabschnitts zu SSL/TLS installiert Alice die Firefox-Erweiterung ↑Certificate Patrol (evtl. auch ↑Perspectives) und besucht jede ihrer Online-Banking-Seiten. Sie akzeptiert die Zertifikate mit Certificate Patrol (trust on first use) und legt Lesezeichen für ggf. fehlende Online-Banking-Seiten an. Sie schließt die Installation wie auf der ↑Projektseite beschrieben durch Speichern (und ggf. Brennen) der Systemeinstellungen ab. Durch Certificate Patrol wird Alice nun sowohl auf ↑Man-In-The-Middle-Angriffe als auch reguläre Zertifikatänderungen hingewiesen. Perspectives kann Hinweise geben, um beide Fälle voneinander zu unterscheiden. Bei regulären Zertifikatänderungen bestätigt sie diese mit Certificate Patrol und aktualisiert ihre Systemeinstellungen (was im Falle eines USB-Sticks mit mechanischem Schreibschutz einfacher ist als das Brennen einer neuen CD).

Für Bastler kommt evtl. auch das Aufsetzen eines ↑benutzerfreundlichen, schreibgeschützten Live-Systems mit SATA-DOM in Frage.

Falls Alice ein „normal installiertes“ Betriebssystem nutzt, beachtet sie alle folgenden Punkte.

Firewall. Alice aktiviert eine Firewall, bevor sie den Rechner erstmalig an das Internet anschließt. Dies ist notwendig weil nahezu jedes Betriebssystem in der Standardkonfiguration Dienste startet, auf die über das Internet zugegriffen werden kann und die zudem Programmierfehler enthalten, durch die ein Angreifer Kontrolle über den Rechner erlangen kann. Der Erfolg der Würmer ↑Blaster und ↑Conficker demonstrierte dies sehr eindrucksvoll. Man beachte, dass derartige Würmer keinerlei Interaktion von Alice erfordern: Sie installiert nichts aus dubiosen Quellen, sie öffnet keine Anhänge. Sie schließt ihren Rechner lediglich an das Internet an. Wenn Sie allerdings ihre (richtig konfigurierte) Firewall aktiviert, werden alle Dienste vor Zu- und damit Angriffen aus dem Internet abgeschirmt.

Alice hört übrigens nicht auf Ratschläge, auf die Firewall zu verzichten, wenn sie stattdessen alle nicht benötigten Dienste deaktiviert. Sie bliebe dann nämlich bei allen Schwachstellen in den Netzwerkprotokollen selbst schutzlos (z. B. ↑dieser hier). Bei ↑manchen Schwachstellen in Netzwerkprotokollen ist sie allerdings immer noch schutzlos, weil ↑die Firewall löchrig ist. (Zudem hofft Alice, dass das Aktivieren der Firewall nicht allzu viele zusätzliche Schwachstellen aufreißt.)

Backups. Alice sichert die ihr wichtigen Dateien regelmäßig auf einer externen USB-Festplatte. Falls sie ihren Rechner nach einem Angriff neu aufsetzen muss, sind keine wichtigen Daten verloren. Selbst wenn sie nicht angegriffen wird, werden ihre Festplatten (auch die externe für die Backups) irgendwann den Geist aufgeben (es handelt sich um rotierende Magnetplatten mit allerhand Feinstmechanik, die natürlichem Verschleiß unterliegt). Zudem prüft sie gelegentlich, ob die Backups noch lesbar sind. Dies gilt ebenfalls für Backups auf CD oder DVD.

Virenscanner, Antivirus-Software. Unter GNU/Linux benötigen Alice und Bob (noch?) keinen Virenscanner. Unter dem Betriebssystem, das auf den meisten PCs vorinstalliert ist, verlasse ich mich auf den mitgelieferten Virenscanner in Kombination mit ↑EMET, obwohl der mitgelieferte Virenscanner in Tests regelmäßig nicht zur Spitzengruppe gehört. Beide (Virenscanner und EMET) verfolgen das Ziel, vor schädlichen Inhalten aus dem Internet zu schützen (z. B. Viren in E-Mails, Trojaner in heruntergeladener Software, Angriffs-Code in Office-Dokumenten, PDF-Dokumenten und Web-Seiten). Der Schutz von Virenscannern wirkt natürlich nur, wenn die Angriffsmuster bereits bekannt sind; EMET aktiviert zusätzliche Schutzmaßnahmen. Dennoch benutzt Alice ihren gesunden Menschenverstand und ist vorsichtig mit Inhalten aus unbekannten Quellen. Gegen gezielte Angriffe wie beispielsweise ↑auf Pro-Tibet-Gruppen in 2008 und ↑2015 bleibt sie allerdings schutzlos … Weitergehende Sicherheit ist experimentierfreudigen Menschen vorbehalten, die etwa ↑SELinux oder ↑Qubes OS einsetzen.

Generell empfehle ich natürlich, Windows überhaupt zu nicht verwenden, sondern freier Software den Vorzug zu geben. Unfreie Virus-Scanner sind gefährlich, vor Sicherheitslücken in denjenigen von ↑Symantec und Norton warnte im Juli 2016 das US-CERT, im November 2016 dann auch ↑das Bundesamt für Sicherheit in der Informationstechnik. Zum Jahreswechsel 2016/17 machte auch ↑Kaspersky Negativschlagzeilen.

Auch Browser-Hersteller wie Google (Chrome) und Mozilla (Firefox) halten viele Arten von ↑Antivirus-Software für schädlich, wie ein kurzer Artikel auf heise online im Januar 2017 nachdrücklich dokumentiert.

Browser mit NoScript und Werbe-Blocker. Alice verwendet unterschiedliche Browser, nämlich den Tor Browser für das „normale“, anonymisierte Surfen und den Firefox mit nachfolgender manueller Konfiguration für spezielle Fälle.

Sie benutzt zunächst den Menüeintrag Bearbeiten → Einstellungen → Datenschutz → „Firefox wird eine Chronik: nach benutzerdefinierten Einstellungen anlegen“ mit der Auswahl „Die Chronik löschen, wenn Firefox geschlossen wird“, um zumindest Cookies, Cache und sonstige Spuren ihres Web-Lebens regelmäßig zu löschen. Bob favorisiert hier: „Firefox wird eine Chronik: niemals anlegen“

Was Alice tun muss, um Kontrolle über Caching, Cookies, Web-Bugs und aktive Inhalte zu gewinnen, hängt von ihrer Wahl des Anonymisierungsdienstes ab: ↑JAP/↑JonDo empfiehlt eine andere Konfiguration als ↑Tor. In jedem Fall vergewissert sie sich, dass die Firefox-Erweiterung NoScript installiert ist, weil diese aktive Inhalte solange blockiert, bis Alice sie explizit erlaubt. Alice installiert ↑NoScript hier per HTTPS.

Wer den Tor Browser einsetzt, muss selbst entscheiden, ob NoScript aktiviert sein soll oder nicht, wie im Abschnitt zu Tor dargelegt wird. Alice und Bob haben sich entschieden, NoScript zu aktivieren; zum einen reduziert dies die Gefahr, Opfer eines ↑Drive-By-Downloads zu werden, zum anderen stellt der Browser dann weniger Informationen zur Verfügung, die Fingerabdrücke aussagekräftiger werden lassen. Sie sorgen über den Sicherheitsschieberegler im Tor Browser dafür, dass die Einstellung „Skripte allgemein erlauben (nicht empfohlen)“ nicht aktiviert ist, da NoScript sonst ausgeschaltet ist.

NoScript ist deshalb so wichtig, weil moderne Browser mit ihren zahlreichen Medientypen, Plugins und aktiven Inhalten (für Java- und Flash-Spiele, interaktive Seiten, Musik, Videos, Bilder, Zeichensätze und PDF-Dokumente) zahlreiche Sicherheitslücken enthalten, durch die Alice’ Rechner beim Besuch einer beliebigen Web-Seite in einen Bot/Zombie verwandelt werden kann. Manche dieser Sicherheitslücken lassen sich allein durch das Anschauen einer entsprechend präparierten Web-Seite ausnutzen, wodurch automatisch beliebige Schad-Software im Hintergrund heruntergeladen und installiert werden kann, ohne irgendeine Nutzerinteraktion zu erfordern. Diese automatische Installation von Schad-Software wird als ↑Drive-by-Download bezeichnet und stellt eine ernstzunehmende Gefahr dar. Da die meisten der zugrunde liegenden Sicherheitslücken von JavaScript bereitgestellte Funktionalität voraussetzen und da JavaScript von NoScript deaktiviert wird, kann NoScript viele Arten von Angriffen auf den Browser verhindern.

Ad-Blocker/Werbe-Blocker gegen Malvertising. In ihrem „normalen“ Browser (also nicht dem Tor Browser, siehe ↑FAQ-Eintrag zu Erweiterungen) installiert Alice zudem die Firefox-Erweiterung ↑uBlock Origin als Ad-Blocker/Werbe-Blocker, der im Zusammenhang mit Web-Bugs erwähnt wurde. Zunächst verhindert dies, dass zahlreiche bekannte (und unbekanntere) Werbenetze Informationen über Alice sammeln. Andererseits erhöht dies die PC-Sicherheit, da über kompromittierte Werbenetze ↑seit langem (2008) und ↑immer wieder (2010) Schadprogramme wie ↑Viren und Trojaner per Drive-by-Download (2012) in Werbebannern verteilt werden, wovor auch das ↑Bundesamt für Sicherheit in der Informationstechnik warnt (2013) und ↑wovor noch nicht einmal Malvertising-Experten gefeit sind (2015).

Diese Problematik hat sich mittlerweile eher verschärft, da Schad-Software nicht mehr nur über kompromittierte Werbenetze verteilt wird, sondern in von kriminellen regulär bezahlten Anzeigen als Werbebanner ausgeliefert werden, weshalb es mit ↑Malvertising inzwischen einen eigenen Begriff für das Ausliefern von Malware über Werbung (Advertising) gibt. Beispiele solcher Malware wurden bei ↑Zedo und der Google-Tochter Doubleclick (2014), bei ↑Yahoo! (2015), bei ↑MSN.com (2015), bei ↑Google Ads (2015) wieder bei ↑DoubleClick sowie weiteren Werbenetzen (2015), bei ↑eBay.de und t-online.de (2015) und bei ↑AOL, BBC, New York Times (2016) beobachtet. Eine im ↑Sommer 2016 entdeckte Malvertising-Kampagne verseuchte so diverse Web-Seiten wie New York Times, Playboy, Sky.com, Answers.com und andere, was seit 2013 unentdeckt geblieben sein könnte. Eine neue Spielart von Malvertising wurde im Dezember 2016 beschrieben, die nicht PCs direkt angreift, sondern ↑Heim-Router infiziert, von denen ausgehend dann sämtliche heimischen Geräte angegriffen werden. Aktuelle Fälle von ↑Malvertising werden regelmäßig im Blog Malwarebytes.org dokumentiert.

Auf Werbeeinnahmen angewiesene Medien zeigen sich gegenüber Malvertising erstaunlich lernresistent: ↑So infizierte Forbes im September 2015 seine Besucher durch Malvertising, nur um diese ↑im Januar 2016 aufzufordern, ihre Ad-Blocker zu deaktivieren und dann direkt wieder Malware auszulieferen.

Als wäre dies nicht schon schlimm genug, können die Tracking-Identifikatoren der Werbenetze (z. B. Cookies) auch ohne Malware von anderen Kriminellen für gezielte Angriffe missbraucht werden: Im Rahmen der Snowden-Enthüllungen wurde bekannt, dass ↑NSA und GHCQ die Cookies von Google als Identifikatoren für Spionagetätigkeiten verwenden, was es in Kombination mit dem ↑Angriffsprogramm QUANTUM ermöglicht, Rechner zielgerichtet zu übernehmen.

Als Schlussfolgerung bleibt nur: Ein Werbe-Blocker ist digitale Selbstverteidigung, und ich empfehle ↑uBlock Origin für den Firefox. (Früher hatte ich hier mal Adblock Plus empfohlen. Nach den ↑Recherchen von Sascha Pallenberg zur „nicht aufdringlichen Werbung“, die auch ↑bei Heise zusammengefasst werden, dann das verbesserte Adblock Edge, das inzwischen durch ↑uBlock Origin abgelöst wurde.)

Updates. Alice spielt regelmäßig Updates ihrer Software ein, da diese oft Sicherheitslücken schließen. Sie macht dies nicht nur für das Betriebssystem, sondern achtet auf zusätzlich installierte Programme (z. B. den Browser und alle seine Plugins, Virenscanner, Office-Produkte, PDF-Viewer, Video-Player, Java). Notorisch ↑gefährliche Software wie Adobe Flash, die regelmäßig für Angriffe ausgenutzt wird, verwendet sie gar nicht.

Benutzerverwaltung. Alice richtet eine Kennung ohne Administratorrechte ein, die sie zur normalen Arbeit verwendet, um einem Angreifer, der durch eine Lücke im Browser oder PDF-Viewer eindringt, nicht sofort vollen Zugriff auf ihren PC zu gewähren. Vor allem bei Online-Diensten sichert sie alle Kennungen mit guten Passwörtern – ↑„hallo“, „ficken“, „passwort“ und „qwertz“ gehören nicht dazu. Alice hat übrigens kein Problem damit, kryptische Passwörter auf Papier aufzuschreiben, da sie sich in erster Linie vor Online-Angreifern schützen will.

Es gibt verschiedene Vorgehensweisen, um gute und trotzdem merkbare Passwörter zu generieren, etwa basierend auf einem ↑zufälligen Master-Passwort, das Sie für jeden Dienst nach einem nur Ihnen bekannten Schema modifizieren, oder ↑Schneiers Schema basierend auf den Anfangsbuchstaben und Satzzeichen einer Phrase, die Sie nie vergessen werden.

Falls ein Dienst dies unterstützt, können Sie den Schutz von Passwörtern natürlich durch ↑Zwei-Faktor-Authentifizierung erhöhen, wozu neben einem Passwort ein zweiter Faktor genutzt wird. (Wir alle nutzen Zwei-Faktor-Authentifizierung beim Geldabheben mit EC-Karte – die PIN-Nummer entspricht einem Passwort, das nur in Kombination mit dem zweiten Faktor, der EC-Karte, verwendet werden kann.) Verschiedene Web-Dienste unterstützen Zwei-Faktor-Authentifizierung in Form von Passwort und SMS-Versand. Wenn ein Dienst-Anbieter Ihre Handy-Nummer schon kennt, können Sie durch Zwei-Faktor-Authentifizierung nur gewinnen.

Alice und Bob verwenden übrigens keine Passwort-Manager, deren Sicherheit sie nicht verstehen. Im ↑März und April 2017 wurden beispielsweise mehrere Sicherheitslücken im Passwort-Manager LastPass gefunden. Weiter oben erwähnte ich bereits, dass das Aufschreiben von Passwörtern keine schlechte Idee ist. Von ↑Krypto-Guru Martin Hellman gibt es dazu das überlegenswerte Zitat: „↑Write down your password. Your wallet is a lot more secure than your computer.“ (Schreib dein Passwort auf. Deine Brieftasche ist viel sicherer als dein Computer.) Auch der IT-Sicherheitsexperte ↑Bruce Schneier hält das für einen guten Ratschlag.

Allerdings gibt es auch namhafte Experten, die Passwort-Manager empfehlen. ↑Bruce Schneier gehört auch hier dazu :)

WPA2. Wenn Alice zu Hause WLAN einrichtet, dann neben dem offenen ↑Freifunk nur mit dem Verschlüsselungsmechanismus WPA2. Sie schaltet dabei das ↑völlig unsichere WPS ab.

Festplattenverschlüsselung (optional). Die Festplatten, USB-Sticks, Notebooks, die Alice auf Reisen mitnimmt, verschlüsselt sie unter Einsatz der Bordmittel ihres Betriebssystems oder↑loop-aes.

Ich meine das ernst: Wer den eigenen PC nicht vernünftig absichert, braucht sich keine Gedanken über Anonymisierungstechniken zu machen.

Verschlüsselte Verbindungen mit SSL/TLS – asymmetrische Kryptographie

Verschlüsselung ist ein uralter Ansatz, um die ↑Vertraulichkeit von Nachrichten zu gewährleisten, also den Nachrichteninhalt vor Außenstehenden zu verbergen. Heutzutage stellt die ↑Kryptographie vielfältige Techniken zur Verfügung, um die Vertraulichkeit und auch die ↑Integrität (Nachweis unbefugter Modifikationen) von Nachrichten und Dateien sicherzustellen und gehört daher zu den Grundtechniken der digitalen Selbstverteidigung.

Gängige kryptographische Techniken werden durch offene, standardisierte Protokolle beschrieben, und zu den wohl am häufigsten (weil auch unbewusst) benutzten Protokollen gehören SSL und das Nachfolgeprotokoll ↑TLS. ↑SSL wird spätestens seit Juni 2015 als unsicher angesehen, weshalb nur noch TLS eingesetzt werden sollte; da der Name SSL aber weit verbreitet ist, schreibe ich im Folgenden „SSL/TLS“. Beide Protokolle haben das Ziel, z. B. beim Online-Banking und -Shopping Ihre Kontodaten zu sichern, wenn die Adresse im Browser mit https:// beginnt, wobei das unscheinbare „s“ hinter „http“ für „Sicherheit“ steht. Wann immer Sie eine Web-Seite mit https:// (statt http://) abrufen, kommt das durch SSL/TLS abgesicherte ↑HTTPS zum Einsatz (statt des ungeschützten HTTP) und verspricht (ohne Garantie, wie ich nachfolgend erläutere) Vertraulichkeit und Integrität: Die Kommunikation zwischen Browser und Web-Server ist verschlüsselt und sollte für Dritte daher aussehen wie eine zufällige, unverständliche Zeichenfolge; darüber hinaus sollten beide bemerken können, wenn Dritte Daten modifizieren (z. B. die Kontonummer des Empfängers einer Überweisung).

Wichtig für Alice und Bob sind neben HTTPS insbesondere POPS und IMAPS zum gesicherten Abruf ihrer E-Mails im ↑Thunderbird und SMTPS zum gesicherten Versand.

Im Wesentlichen soll der Schutz von SSL/TLS automatisch funktionieren. Ganz so einfach ist es aber nicht.

Wenn Alice und Bob SSL/TLS einsetzten, werden die Daten verschlüsselt. So weit so gut. Es bestehen aber folgende Kernprobleme:

  1. Alice und Bob wissen nicht, für wen die Daten verschlüsselt werden. Sie hoffen zwar, dass die Daten für den beabsichtigten Empfänger verschlüsselt werden (z. B. für den Web-Server). Sie haben aber kaum eine Möglichkeit nachzuprüfen, ob sie einem ↑Man-in-the-Middle-Angriff zum Opfer fallen.

    Weiter unten begründe ich diese Sichtweise.

  2. Selbst wenn kein Man-in-the-Middle-Angriff vorliegt, wissen Alice und Bob nicht, wer außer dem beabsichtigten Empfänger die Kommunikation noch entschlüsseln kann:

    • Browser und Web-Server handeln untereinander aus, welche kryptographischen Verfahren genau eingesetzt werden. Es könnte sein, dass die ausgehandelten Verfahren wirkungslos sind und daher gar keinen Schutz bieten.

      Sie können wirkungslos sein, weil sie

      • beabsichtigt mit einer Hintertür entworfen worden sind,
      • mit einer Hintertür implementiert worden sind (obwohl das Verfahren an sich sicher ist)
      • oder weil sie von Anfang an unsicher waren, was erst später bemerkt wurde, aber seitdem nicht publiziert worden ist.

      Diese drei Aussagen ergeben sich im Wesentlichen aus ↑Snowden-Dokumenten, die im September 2013 publik wurden.

    • Zur Verschlüsselung werden Zufallszahlen benötigt. So wie ein Zahlenschloss mit wenigen (sagen wir 42) möglichen Kombinationen keinen Schutz bietet, bietet Verschlüsselung ohne zufällige „Zufalls“zahlen keinen Schutz. (Beide scheinen bei oberflächlicher Betrachtung zu wirken; einem ernsthaften Angriff können sie aber nicht standhalten.) Die Erzeugung von „Zufalls“zahlen ist extrem schwierig. Einerseits werden dabei ↑immerwiederFehler gemacht, zum anderen werden offenbar ↑Verfahren mit Hintertür standardisiert.
    • Es könnte sein, dass ein als Empfänger oder als Kommunikationsdienste anbietendes Unternehmen gesetzlich verpflichtet worden ist, Ver- und Entschlüsselungsschlüssel bei Behörden zu hinterlegen. Und zwar ohne die Gesprächspartner informieren zu dürfen. Unternehmen in demokratischen Staaten. Höchst schockierend, erstaunlich und bemerkenswert.

      Wenige Dienstbetreiber wie Ladar Levison, der Gründer der Firma Lavabit für verschlüsselte E-Mail-Kommunikation, ↑schließen dann lieber ihr Unternehmen, als dass sie ihre Kunden hintergehen würden. Offenbar müssen sämtliche US-Unternehmen ihre Kunden derart ausspionieren. Levison rät davon ab, private Daten US-basierten Unternehmen anzuvertrauen. (↑„I would strongly recommend against anyone trusting their private data to a company with physical ties to the United States.“)

Sind Sie noch da, oder sind Sie hintenübergefallen?

Um es ganz klar zu sagen: Wir wissen nicht, welche Verfahren sicher sind. Zumindest die NSA kennt selbst entdeckte, selbst eingebaute und in ihrem Auftrag eingebaute Hintertüren. Das ist Wahnsinn und geht über mein Thema, informationelle Selbstbestimmung, weit hinaus. Ich möchte mir lieber nicht vorstellen, was alles durch SSL/TLS „geschützt“ wird, von Finanztransaktionen bis zur Steuerung von Anlagen in Industrie und Infrastruktur. Kann irgendeine Organisation mit so viel Macht verantwortungsbewusst umgehen? Was passiert, wenn dieses Wissen in weitere Hände gerät?

Der zutiefst beunruhigende Roman ↑Blackout von Marc Elsberg zeigt am Beispiel der Stromversorgung, welche Horrorszenarien auf uns zukommen werden, wenn Sicherheitslücken und Hintertüren in kritischen Infrastrukturen für gezielte Angriffe ausgenutzt werden.

Ich schweife ab. Zurück zu obigen Kernproblemen. Alice und Bob können erklären, was Man-in-the-Middle-Angriffe sind. Im Normalfall nutzen sie Anonymisierungstechniken wie Tor nur für normales Surfen, wo sie keine Passwörter eingeben müssen. Wenn sie die Nutzung von Diensten anonymisieren wollen, die die Übertragung von Passwörtern erfordern, dann setzen sie Mechanismen ein, die sie vor Man-in-the-Middle-Angriffen schützen, etwa das unten erwähnte Certificate Patrol als Browser-Erweiterung oder ↑manuelles Certificate Pinning, was über die nachfolgenden Erläuterungen hinausgeht.

Asymmetrische Kryptographie

Asymmetrische Kryptographie stellt eine Grundlage vieler Sicherheitsmechanismen im Internet dar, unter anderem von SSL/TLS und auch vom später besprochenen GnuPG zur E-Mail-Verschlüsselung. Zudem beinhaltet Ihr Personalausweis eine Smartcard, die asymmetrische Verfahren implementiert. Insofern gehört das Folgende zur Allgemeinbildung.

Durch Verschlüsselung werden Nachrichten unter Verwendung eines sogenannten Schlüssels in unverständliche, zufällig aussehende Zeichenketten verwandelt. Bei symmetrischen Verfahren setzen Sender und Empfänger denselben Schlüssel für Ver- und Entschlüsselung ein. Demgegenüber muss die Empfängerin (sic!) bei asymmetrischer Verschlüsselung ein Schlüsselpaar besitzen. Ein Schlüsselpaar besteht aus einem geheimen (oder privaten) und einem öffentlichen Schlüssel. Wie die Namen schon andeuten, muss die Besitzerin gut auf den geheimen Schlüssel aufpassen, so dass dieser nie in fremde Hände gerät, während der öffentliche Schlüssel weitergegeben wird.

Wenn Bob einen öffentlichen Schlüssel von Alice erhalten hat, kann er mit diesem Nachrichten an Alice verschlüsseln. Nur sie (also nicht einmal Bob) kann diese Nachrichten dann entschlüsseln, und zwar benötigt sie dazu ihren geheimen Schlüssel. Der öffentliche Schlüssel entspricht in etwa einem geöffneten Tresor mit Zahlenkombination: Jede/r kann Nachrichten hineinlegen und den Tresor verschließen. Geöffnet werden kann der Tresor jedoch nur von Personen, die die Zahlenkombination (also den geheimen Schlüssel) kennen.

Bei Verwendung von HTTPS im Web sendet der Server zuerst seinen öffentlichen Schlüssel. Bobs Browser kann seine Daten dann mit diesem öffentlichen Schlüssel verschlüsseln. (Die Details sind komplex und beruhen auf ↑hybriden Verfahren, spielen hier aber keine Rolle.) Eine im Web kaum zu überwindende Herausforderung besteht nun darin sicherzustellen, dass ein öffentlicher Schlüssel dem „richtigen“ Empfänger gehört. Andernfalls könnte Bob seine Nachrichten in einen Tresor legen, der zwar mit „Alice“ beschriftet ist, der aber von ihrem Ex (der Mallory heißt) aufgestellt worden ist …

Der Ex Mallory wäre dann ein Man-in-the-Middle: Er entnimmt die Nachrichten von Bob an Alice aus dem von ihm aufgestellten Tresor und hat freie Hand, sie zu lesen oder zu ändern. Dann legt er die (möglicherweise geänderten) Nachrichten in den echten Tresor von Alice. Weder Alice noch Bob würden dies bemerken.

Digitale Zertifikate, Zertifizierungsstellen und Vertrauen

Um der gerade skizzierten Gefahr zu begegnen, einem Man-in-the-Middle zum Opfer zu fallen, werden ↑Public-Key-Infrastrukturen (PKI) genutzt. Hier behaupten Zertifizierungsstellen durch ↑digitale Signaturen (welche wiederum mittels asymmetrischer Verfahren erzeugt werden), dass ein öffentlicher Schlüssel wirklich zu einem bestimmten Empfänger gehört. (Beim Tresor entspräche eine fälschungsresistente ↑Plombe am Namensschild einer digitalen Signatur.)

Ein digital signierter öffentlicher Schlüssel wird als ↑digitales Zertifikat bezeichnet, und statt eines einfachen öffentlichen Schlüssels (wie oben vereinfachend dargestellt) sendet ein Web-Server zuerst sein digitales Zertifikat an Bob. Bobs Browser muss dann überprüfen, ob die digitale Signatur dieses Zertifikats gültig ist und von einer „vertrauenswürdigen“ Zertifizierungsstelle stammt. Wie dies im Detail funktioniert, spielt hier keine Rolle. Wichtig ist, dass der Browser nach erfolgreicher Prüfung davon ausgeht, dass der öffentliche Schlüssel des Zertifikats wirklich zum sendenden Web-Server gehört.

Alice’ Ex Mallory hat nun noch (mindestens) zwei Möglichkeiten, um trotzdem erfolgreich als Man-in-the-Middle aufzutreten. Zum einen kann er einfach selbst eine Plombe am Tresor anbringen. Im Web bedeutet dies, dass er selbst ein Zertifikat erstellt, in dem seine eigene digitale Signatur bestätigt, der enthaltene öffentliche Schlüssel (zu dem er auch den geheimen Schlüssel besitzt) gehöre Alice. Offenbar sollte Bob diesem Zertifikat nicht trauen (die Plombe sieht irgendwie komisch aus), und sein Browser wird ihn darauf hinweisen, dass der Aussteller des Zertifikats unbekannt ist. Je nach Browser und Version sieht Bob einen Hinweis der folgenden Art:

Firefox:SSL-Warnung

Nach Aufklappen von „Erweitert“ sieht das je nach Problem evtl. so aus:

Firefox:SSL-Warnung mit Details

Wenn Bob so eine Warnung auf einer Web-Seite sieht, wo er persönliche Daten eingeben soll oder die gar mit Geld zu tun hat (Online-Banking oder -Shopping), bricht er die Verbindung ab. Ansonsten würden seine Daten und sein Geld von einem Man-in-the-Middle gestohlen.

Wenn Bob aber eine Web-Seite ansehen möchte, ohne persönliche Daten oder gar Passwörter einzugeben, ignoriert er solche Warnungen, da er die Web-Seite auch ohne SSL/TLS angesehen hätte. Dass hier mit einer dem Browser unbekannten Partei verschlüsselt wird, schadet sicher nicht.

Außerdem akzeptiert Bob natürlich die Zertifikate, die er für seine eigenen Server selbst erstellt hat, etwa den anderswo erwähnten ownCloud- oder Nextcloud-Server. Es gibt für Bob keinen Grund, diese selbst erstellten Zertifikate von einer dem Browser bekannten Zertifizierungsstelle zertifizieren zu lassen, über die er selbst wenig weiß. Wenn auch seine Familienmitglieder auf diesen Server zugreifen wollen, können sie zunächst nicht erkennen, ob die Warnung auf Bobs unbekannte Signatur oder auf einen Man-in-the-Middle-Angriff zurückzuführen ist. Sie können entweder in ihrem Browser Bob als Zertifizierungsstelle hinzufügen, wobei Bob ihnen hilft, oder Sie müssen Zertifikat-Fingerabdrücke vergleichen. Bob teilt ihnen dazu (z. B. in der verschlüsselten E-Mail, mit der er auch Benutzerkennung und initiales Passwort verschickt) den Fingerabdruck seines Zertifikats mit. Die Familienmitglieder vergleichen diesen dann über „Ausnahmen hinzufügen…“ / „Ansehen…“ / „SHA1-Fingerabdruck“, bevor sie „Sicherheits-Ausnahmeregel bestätigen“ anklicken.

Zurück zu Alice’ Ex Mallory. Sein Versuch, eine eigene Plombe an seinem eigenen Tresor anzubringen, schlägt bei Alice und Bob fehl, da beide genau hinsehen und obige Browser-Warnungen beachten. Seine zweite Möglichkeit besteht darin, eine offizielle Plombe an seinem mit „Alice“ beschrifteten Tresor anbringen zu lassen. Er kennt dafür drei Wege. Erstens kann er in die Computer einer anerkannten Zertifizierungsstelle einbrechen und sich dort selbst ein offizielles Zertifikat erstellen. So etwas ist in großem Stil ↑im März 2011 bei Comodo geschehen und auch in 2011 ↑für DigiNotar bekannt geworden. Im ↑Juli 2016 wurde ein weiterer haarsträubender Fall bei Comodo entdeckt. Wie oft derartiges unbemerkt vorkommt, ist natürlich unbekannt.

Zweitens kann Mallory auch ganz offiziell eine Zertifizierungsstelle um das Ausstellen eines Zertifikats bitten, wiederum mit einigen Varianten. (a) Vielleicht kennt er eine Zertifizierungsstelle, die nicht richtig prüft, was sie da zertifiziert. Diese übersieht dann, dass sie einen Tresor mit Namen „Alice“ für jemanden verplombt, der nicht Alice ist. So etwas kommt ↑immer (2001, VeriSign)mal (2006, GeoTrust)wieder (Comodo, Symantec, 2015) und ↑wieder (WoSign, 2016) und ↑wieder (Comodo, 2016) und ↑wieder (Symantec, 2017) vor.

(b) Es gibt Zertifizierungsstellen ↑wie Trustwave, die Schnüffel-Zertifikate dreist verkaufen (2012). Und es gibt Zertifizierungsstellen ↑wie Thawte, die „interne Test-Zertifikate“ ausstellen, die dann doch für andere Zwecke missbraucht werden (2015). Man glaubt es nicht, ist aber so.

(c) Mallory kann, wenn er mächtig genug ist, auch eine eigene Zertifizierungsstelle betreiben. Die Hintergründe sind zwar nicht bekannt, aber für mich sehen die „Fälle“ ↑ANSSI (2013), ↑NIC of India (2014) und ↑CNNIC (2015) nach staatlicher Spionage aus.

Drittens kann Mallory eine inoffizielle Zertifizierungsstelle betreiben und deren Wurzelzertifikat auf Rechnern installieren, in die er eingebrochen ist. Es gibt ↑Online-Banking-Trojaner (2014), die so vorgehen.

Es gibt auch PC-Hersteller, die ihre Geräte mit vorinstallierten Spionagewurzelzertifikaten ausliefern wie ↑Dell (2015) und ↑Lenovo (2015).

Schauen Sie einfach mal in Ihrem Browser nach, welchen Zertifizierungsstellen der so „vertraut“. Im Firefox wählen Sie dazu das Menü „Bearbeiten“ / „Einstellungen“ / „Erweitert“ / „Zertifikate“ / „Zertifikate anzeigen“ / „Zertifizierungsstellen“; nur sechs läppische Klicks, fast direkt zu sehen. Scrollen Sie mal drüber, wen Sie da kennen, dem Ihr Browser „vertraut“. Wem trauen Sie (ohne Anführungszeichen, im wörtlichen Sinne)? Alternativ schauen Sie sich doch diese ↑„übersichtliche“ Darstellung von ca. 650 Zertifizierungsstellen und deren „Vertrauens“beziehungen an. Eine Legende finden Sie auf der Seite des ↑SSL Observatory.

Wenn Mallory nur eine einzige Zertifizierungsstelle überredet, zwingt, bezahlt oder betreibt, erzeugt diese eine Plombe für den Tresor mit Namen „Alice“, ohne dass der Browser eine Warnung anzeigen würde.

Eine einzige Zertifizierungsstelle genügt ihm.

Es reicht, das schwächste Glied der Kette aufzubrechen.

Um es auf den Punkt zu bringen: Das „Vertrauensmodell“ von SSL/TLS ist kaputt. Im Jargon ist wohl „FUBAR“ der treffende Begriff. ↑metageren, ↑ixquicken, ↑unbubblen oder ↑startpagen Sie das. Alice und Bob wissen nicht, warum eine Zertifizierungsstelle welches Zertifikat für wen ausgestellt hat. Nach eingehender Prüfung für ihre Bank? Oder nach Einbruch eines Kriminellen im Namen der Bank für sich selbst? Oder für einen Kriminellen nach Bestechung? Oder für eine Regierung im Namen der Terrorabwehr? Alice und Bob wissen auch nicht, warum welcher Browser welcher Zertifizierungsstelle „vertraut“.

(Hoffnung auf Besserung liegt im experimentellen Internet-Protokoll ↑Certificate Transparency. Grob gesprochen sollen hier öffentliche, verifizierbare Logbücher sämtlicher Zertifikate geführt werden. Wenn eine Zertifizierungsstelle dann plötzlich anfängt, Zertifikate für Domänen auszustellen, für die sie gar nicht zuständig ist, könnte der Browser die Verbindung abbrechen. Im ↑Oktober 2015 erhielt Certificate Transparency einen neuen Schub durch Google. ↑Seit September 2016 unterstützt Firefox diesen Ansatz, ↑Certificate Transparency wird anfänglich jedoch noch ausgeschaltet sein.)

Um einen Man-in-the-Middle-Angriff durchzuführen, fehlt noch ein Detail. Mallory muss die Briefe von Bob zu seinem gefälschten Tresor locken. Im Internet bedeutet dies, dass Bobs Kommunikation durch einen von Mallory kontrollierten Rechner fließen muss, damit er Bob ein fingiertes Zertifikat unterschieben kann, so dass Bob die Kommunikation an Mallory verschlüsselt, ohne dies zu merken. Mallory liest und ändert die Kommunikation dann nach Belieben, bevor er sie erneut verschlüsselt in Bobs Namen an das eigentliche Ziel weiterleitet.

Mallory hat gute Karten, wenn er (↑WLAN- oder ↑„echte“) Router oder ↑Internet-Knoten kontrolliert. Außerdem könnte er versuchen, ein für Bob präpariertes WLAN aufzusetzen.

Wenn Bob Anonymisierungsdienste benutzt, ist klar, dass seine Kommunikation über Rechner dieser Dienste abgewickelt wird. Dann würde es sich lohnen, solche Rechner zu kontrollieren oder selbst zu betreiben.

Möglichkeiten in Hülle und Fülle.

Seien Sie so vorsichtig wie Alice und Bob, was die „Sicherheit“ von SSL/TLS betrifft, insbesondere wenn Sie anonymisiert über Tor surfen, wo Mallory ohne vorherige Prüfung Mitbetreiber des Anonymisierungsdienstes werden und so auf einfache Weise Internet-Kommunikation zu sich lenken kann!

Browser-Erweiterungen zu SSL/TLS

Angesichts des katastrophalen Sicherheitszustandes von SSL/TLS gibt es einige Ansätze, die mittels Firefox-Erweiterungen eine Verbesserung anstreben. Sie könnten mit ↑HTTPS Everywhere, ↑Certificate Patrol und ↑Perspectives experimentieren.

HTTPS Everywhere ist eine freie Firefox-Erweiterung, die von der ↑Electronic Frontier Foundation und dem ↑Tor-Projekt entwickelt wird. Sie ist im Tor Browser bereits enthalten.

HTTPS Everywhere beinhaltet folgende zwei zentrale Funktionalitäten. Zum einen können viele Web-Server ihre Inhalte sowohl verschlüsselt per HTTPS als auch unverschlüsselt per HTTP ausliefern. HTTPS Everywhere beinhaltet einen Regelsatz für viele solcher Web-Server, so dass der Browser automatisch die verschlüsselte Verbindung bevorzugt. Wenn Alice zum Beispiel die ungesicherte HTTP-Adresse ↑http://www.bundestag.de/ aufruft, wird sie bei Nutzung von HTTPS Everywhere automatisch auf die gesicherte HTTPS-Adresse ↑https://www.bundestag.de/ umgeleitet.

Zum anderen unterstützt HTTPS Everwhere das ↑SSL-Observatorium der Electronic Frontier Foundation. Dieses Observatorium sammelt SSL/TLS-Zertifikate, die im Web vorkommen. HTTPS Everwhere kann so konfiguriert werden, dass der Browser die ihm präsentierten Zertifikate an das Observatorium schickt; dann soll er ↑in Echtzeit Warnungen geben können, wenn Sicherheitsprobleme mit Web-Seiten erkennt werden, etwa schwache SSL/TLS-Schlüssel. (Bei obigem Man-in-the-Middle-Angriff mit der Deutschen Bank gab es keine weitere Warnung zum Standard-Firefox-Dialog.) Beachten Sie, dass das Observatorium jedes Zertifikat erhält (mit Ausnahme einiger konfigurierbarer Details). Wenn Alice über Tor surft, weiß das Observatorium nur, dass irgendjemand den zugehörigen Web-Server besucht hat, aber nicht wer. Ohne Anonymisierungsdienst sähe das Observatorium dagegen die IP-Adresse von Alice. (Laut ↑Datenschutzerklärung werden die Zertifikate und, abhängig von Konfigurationseinstellungen, das autonome System von Alice gespeichert; die IP-Adresse wird nicht erwähnt.)

Alternativen oder Ergänzungen zu HTTPS Everywhere sind ↑Certificate Patrol und ↑Perspectives. Certificate Patrol kann als ↑reguläres Add-On installiert werden. Diese Erweiterung merkt sich, welche Zertifikate sie für welche Web-Server gesehen hat, und warnt, wenn sich ein Zertifikat ändert. Da Zertifikate ein Ablaufdatum besitzen, sind gelegentliche Warnungen zu erwarten, und Certificate Patrol gibt unterschiedliche Warnungen aus, je nach Art der Änderung. Beim Wechsel einer Zertifizierungsstelle wird eindringlicher gewarnt als beim Austausch eines Zertifikats mit abgelaufener Gültigkeit. Beachten Sie, dass beim ersten Besuch einer Web-Seite das Zertifikat nur gespeichert, aber noch gegen keine Vergleichsdaten geprüft werden kann, was als „Trust on first use“ („Vertrauen basierend auf erster Nutzung“) bezeichnet wird. Dies bedeutet, dass Certificate Patrol keine Verbesserung darstellt, wenn Mallory schon einen erfolgreichen Man-in-the-Middle-Angriff auf Alice durchführt, bevor sie Certificate Patrol installiert. Dann sieht Certificate Patrol immer nur das Man-in-the-Middle-Zertifikat von Mallory und kann vor keinen Änderungen warnen. Absolute Sicherheit gibt es nicht.

Perspectives zielt auf eine grundlegende Änderung der Vertrauensstruktur im Zusammenhang mit Zertifikaten. Sie basieren auf der Idee, (ähnlich wie beim SSL-Observatorium) die von Browsern empfangenen Zertifikate zu sammeln und dann in Echtzeit zu warnen, wenn das dem Browser präsentierte Zertifikat vom Normalfall abweicht. Perspectives wird im Browser durch ein ↑reguläres Firefox-Add-On implementiert. Es basiert auf einem Netz von Notar-Servern, welche die Zertifikate der Perspectives-Browser speichern und durch Mehrheitsentscheidungen die „Vertrauenswürdigkeit“ einzelner Zertifikate bestimmen. Alice und Bob können ↑eigene Notar-Server betreiben und auch konfigurieren, welche Notar-Server für die Mehrheitsentscheidungen herangezogen werden sollen.

Anonymisierende Proxies: Chaum, JAP/JonDo und Tor

Der Internet-Provider von Alice ist in der Lage, ihre gesamte Kommunikation zu überwachen, und ihre Kommunikationsdaten weiterzugeben. Selbst wenn sie möglichst oft ihre Daten mit SSL/TLS absichert, sieht er immer noch, welche Dienste sie wie oft in Anspruch nimmt. Um dies zu verhindern, also weitgehend unbeobachtet oder gar anonym zu surfen und zu kommunizieren, muss Alice weiterentwickelte Techniken der digitalen Selbstverteidigung anwenden, mit deren Hilfe sie verbirgt, mit wem sie kommuniziert.

Ein einfaches, aber auch ungenügendes Verfahren besteht in der Konfiguration einer einzelnen anonymisierenden Zwischenstation, ↑Proxy oder Mix genannt (technisch evtl. auch ein VPN-Server), dem Alice ihre Kommunikationsdaten verschlüsselt zusendet, damit dieser sie an den eigentlichen Adressaten weiterleitet und dessen Antworten verschlüsselt an sie zurücksendet. Der Internet-Provider sieht dann nur noch Alice’ verschlüsselte Kommunikation mit dem Proxy. Dieses Verfahren ist ungenügend, weil nun anstelle des Internet-Providers der Proxy vollständiges Wissen über Alice’ Kommunikation erlangt. Was er mit diesem Wissen macht, ist nicht klar. Löschen oder Verkaufen sind zwei Extreme, und in Zeiten des Überwachungskapitalismus drängt sich eine Alternative auf …

Insbesondere rate ich von der Anonymisierung (!) über ↑VPN-Proxies ab. VPNs sind nützlich, um aus wenig vertrauenswürdigen oder zensierten Netzen eine gesicherte Verbindung in ein anderes Netz aufzubauen. Für Anonymisierung sind sie aber ungeeignet. Zusätzlich zum bereits genannten Aspekt, dass mit dem Proxy eine in der Regel nicht vertrauenswürdige Partei vollständiges Wissen über Alice’ Kommunikation erlangt, heißt es in einer ↑vom Guardian veröffentlichten XKEYSCORE-Präsentation aus dem Jahre 2008, auf Seite 17: „Zeige mir die Daten aller VPN-Startups aus Land X und gib mir die Daten, damit ich sie entschlüsseln und die Benutzer aufdecken kann. Diese Ereignisse können in XKEYSCORE einfach durchgeblättert werden.“

Letztlich geht es bei VPN-Proxies primär um die „Umleitung“ des Netzwerkverkehrs. Weitergehende Anonymisierungsüberlegungen, etwa zum Schutz vor Fingerprinting, stehen in der Regel nicht im Fokus.

Die Kernidee echter Anonymisierungsdienste besteht darin, Nachrichten aufgeteilt in mehrfach verschlüsselte Pakete gleicher Größe über eine Kette mehrerer Proxies, idealerweise zeitlich verzögert und umgeordnet, zum eigentlichen Kommunikationspartner weiterzuleiten. Die Beobachtung von Alice’ Kommunikation wird dann nur zeigen, dass ihre Kommunikation verschlüsselt mit einem von ihr gewählten Proxy stattfindet, vorzugsweise im nichteuropäischen Ausland: der eigentliche Adressat bleibt verborgen. Die wegweisende Grundlagenarbeit dieser Verfahren ist bereits 1981 von David Chaum unter dem Titel ↑„Untraceable electronic mail, return addresses, and digital pseudonyms“ veröffentlicht worden.

Heute existieren für E-Mail, Web, Tauschbörsen und allgemeine TCP/IP-Verbindungen frei verfügbare und einfach zu benutzende Software-Lösungen, die einen gewissen Grad von Anonymität basierend auf Netzen von Proxy-Servern bieten. Im Folgenden gehe ich auf ↑JAP/↑JonDo und ↑Tor zum anonymisierten Web-Surfen ein. Bei diesen Verfahren bleibt zumindest dem Internet-Provider verborgen, mit wem Alice kommuniziert, und der Gesprächspartner (z. B. der Suchmaschinenbetreiber im Internet) erfährt nicht, dass es Alice ist, mit der er kommuniziert (aus seiner Sicht findet die Kommunikation mit dem letzten Proxy statt). Darüber hinaus gibt es keine einzelne Stelle mehr, der Alice ihre gesamte Kommunikation anvertrauen müsste.

Grob gesagt funktionieren diese Verfahren wie folgt, wenn Alice anonym surfen möchte, ihr Browser also eine anonymisierte Internet-Verbindung zum Server Sara aufbauen soll: Die Daten, die der Browser eigentlich an Sara schicken soll, werden mehrfach verschlüsselt in ein Anonymisierungsnetz geleitet und dort zunächst im Zickzack hin und her geschickt, wobei die mehrfache Verschlüsselung Schritt für Schritt aufgehoben wird. Bei der letzten Station im Anonymisierungsnetz, nennen wir sie Max, liegen dann wieder die Daten vor, die Alice an Sara schicken wollte, allerdings ohne die IP-Adresse von Alice. Max weiß nichts von Alice, sondern kennt nur die vorletzte Station im Anonymisierungsnetz. Er baut nun eine Verbindung zu Sara auf und führt die Kommunikation an Alice’ Stelle. Er sieht dabei sämtliche zwischen Alice und Sara ausgetauschten Daten – es sei denn, Alice wählt eine verschlüsselte Verbindung mit Sara (z. B. HTTPS, IMAPS); dann sieht Max nur unverständliches Wirrwarr. Die empfangenen Daten gehen zurück durch das Anonymisierungsnetz, wobei sie Schritt für Schritt verschlüsselt werden. Alice entschlüsselt am Ende wieder alles.

Beachten Sie: Alice’ Kommunikation wird also stellvertretend von einem anderen Rechner irgendwo im Internet geführt. Im Wesentlichen wird dabei die IP-Adresse von Alice durch die von Max ersetzt, ohne dass Max irgendetwas von Alice wissen müsste, wodurch eine Anonymisierung erreicht wird. Wenn Alice sich in ihren Daten selbst identifiziert, macht sie die Anonymisierung dadurch natürlich zunichte. (Z. B. wenn sie in einem Web-Formular ihren Namen oder ihre E-Mail-Adresse eingibt. Oder wenn ihr Browser Cookies verschickt, die ohne Anonymisierung gesetzt wurden. Oder wenn sie ↑unsinnigerweise einen Bittorrent-Client verwendet, der ihre eigene IP-Adresse als Teil der Daten durch das Anonymisierungsnetz sendet.)

Wie im Grundlagenabschnitt zu Fingerabdrücken dargestellt, ist die IP-Adresse nur ein identifizierendes Merkmal unter vielen. Damit Alice beim Surfen nicht trotz anonymisierter IP-Adresse durch Fingerprinting-Techniken identifiziert wird, darf sich ihre Browser-Konfiguration nicht zu sehr von der anderer anonymisierter Surfer unterscheiden. Dies kann nur funktionieren, wenn sie einen speziell vorbereiteten Browser wie Tor Browser benutzt und dessen Konfiguration nur im empfohlenen Rahmen verändert.

Jedes dieser Anonymisierungsprojekte befindet sich in der Entwicklung. Keines dieser Projekte behauptet von sich, Anonymität zu garantieren. Auch ich behaupte das nicht! Ich halte es aber für besser, ein Verfahren in Entwicklung einzusetzen, das bekannte (z. B. ↑Angriffe auf JAP und ↑Angriffe auf Tor) und unbekannte Schwachstellen hat, als gar nichts zu tun.

Insbesondere beabsichtigen diese Projekte nicht, vor sogenannten globalen passiven Angreifern (engl. global passive adversaries) zu schützen. Eine Angreiferin ist passiv, wenn sie Internet-Kommunikation lediglich beobachtet, aber nicht aktiv manipuliert. Sie ist global, wenn sie die Internet-Kommunikation nahezu überall beobachten kann. Zumindest Geheimdienste wie NSA und GHCQ dürfen als globale Angreifer betrachtet werden; vermutlich beobachten sie nicht nur passiv, sondern kontrollieren auch „anonymisierende“ Zwischenstationen. Insofern verspricht keines der hier vorgestellten Projekte Schutz im Rahmen der ↑Überwachungs- und Spionageaffäre.

Globale passive Angreifer können das durch ↑JAP/↑JonDo und ↑Tor „anonymisierte“ Surfen von Alice auf dem Web-Server Sara wie folgt de-anonymisieren: Sie beobachten die (verschlüsselte und daher unverständliche) Kommunikation zwischen Alice und der ersten von ihr (oder ihrer Software) gewählten Zwischenstation, ebenso wie die Kommunikation zwischen der letzten Zwischenstation und dem Ziel-Server Sara. Da jede Kommunikation bestimmte Muster aufweist (z. B. umfasst jede Web-Seite andere Anzahlen und Größen an Bildern, Stylesheets und Skripten, die in einer bestimmten Reihenfolge übertragen werden), kann die globale passive Angreiferin versuchen, die bei Alice und bei Sara auftretenden Kommunikationsmuster miteinander zu korrelieren (obwohl zumindest diejenigen bei Alice verschlüsselt sind). Es ist unklar, wie schwierig diese Korrelationsaufgabe wirklich ist. Alice und Bob gehen davon aus, dass Geheimdienste anonymisierte Kommunikation besonders interessant finden und daher speichern und mit dem Ziel der De-Anonymisierung analysieren (was durch aktive Angriffe vereinfacht wird, wenn ihre Kommunikation über kompromittierte Zwischenstationen abgewickelt wird).

Ich mache mir zudem Gedanken, dass manche meiner Daten durch Anonymisierung erst in von ausländischen Geheimdiensten kontrollierte Gebiete „umgeleitet“ werden. In solchen Fällen würde ich diesen Geheimdiensten durch meine Anonymisierungsbemühungen den Zugriff auf meine Daten ermöglichen. Sowohl im JonDonym-Forum (wo der Beitrag nicht mehr zu existieren scheint) als auch auf der ↑Tor-Talk-Mailingliste habe ich im Sommer 2013 entsprechende Diskussionen angestoßen. Kurz gesagt ↑empfehle ich (und das ist eine Minderheiten-, wenn nicht Einzelmeinung), eine „nahegelegene“ erste Zwischenstation auszuwählen. So eine Wahl reduziert die Gefahr, dass meine Kommunikation mit dieser Zwischenstation durch feindliches Gebiet verläuft und dort von Geheimdiensten gespeichert und analysiert wird. Wenn in Ihrer Firma z. B. ein Tor-Server betrieben wird, sollten Sie diesen als Entry-Guard konfigurieren. Wenn in Ihrer Firma kein Tor-Server betrieben wird, beantragen Sie doch einen. Das ↑Aufsetzen ist denkbar einfach.

Bob weist dringend darauf hin, dass bei Einsatz eines Anonymisierungsverfahrens die eigenen Daten über zusätzliche Zwischenstationen von Betreibern mit unbekannten Motiven geleitet werden. Insbesondere im Falle von ↑Tor ist bekannt, dass es Betreiber mit kriminellen Absichten gibt, die versuchen, Kommunikation zu belauschen, Klartext-Passwörter abzufangen, Man-In-The-Middle-Angriffe auszuführen usw. Zudem wird das Surfen über mehrere Zwischenstationen durch Erhöhung von Latenzzeiten und Verminderung von Bandbreite natürlich langsamer …

Magie? Fehlanzeige … Ich warne nachdrücklich, dass es gängige Internet-Protokolle gibt, die niemand verwenden sollte. Erst recht niemand mit Sorge um informationelle Selbstbestimmung. Und überhaupt niemand, der ein Anonymisierungsverfahren einsetzt. Dies sind insbesondere POP und IMAP zum Lesen von E-Mail, NNTP zum Lesen von News-Beiträgen und, falls eine Authentifizierung erforderlich ist, auch HTTP beim Web-Surfen sowie FTP zum Dateitransfer. Bei all diesen Protokollen werden sämtliche Daten im Klartext übertragen, insbesondere Benutzerkennung und Passwort. Das bedeutet, dass alle Rechner, z. B. beteiligte Router, auf dem Weg vom eigenen Rechner bis zum Zielserver sämtliche Nachrichten mitlesen (auch nach Belieben unbemerkbar manipulieren) und dabei Passwörter ausfiltern können. Nach einmaligem Login darf man seine Kennung als kompromittiert ansehen. Vor dieser Gefahr schützt auch keines der im Folgenden beschriebenen Anonymisierungsverfahren. Das Gegenteil ist der Fall: Bei Verwendung der folgenden Verfahren werden die eigenen Daten über zusätzliche Wege und Zwischenstationen, die von unbekannten Parteien mit unbekannten Motiven kontrolliert werden, weitergeleitet. Es sollte klar sein, dass die eigenen Daten dabei auch in die dunkelsten Ecken im Internet geraten werden.

Um sich sicher durch diese dunklen Ecken bewegen zu können, deaktivieren Alice und Bob aktive Inhalte wie Java, JavaScript und Flash, was durch die Firefox-Erweiterung NoScript (wie oben beschrieben) sichergestellt wird (bzw. durch geeignete Konfiguration des Tor Browsers). Zudem vertrauen sie auf starke Kryptographie und verwenden nicht obige Klartextprotokolle, sondern deren durch das oben erläuterte Protokoll SSL/TLS abgesicherten Varianten (POPS, IMAPS, NNTPS, HTTPS, SFTP). (Und sie machen Server-Betreiber, die nur unsichere Klartextvarianten anbieten, aber deren Dienste sie trotzdem für wertvoll halten, darauf aufmerksam, dass Klartextprotokolle keine gute Idee sind. Obwohl Klartextprotokolle Alice und Bob erlauben abzustreiten, etwas mit den unter ihren Kennungen durchgeführten Aktionen zu tun zu haben …)

Lesen Sie obigen Unterabschnitt zu SSL/TLS und dessen Grenzen; insbesondere müssen Sie die Varianten von Man-In-The-Middle-Angriffen mit und ohne Zertifikat-Warnungen kennen.

Wenn Alice und Bob eines der folgenden Anonymisierungsverfahren verwenden, sind sie bei Zertifikat-Warnungen besonders vorsichtig, weil dann insbesondere die letzte zur Anonymisierung gedachte Zwischenstation von einem Angreifer betrieben werde könnte, der Kennungen/Passwörter/PIN/TAN trotz SSL/TLS-Verschlüsselung abfängt.

Letzte Änderung dieses Abschnitts: 2017-04-10 17:03:21