Die Podiumsdiskussion mit Hans-Christian Ströbele und Prof. Dr. Michael Dreyer wurde von Campus TV aufgezeichnet. Mittlerweile ist das Video bei YouTube verfügbar. Die Audioqualität ist verbesserungswürdig. Dennoch viel Spass beim Anhören und -sehen!
Die Räume der Friedrich-Schiller-Universität Jena hatte heute zu ungewöhnlicher Zeit ungewöhnliche Gäste. Zur Mittagszeit, wo sonst der Vorlesungsbetrieb in vollem Gange ist, trafen sich verschiedene Politiker, Wissenschaftler und interessiertes Publikum. Die Fraktion von Bündnis90/Grüne hatte zusammen mit der Heinrich-Böll-Stiftung Thüringen, den Politiker Hans-Christian Ströbele und den Politikwissenschaftler Prof. Dr. Michael Dreyer. Beide sollten gemeinsam eine Podiumsdiskussion zum Thema Snowden und NSA bestreiten.
Ströbele erzählte zu Beginn seines Vortrages von seinem Besuch in Moskau bei Edward Snowden. Währenddessen oder kurz danach hatte er sich vorgenommen, den Whistleblower zu unterstützen. Dies sollte zum einen durch die Errichtung eines Untersuchungsausschusses wie auch durch einen Aufenthalt Snowdens in Deutschland passieren.
Der NSA-Untersuchungsausschuss lag zu Beginn der Legislaturperiode in weiter Ferne. Die SPD, die vor der Wahl noch einen anderen Zungenschlag hatte, verlor mit Regierungsbeteiligung das Interesse an Snowden. Interessanterweise war es die CDU, die den Weg zu dem Untersuchungsausschuss ebnete. Ströbele machte hierfür den Druck aus den Reihen der Bevölkerung verantwortlich. Im Verlaufe des Vortrages versuchte er immer wieder klar zu machen, dass politischer Druck »von der Straße« durchaus in die Politik einwirkt. Die Schritte, die dann passieren, sind leider klein, manchmal zu klein.
Mittlerweile wurden erste Juristen im Untersuchungsausschuss angehört. Auch hier erwähnte Ströbele, dass alle drei Juristen einhellig meinten, dass die Überwachung des BND verfassungswidrig ist. Hier gilt es nun, die Gesetze und auch die Arbeit des parlamentarischen Kontrollgremiums anzupassen. Dies soll nach dem Vorbild des United States Senate Select Committee on Intelligence sowie ähnlicher Behörden passieren. Diese haben neben den eigentlichen Gremiumsmitgliedern eine Reihe von unterstützenden Mitarbeitern. Die Mitarbeiter helfen dann beispielsweise bei der Einschätzung technischer Fragen.
Ströbele erwähnte einige Male stolz das Unternehmen Posteo. Das
kümmert sich um gute Verschlüsselung und sitzt in Kreuzberg. Ich war
ja versucht, noch mailbox.org zu erwähnen. Auch das Unternehmen sitzt
in Berlin und verschlüsselt die Daten auf dem Transportweg wie auch in
der Inbox. 
Insgesamt regte Ströbele an, dass sich US-Unternehmen, die Probleme wegen starker Verschlüsselung bekommen haben, in Deutschland ansiedeln.
Zum Abschluss seines Vortrages klebte er einen Ein-Bett-für-Snowden-Aufkleber in den Hörsaal und überließ Prof. Dreyer das Wort.
Dreyer bemühte sich um Gegenrede. Denn nach seinem Bekunden ist ein Podium mit gleichen Meinungen langweilig. Nachdem er einen Werbeblock für diverse andere Veranstaltungen abgespult hatte, fragte er das Publikum, wer denn Jonathan Pollard kenne. Erwartungsgemäß meldete sich (fast) niemand. Pollard gab Dokumente an den israelischen Geheimdienst (oder, wie die offizielle Bezeichnung lautete, das Büro für wissenschaftliche Verbindungen) weiter. Dafür wurde Pollard zu lebenlänglicher Haftstrafe verurteilt. Seit der Verurteilung setzte sich ziemlich jeder israelische Premier bei dem jeweiligen US-Präsident für die Freilassung ein. Bisher waren alle ohne Erfolg. Dreyer nahm dies als Beispiel oder Parallele für ein eventuelles Vorgehen gegen Snowden. Aus meiner Sicht hinkt dieser Vergleich jedoch. Denn Pollards Veröffentlichungen sorgten für die Enttarnung diverser CIA-Agenten und vermutlich sogar für Hinrichtungen einiger Agenten. Das Damage Assessment besteht aus diversen Dateien. Auf der anderen Seite versuchte Snowden Dokumente zu wählen, die niemandem einem Risiko aussetzen und die auch keine legitime nachrichtendienstliche Tätigkeit aufdeckt. Stattdessen versuchte er nur den ungesetzlichen Teil aufzudecken und mit Dokumenten zu belegen. Daher würde ich erwarten und hoffen, dass er im Falle eines Gerichtsverfahrens wenig streng bestraft wird.
Die anderen Argumente Dreyers bezogen sich auf die Auslieferungsabkommen, die Deutschland natürlich einhalten muss. Ströbele wandte ein, dass einerseits die Regierung sich gegen eine Auslieferung aussprechen kann und andererseits die Auslieferung für politische Vergehen verboten ist. Die Bundesregierung wurde angefragt, ob es sich bei Snowden um einen solchen handelt. Daraufhin fragte die Regierung in den USA nach deren Meinung. Das sorgte für einige Lacher im Publikum.
Dreyer schlug weiterhin vor, statt Snowdens lieber Glenn Greenwald oder Laura Poitras einzuladen. Hier stellte sich heraus, dass er diesen Aspekt nicht gut vorbereitet hatte. Denn beide sind bereits eingeladen. Allerdings werden sie wohl keine Aussage machen, sondern als Journalisten Quellen schützen.
Die Empfehlung von Dreyer war, dass sich alle umfassend Gedanken über Vor- und Nachteile machen sollten. Diese Gedanken sollten als Grundlage einer Entscheidung stehen und eventuelle Emotionen sollten zurücktreten.
Insgesamt fand ich die Veranstaltung sehr schön. Gerade dadurch, dass
Prof. Dreyer versuchte, einen Kontrapunkt zu setzen, wurde die
Diskussion interessanter und einige Argumente traten stärker zu
Tage. Ich würde mir mehr solcher Veranstaltungen wünschen.
Stellungnahmen zu Gesetzentwürfen sind üblicherweise große Papierberge. Die Mitglieder der Ausschüsse müssen diese lesen und interpretieren. Die Initiative Freiheitsfoo ist einen anderen Weg gegangen. Sie bekamen eine Anfrage des Wirtschaftsausschusses des Landes Schleswig-Holstein, in der es um die lückenlose Überwachung in Zügen ging. Freiheitsfoo entwickelte ein Hörspiel und stellte es den Abgeordneten zur Verfügung. Es steht mittlerweile allen zur Verfügung. Hört rein: 201402freiheitsfoo-an-LT-SH-zu-VUE-OEPNV.mp
via Patrick Breyer: Videoüberwachung im ÖPNV: Landtag erhält Hörspiel als Stellungnahme
Die operative Hektik angesichts der Heartbleed-Lücke bei OpenSSL legt sich langsam. Ein Großteil der Server scheint gepatcht zu sein und diverse Zeitungen wie andere Medien bringen zur Prime-Time Warnungen an die Nutzer. Jetzt beginnt die Zeit der Spekulation, woher der Bug kommt, ob der absichtlich eingebaut wurde und es wird auch die Frage diskutiert, ob Open Source sicherer bzw. besser als Closed Source ist.
Auf der einen Seite steht u.a. Linus’ Law als Argument. Der Erschaffer von GNU/Linux wird mit dem Spruch »Given enough eyeballs, all bugs are shallow« zitiert. Das heißt, wenn nur genügend Leute einen Blick in den Quellcode werfen, so wird jeder Bug gefunden und am Ende ist die Software »rein«. Am Beispiel des Linuxkernel ist zu sehen, wie gut das Modell funktioniert. Allerdings gibt es eine Reihe von anderer Open-Source-Software, wo offensichtlich niemand einen Blick in den Quellcode wirft. Dort bleiben dann zahlreiche Fehler unentdeckt. Das ist dann auch gleich das Argument der Befürworter von Closed Source. Denn dort bekommt niemand den Code zu sehen und kann daher auch keine Fehler finden. So lautet die etwas vereinfachte Argumentation.
Forscher vom Lehrstuhl für Betriebssysteme der TU Dresden haben sich dieser Frage im Jahr 2010 genähert. Für ihre Veröffentlichung The Mathematics of Obscurity: On the Trustworthiness of Open Source schufen sie ein Modell, in dem verschiedene Personen versuchen, Schwachstellen in Code zu finden. Wenn die Verteidiger zuerst sind, können sie die Lücke schließen. Die Angreifer haben auf der anderen Seite eine Lücke, über die sie ins System eindringen können.
Das Modell widerspricht dem obigen Gesetz von Linus Torvalds. Das Modell erbringt die Aussage, dass die Angreifer bei Open Source immer leicht im Vorteil sind. So nehmen die Forscher an, dass bei einem Open-Source-Projekt die Verteidiger in 6 von 10 Fällen einen Fehler vor dem Angreifer finden. Je nach den weiteren Modellannahmen braucht das Projekt mehr als Tausend oder gar mehr als Zehntausend Mitwirkende. Für den Fall, dass sogar in 9 von 10 Fällen der Fehler von den Verteidigern gefunden wird, können die Forscher zeigen, dass dies unmöglich ist. Alles in allem erscheint Closed-Source-Software besser aufgestellt zu sein.
Jedoch sagen die Forscher weiter, dass sie hier einen eingegrenzten Aspekt betrachten. In der Realität beheben die Hersteller von Closed Source die Fehler nicht sofort. Außerdem gibt es dort wirtschaftlichen Druck, Programme zu einem festen Datum herauszubringen. Dies führt dann dazu, dass die Programme nicht getestet sind. Alldies bringt die Forscher zu der Meinung, dass Open Source in der Gesamtschau vermutlich doch Vorteile mit sich bringt. Letztlich bringt gerade Freie Software die Vier Freiheiten mit.
Alles in allem kann ich nur nochmal den Aufruf aus meinem letzten Eintrag wiederholen. Nutzt Freie Software, schaut in den Quellcode oder versucht anderweitig zu der Software beizutragen. Damit helft ihr allen!
Lest ihr regelmäßig Bugreports oder Meldungen über Schwachstellen bei SSL/TLS? Wie fühlt ihr euch so? Zur Erinnerung:
Das heißt, drei Monate in Folge gab es schwere Sicherheitslücken in Software zur Verschlüsselung. Ganz unwillkürlich fühlt man sich an die Folien aus dem NSA-Programm MUSCULAR erinnert.
Die letztgenannte Schwachstelle ist vermutlich die bislang schwerste. Denn damit ist es möglich, den Arbeitsspeicher eines Computers auszulesen. Dies funktioniert sowohl auf der Seite des Servers wie auch beim Clientprogramm. Dazu ist es notwendig, dass das Programm OpenSSL verwendet und eine Erweiterung von SSL namens Heartbeat aktiviert hat. Dies ist beispielsweise bei Android in der Version 4.1.1 der Fall. Mozilla Firefox hingegen nutzt die NSS-Bibliothek und ist nicht betroffen. Die Webserver nutzen hingegen recht oft die OpenSSL-Bibliothek und sind damit betroffen, falls die Version 1.0.1 bis 1.0.1f von OpenSSL verwendet wird. Sollte jemand von euch die Software nutzen, so upgraded auf mindestens 1.0.1g oder deaktiviert Heartbeat in OpenSSL. Gerade letzteres kann man aus meiner Sicht problemlos tun. Denn bisher fand ich keinen sinnvollen Anwendungsfall für Heartbeat.
Doch wie funktioniert diese Lücke eigentlich? Heartbeat (RFC 6520) ist eine Erweiterung für TLS. Ein Teilnehmer einer Verbindung sendet beliebige Daten an den Empfänger. Dieser antwortet mit einer Kopie dieser Daten und zeigt somit, dass die Verbindung noch steht und alles in Ordnung ist. Das Problem dabei ist, dass in einer Anfrage zwei Längenfelder vorhanden sind. Ein Angreifer sendet einfach ein Byte Daten und behauptet, er hätte 64 kB gesendet. OpenSSL liest nun die 64 kB aus dem eigenen Puffer und sendet die Daten zurück an den Angreifer. Der Angreifer kann den Angriff immer und immer wieder starten und erhält so eventuell immer wieder ein neues Stück Arbeitsspeicher (siehe Kommentar von Florian Diesch). Bruce Schneier hat mit seinen Worten vollkommen recht:
Catastrophic" is the right word. On the scale of 1 to 10, this is an 11.
https://www.schneier.com/blog/archives/2014/04/heartbleed.html
Ich hatte in meinem 30C3-Vortrag schon ein OpenSSL-Beispiel reingenommen. Das sollte zeigen, wie kompliziert es sein kann, mit der Software sicheren Code zu schreiben. Auch andere sind, über die Codequalität gestolpert. Daher sind Leute gefragt, die einen detaillierten Blick auf OpenSSL werfen und die Software verbessern. Dazu zählt auch die bessere Lesbarkeit des Codes oder gute Dokumentation.
Wenn ihr wissen wollt, ob ihr betroffen seit, schaut lokal auf die
OpenSSL-Version, nutzt die Zeile openssl s_client -connect
example.com:443 -tlsextdebug 2>&1| grep ‘server extension
“heartbeat” (id=15)’ || echo safe oder verwendet den Testservice
von Lutz Donnerhacke oder Filippo Valsorda.
Weiterlesen:
Do not login to Yahoo! The OpenSSL bug #heartbleed allows extraction of usernames and plain passwords! pic.twitter.com/OuF3FM10GP
— Mark Loman (@markloman) 8. April 2014
Jetzt ist der Zeitpunkt gekommen, an dem ich meine Anleitung zu sicheren SSL-Einstellungen löschen kann. Der aktuelle Firefox ist in der Version 27 erschienen. Wie angekündigt, unterstützt der Browser nun standardmäßig TLS 1.1 und 1.2. Damit werden die TLS-Einstellungen über about:config hinfällig. Die Seite How’s my SSL zeigt den Firefox mit Standardeinstellungen als Probably OK an. Sogar Seiten mit AES im GCM-Modus werden korrekt verschlüsselt.
In den letzten Beiträgen thematisierte ich die Verschlüsselung von Webseiten. Meine eigene Webseite läuft seit längerer Zeit über SSL/TLS. Das alte Zertifikat lief Ende Januar 2014 aus. Daher war es Zeit für eine Erneuerung. Das neue Zertifikat stammt von CACert. Vermutlich erzeugt das bei vielen eine Warnung im Browser. Daher solltet ihr unbedingt das Root-Zertifikat von CACert importieren. Dann funktionieren auch diese Seiten im Browser.
Mit dem neuen Zertifikat kommt ein neuer Fingerprint: 80:5B:82:22:9C:62:11:69:2E:92:69:9D:60:D1:DD:D3:C3:8C:D1:1A
Durch das fehlende Root-Zertifikat im Browser bewertet SSLLabs die Seite nur noch mit einem F. Bliebe der Fakt unberücksichtigt, würde die Webseite wieder ein A bekommen. "Neues SSL-Zertifikat für kubieziel.de" vollständig lesen
In meinem Beitrag zur sicheren Einstellung von SSL/TLS im Browser fragte ich, ob ihr Seiten bemerkt, die nicht mit TLS 1.1 oder 1.2 funktionieren. In den Kommentaren und bei Twitter meldeten sich einige. Irgendwann entschied ich, eine eigene Webseite hierfür anzulegen. Die Seite SSL/TLS im Browser dokumentiert Seiten, die nur TLS in der Version 1.0 oder schlechter anbieten. Beim Testen fielen mir sogar einige Seiten auf, die auf das komplett unsichere SSL 2 setzen.
Weitere Seiten könnt ihr mir gern melden. Ich habe ein Pad angelegt. Wenn dort ein neuer Domainname auftaucht, teste ich den und nehme den mit in die Seite auf. Git-Nutzer können die Datei SSL-TLS.org bei Github editieren und mir einen Pull-Request schicken.
Die Daten sollen natürlich nicht ungenutzt liegen. Ich möchte in einem zweiten Schritt die Betreiber der Webseiten anschreiben und diese bitten, auf neuere Protokollversionen zu aktualisieren. Hier würde ich mich über eure Hilfe freuen. Bitte schreibt eure Textvorschläge ins Pad. So können wir gemeinsam ein Schreiben entwickeln und das dann in die Welt schicken. Hoffentlich erreichen wir dadurch eine kleine Verbesserung beim Schutz unserer Daten.
mutt ist ein E-Mail-Programm für die Kommandozeile unter GNU/Linux. Das Programm wird über die Tastatur bedient und über eine Textdatei konfiguriert. Wer das innerhalb einer Firma verwendet bzw. auf Rechnern mit mehreren Nutzern, wird vermutlich ein schlechtes Gefühl haben, dort Passwörter zu hinterlassen. Für den Versand von E-Mails bzw. den Zugang zum Mailserver per IMAP muss meist ein Passwort angegeben werden. Das steht standardmäßig im Klartext in der Datei. Wie kann man sich schützen?
Die Lösung ist ganz einfach: Passwörter werden mit GnuPG verschlüsselt und mutt angewiesen, die Datei zu entschlüsseln. In der Passwortdatei stehen die Passwörter in einem Format, welches mutt versteht:
set imap_pass=“MeingeheimesIMAP-Passwort”
set smtp_pass=“MeingeheimesSMTP-Passwort”Anschließend wird dieses Datei mit GnuPG veschlüsselt. In die Konfigurationsdatei .muttrc kommt nun zusätzlich die Zeile:
source “gpg -d ~/.mutt/passwort.gpg |”Beim Start liest mutt die Konfiguration aus und startet GnuPG wie angegeben. Es muss das Passwort zur Entschlüsselung eingegeben werden und fertig ist alles.
Natürlich ist es sinnvoll, seine Festplatte oder das Home-Verzeichnis zu verschlüsseln. Denn manchmal gibt es andere Programme, die solche Informationen ebenso im Klartext hinterlassen.
Vielen Dank an Rainer für den Hinweis!
The website How's My SSL shows you, how your Browser handles HTTPS connections. In the case of Firefox 24 it shows:
Your SSL client is Bad.
But how can you improve this? I wrote some hints below:
I use Firefox 24. So all I wrote below belongs to this version. Future Firefox versions will bring some improvements. So some settings will be unnecessary then.
All settings must be made by using about:config. The configuration menu is not able to handle it. Enter about:config into the address bar. Firefox prints a warning, that changes will have effects on the security, stability etc. I assume that none of the settings below have negative impact. Thatswhy I confirmed it and came to the next window.
The config window has a search bar and a listing of configuration settings. Enter tls.v (or tls.version) into the search bar. Now you see four or five results. The important options are security.tls.version.min and security.tls.version.max. Both lines have an integer value in the last column. Those can be 0 (SSL 3.0), 1 (TLS 1.0), 2 (TLS 1.1) or 3 (TLS 1.2). You can change them by double clicking on it. I'd change the value security.tls.version.min to at least 1 (better 2)and security.tls.version.max to 3. If you change the first value to 2, it might be, that some pages don't work anymore. This is because they use some older protocol. However the minimum value should be 1 which is TLS version 1.0. You should contact the administrator of those pages and recommend to change to a newer TLS version. I'd like to hear which sites are affected.
Firefox also uses some insecure cipher suites. So i.a. is the cipher SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA supported. To change it, enter fips into the about:config search bar. You should see one result. By double-clicking you can set it to False. Brian Smith pointed out that SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA is not insecure. In his pull request at Github he describes why it is the case.
When you reload the HowsMySSL-page, you'd see a new result:
Your SSL client is Probably Okay.
Furthermore I usually deactivate all RC4 cipher suites. I look for rc4 and set them all to False
The Twitter user @andiheimann commented, that the Tor Browser Bundle fails:
@qbi @netzpolitik Der #TorBrwoser fällt beim Test leider auch durch..
— andi (@andiheimann) 10. Januar 2014
Tor has to balance anonymity and security. With those settings the anonymity set reduces and there might be some risks to the anonymity of a Tor user. Thatswhy it is probably better to wait for the new Firefox version.
The Tor Project released version 4 of the Tor Browser Bundle. This version comes with Firefox 31 ESR and disables SSLv3.
Chrome and Chromium doing a good job by default. Only when you want to disable RC4, you have to call both with specific command line options:
In October 2014 Google announced the POODLE exploit. So you should use at least TLS 1.0 in your browser. This option does exactly this: --ssl-version-min=tls1.
When using Opera 12 with the SSL-test-site it shows bad results. The recent Windows version 18 as well as Opera Next 19 are shown as »good«. If you see bad result then type Ctrl+F12 to open the settings and navigate to »Advanced« --> »Security« --> »Security Protocols«. You should make sure, that only TLS 1.1 and 1.2 is enabled. In the detail view you'll see all supported ciphers. Disable all ARC4-based ciphers.
A reload shows Opera as Improvable. This is caused by SSL Session Tickets. Unfortunately I found no settings. If you know where to find them, please leave a message.
Apple's Browser is like Opera: Improvable. Also SSL Session Tickets downgrade the result. As said before, if you know where to change it, please leave a message in the comment section.
Internet Explorer comes with support for SSLv3. To disable it, go to Internet Options and select the Advanced tab. Near the bottom you'll find a checkbox for using SSLv3. Uncheck and save it. You're done.
I'll add more browsers later.
Updates:
Die Webseite How’s My SSL zeigt, wie gut oder schlecht euer Browser konfiguriert ist. Für den Firefox in der Version 24 ergibt sich:
Your SSL client is Bad.
Wie lässt sich der Wert nun verbessern? Ich habe untenstehend mal ein paar Hinweise zusammengestellt.
Die Notizen beziehen sich auf den Firefox in der Version 24. In älteren Versionen hießen die entsprechenden Konfigurationspunkte teilweise anders. Eventuell ändern sich die Werte in der Zukunft wieder.
Die Konfiguration des Firefox’ muss über about:config angepasst werden. Im Menü gibt es dafür keine Möglichkeiten. Gebt also in die Adresszeile about:config ein. Firefox wird warnen, dass sich die Änderungen auf Sicherheit, Stabilität etc. auswirken können. Aus meiner Sicht sind die unten vorgestellten Änderungen unkritisch. Daher könnt ihr die Meldung bestätigen.
Im folgenden Fenster gibt es oben eine Suchzeile und unten diverse Konfigurationsoptionen. Gebt in die Suchzeile tls.v (oder auch tls.version) ein. Es erscheinen vier oder fünf Ergebnisse. Wichtig sind die Optionen security.tls.version.min und security.tls.version.max. Im letzten Eintrag auf der Zeile stehen die Zahlenwerte 0 (SSL 3.0), 1 (TLS 1.0), 2 (TLS 1.1) oder 3 (TLS 1.2). Mit einem Doppelklick auf die Zeile lassen sich die Werte ändern. Ich würde security.tls.version.min auf 2 setzen und security.tls.version.max auf 3. Es kann jedoch sein, dass bestimmte Seiten mit den Einstellungen nicht mehr funktionieren. In dem Fall setzt ihr den ersten Wert auf 1. Berichtet mal, welche Seiten das betrifft. Ihr solltet auch den Admin der Seite informieren. Vielleicht passt dieser die Konfiguration des Servers ja an.
Der nächste Punkt, der von der Testseite reklamiert wird, sind unsichere Algorithmen. Die Chiffre SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA wird vom Firefox noch unterstützt. Gebt in die about:config-Seite fips ein. Es dürfte nur ein Ergebnis bleiben. Ein Doppelklick ändert der Wert auf False. Brian Smith wies mich auf eine Diskussion bei Github hin. Dort gibt es einen Pull-Request nach dem SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA als nicht unsicher eingestuft werden soll. Eventuell muss diese Chiffre nicht aus den Einstellungen entfernt werden. Im Firefox ab Version 27 wird die entfernt.
Ein Reload der Seite zeigt nun das Ergebnis:
Your SSL client is Probably Okay.
Ich würde alle RC4-Chiffren ebenfalls deaktivieren. Dazu suche ich einfach rc4 und setze alle Werte auf falsch. Kai Raven hat weitere nützliche Hinweise zur Verschlüsselung im Firefox gesammelt. Seine Seite ist immer einen Blick wert.
Auf Twitter kommentierte @andiheimann, dass das Tor Browser Bundle bei dem Test durchfällt:
@qbi @netzpolitik Der #TorBrwoser fällt beim Test leider auch durch..
— andi (@andiheimann) 10. Januar 2014
In dem Fall muss Tor eine Balance zwischen Anonymität und Sicherheit finden. Vermutlich sticht ein Browser mit den Einstellungen zu stark aus der Masse heraus und gefährdet damit die Anonymität des Nutzers. Insofern ist es hier wieder sinnvoller zu warten. Immerhin hat Firefox angekündigt, ab der Version 27 die neuen TLS-Versionen standardmäßig zu aktivieren. Dann verschwindet das Problem hoffentlich von allein.
Das Tor-Projekt hat die Version 4.0 des Tor-Browser veröffentlicht. Darin wurde SSLv3 wegen der POODLE-Schwachstelle deaktiviert.
Chrome und Chromium machen laut der Seite auf Anhieb alles richtig. Falls auch RC4 deaktiviert werden soll, muss der Aufruf mit Optionen erfolgen:
chromium --cipher-suite-blacklist=0x0004,0x0005,0xc011,0xc007 deaktiviert RC4. Die Codes für den Aufruf sind in der TLS Cipher Suite Registry aufgelistet.
Im Oktober 2014 wurde eine Lücke bei SSL3 bekannt. Daher ist es sinnvoll, mindestens TLS 1.0 zu verwenden. Diese Option muss daher im Aufruf mit enthalten sein: --ssl-version-min=tls1.
Opera 12 präsentiert sich zunächst auch mit schlechten SSL/TLS-Einstellungen. Unter Windows liefert Opera die Version 18 aus. Diese wie auch Opera Next werden von der Testseite als Gut eingestuft.
Wenn ihr die alte Opera-Version habt, kommt ihr mit der Taste Strg+F12 in das Menü. Im letzten Reiter »Erweitert« gibt es den Eintrag »Sicherheit«. Mit der Schaltfläche »Sicherheitsprotokolle« öffnen sich die Einstellungen. Dort sollte nur TLS 1.2 (und ggf. TLS 1.1) aktiv sein. Bei den Einzelheiten könnt ihr die Einträge für ARC4 rausnehmen.
Mit den Einstellungen kommt der Opera auf Improvable. Problematisch sind hier noch die Session Tickets. Leider fand ich keine Möglichkeit, die Einstellungen zu ändern. Falls ihr einen Hinweis habt, hinterlasst einen Kommentar.
Der Webbrowser von Apple ist genau wie der Opera Improvable. Die Session Tickets trüben die Wertung und wie oben gilt: Wer einen Hinweis zur Konfiguration hat, möge den als Kommentar hinterlassen.
Der Internet Explorer hat standardmäßig SSLv3 noch aktiviert. Klickt auf das Zahnrad und wählt Internetoptionen. Im Reiter Erweitert müsst ihr bis ganz nach unten scrollen. Dort seht ihr dann Schaltflächen für SSLv2, SSLv3 und mehr. Deaktiviert SSLv3 und bestätigt dies. Danach verwendet der Internet Explorer kein SSLv3 mehr.
Andere Browser werde ich eventuell später noch ergänzen.
Updates:
Vor einem Jahr interviewte mich Teresa Sickert für Radio Trackback zur Zensur in China und zur Anonymität. In der heutigen Sendung wurde das nochmal ausgestrahlt und ihr könnt das als MP3 anhören. Viel Spass dabei!
Wer Zensurmaßnahmen erfolgreich umschiffen will, benötigt zahlreiche, verschiedene Werkzeuge. In jedem Land mit ausgeprägter Internetzensur gibt es auch ein Wettrennen zwischen den Zensoren und Zensierten. Ein vergleichsweise neues Werkzeug ist Lantern.
Lantern ist eine Software, die auf Java basiert und sich noch in der Testphase befindet. Die Software unterscheidet anfangs, ob Zensierten der Zugang erlaubt werden soll oder ob man selbst Informationen abrufen will. Im ersten Fall leitet die Software den Netzverkehr Fremder über die eigene Internetverbindung. Damit können diese das Internet frei (also genauso frei wie ihr) nutzen. Im zweiten Fall nutzt ihr die Verbindung anderer.
Zur Verbdinung der Benutzer nutzt Lantern Google. Die Software baut ein Vertrauensnetz der Nutzer auf. Dazu muss sich jeder bei Google einloggen und den anderen als Freund markieren. Den Rest macht Lantern im Hintergrund.
Das Projekt hat vor kurzem die fünfte Betavariante herausgegeben und möchte nun ihren Dienst mit mehr Nutzern testen. Falls ihr also freie Kapazitäten habt, registriert euch für die Betaversion auf der Webseite und testet dann die Software. Eventuell helft ihr Leuten da draußen, wieder ein neues Werkzeug zu benutzen und Informationen frei abzurufen.
Die Users-Seite im Tor Metrics Portal gibt derzeit große Rätsel auf.Seit Mitte August 2013 gibt es etwa dreimal soviele Tor-Nutzer wie sonst. Der Anstieg ist ungebrochen und mittlerweile merkt man als Nutzer einen deutlichen Performance-Einbruch. Das heißt, gerade das Surfen im Web fühlt sich deutlich langsamer an. Doch woher kommen die neuen Nutzer?
Roger Dingledine warf diese Frage auf der tor-talk-Mailingliste auf. Das wurde später von Ars Technica und auch Heise Online aufgegriffen. Aber niemand lieferte bisher eine Antwort.
Der erste Verdächtige hieß PirateBrowser. Diese Anonymisierungslösung aus dem Dunstkreis von The Pirate Bay nutzt Tor. Nun könnte man annehmen, dass der PirateBrowser unglaublich viele Nutzer anzieht und dadurch der Anstieg zustande kommt. Das würde aber bedeuten, dass alle diese Leute vorher kein Tor nutzten. Das halte ich bei dem »Kundenkreis« für recht unplausibel. Ich denke, die meisten nutzen schon jetzt Tor oder andere Lösungen. Weiterhin untersuchten einige die wahrscheinlichen Nutzerzahlen vom PirateBrowser. Die liegen meilenweit von dem Anstieg der Tor-Nutzer weg.
Collin Anderson analysierte die Nutzerzahlen in verschiedenen Ländern (Google-Docs-Dokument). Der Anstieg geht quer durch alle Länder (Diagramm). Ausnahme ist Israel. Dort gingen die Tor-Nutzer im betrachteten Zeitraum sogar etwas zurück.
Das stützt die These, dass hier ein Botnet zugange ist. Es könnte sein, dass Schadsoftware verteilt wird und diese nutzt Tor zur internen Kommunikation. Wenn die Software auf vielen Rechnern »installiert« ist und genutzt wird, dann steigen natürlich die Nutzerzahlen an. Diese Nutzer scheinen Tor mittlerweile wirklich zu nutzen. Denn ich stellte in den letzten Tagen eine deutliche Verlangsamung der (gefühlten) Geschwindigkeit bei Tor fest. Falls das also wirklich ein Botnetz ist, sollten die Tor-Clients als Relay umfunktioniert werden. Das hilft dann wieder dem gesamten Netz. 
Eine andere Theorie lässt sich zunächst dem Bereich der Verschwörungstheorien zuordnen. Aber da in letzten Zeit so viele Wahrheit wurden, brauchen wir mal neue.
Durch die Enthüllungen von Snowden ist es durchaus möglich, dass mehr Leute Verschlüsselung und Anonymisierungswerkzeuge wie Tor nutzen. Eventuell ist es nun für die NSA wirklich schwerer uns zu überwachen. Also wird Tor durch eine unglaubliche Zahl an Clients wieder »verlangsamt«. Viele Nutzer stellen fest, dass das zu unbequem ist und gehen zur alten überwachten Leitung zurück. Voila.
Was ist eure Theorie?
Seit Juni 2013 kommen in regelmäßigen Abständen Veröffentlichungen über Lauschprogramme der NSA und anderer Geheimdienste. In den letzten Tagen gab es dann noch einen Angriff gegen Nutzer von Tor. Der Angriff wird auch der NSA zugeschrieben und heizte mal wieder die Diskussion an, ob die NSA Tor-Knoten betreibt und damit die Anonymität der Nutzer schwächt. Doch was ist da dran? Betreibt die NSA wirklich Tor-Relays?
Die kurze Antwort ist: »Nobody knows«.
Die lange Antwort erfordert ein wenig Abwägung. Stellt euch vor, die NSA betreibt in größerem Umfang Relays. Dann gibt es prinzipiell die Chance, dass die Verbindungen eines Nutzers über drei NSA-Knoten geht und die Daten damit deanonymisiert werden. Bei Exitknoten gibt es zusätzlich die Möglichkeit, persönliche Daten abzugreifen. Dan Egerstad zeigte 2007, wie einfach es ist, an Passworte von Botschaften zu kommen.
Ein Blick auf die Liste der Tor-Relays, sortiert nach Bandbreite zeigt, dass sehr viele der Knoten von TorServers.net, DFRI und anderen Organisationen betrieben werden. Diese stehen für mich nicht im Verdacht, NSA-nah zu sein. Weiterhin versucht das Tor-Projekt »bösartige« Exits bzw. solche, die merkwürdiges Verhalten zeigen, zu finden. Hier konnten in der Vergangenheit wenige gefunden werden. Derzeit gibt es keinen Hinweis, der den Verdacht erhärten könnte.
Wenn man weiter annimmt, dass die NSA Tor-Knoten betreibt und sie sicher auch weiß, dass verschiedene Leute versuchen dies aufzudecken, ist klar, dass sie ein großes Risiko fährt. Denn wenn nur ein NSA-Relay aufgedeckt würde, erzeugt das wegen des Skandalisierungspotentials einen großen medialen Aufschrei. Aus den Überlegungen ist das also nicht empfehlenswert.
Des Weiteren hat die NSA Zugänge zu den großen Netzknoten und kann Kommunikation übergreifend mitlesen. In der Anonbib findet sich die PDF-Datei »AS-awareness in Tor path selection«. Die Autoren beschreiben, wie vergleichsweise einfach es ist, für einen Angreifer mit einer weiten Netzwerksicht, die Anonymität zu minimieren oder zu brechen. Das heißt, die Daten, die die NSA durch den Betrieb von Tor-Relays erhalten würde, hat sie jetzt schon als »Abfallprodukt« der Überwachung. Fefe schrieb recht melodramatisch, dass Tor tot ist. Seine Argumente finden sich bereits im Design-Paper von Tor aus dem Jahr 2003: »[…] Tor does not protect against such a strong adversary. Instead, we assume an adversary who can observe some fraction of network traffic …«. Das bedeutet, dass Tor gegen einen starken Angreifer nicht sicher ist.
Letztlich ist es natürlich auch möglich, dass in bestehende Relays eingebrochen wird und die Daten ausgeleitet werden. Spiegel Online hatte letztens einen Artikel zu einem Einbruch in ein »Wasserwerk«. Das Werk war hier nur eine Falle und der Betreiber beobachtete die Aktionen der Angreifer. Die NSA würde durch einen Einbruch in existierende Tor-Server ebenfalls interessante Erkenntnisse über die Tor-Nutzer gewinnen.
Alles in allem glaube ich, dass der massenhafte Betrieb von Tor-Relays für die NSA derzeit von Nachteil ist. Die Informationen können sie wahrscheinlich auf anderem Wege gewinnen. Warum sollte die Agency also das Risiko eingehen?
Die Frage wurde auch in Blogs diskutiert. Folgende englischen Beiträge fand ich recht interessant:
Update: Link zum DK25: National Security Agency eingebaut. Ein wenig Eigenwerbung muss sein.
