Qbi's Weblog

Der macht eine Meldung über die LogJam-Schwachstelle die Runde. Ein Besuch der Webseite WeakDH.org offenbarte auch bei meinen Browser-Einstellungen Schwächen. Doch wie sichere ich den gegen die Attacke?

Im Firefox ist das recht einfach: In die Adresszeile einfach about:config eingeben und dann in den Konfigurationseinstellungen nach dem Wert .dhe suchen. Der Punkt vor dhe ist wichtig, dass nur die relevanten Algorithmen gefunden werden. Alle Werte (je nach Version sind das zwei oder mehr) werden auf false gesetzt. WeakDH.org sollte nun keine Warnung mehr anzeigen.

Einstellungen im Tor Browser Bundle

Im Chrome oder Chromium gibt es keine Möglichkeit, die Einstellung über ein Menü zu machen. Der beste Weg, den ich fand, ist, zunächst die Cipher-Suite-Detail-Seite zu besuchen. Dort findet ihr eine Tabelle mit Algorithmen, die euer Browser unterstützt. In der Spalte Spec stehen Zahlen-/Buchstaben-Kombinationen. So findet sich bei mir beispielsweise der Eintrag: (00,0a). Sucht nun nach allen Einträgen, bei denen der Cipher-Suite-Name mit DHE (nicht ECHDE) beginnt und entfernt die Klammern und das Komma von der Spec. Nun fügt ihr noch ein 0x an den Anfang. Im obigen Beispiel wird also aus (00,0a) ein 0x000a. Diese unerwünschten Algorithmen werden als Option dem Chrome oder Chromium übergeben: google-chrome --cipher-suite-blacklist=0x009e,0x0033,0x0032,0x0039,0x0004,0x0005 ist das bei meinem Browser.

Wie sieht es bei anderen Browsern aus? Meines Wissens kann man den Internet Explorer nicht so detailliert steuern. Ich freue mich über Hinweise und nehme die gern mit in den Beitrag auf. Schließlich sollte das Ergebnis der Webseite dann wie unten aussehen.

Keine Angriffsmöglichkeit durch LogJam

Im letzten Jahr hatte ich die Abgeordneten des Thüringer Landtages befragt, ob diese denn PGP und SSL/TLS nutzen. Neben der Fraktion der Linken waren es Katharina König und Dirk Adams, die PGP einsetzten. Nun ist die neue Regierung mehr als 100 Tage im Amt. Also wollte ich einen zweiten Rundruf starten. Nach einem ersten Zwischenergebnis hat sich die Zahl der Abgeordneten wie auch die Zahl der Fraktionen mit einem PGP-Schlüssel verdoppelt. Die SPD-Fraktion und Dorothea Marx (SPD) sowie Steffen Dittes (Linke) kamen hinzu. Aber das sind Vorergebnisse.

Nun fragte ich mich, wie das wohl in anderen Landtagen aussieht. Alexander Morlang gab den Hinweis, auf den Keyservern nach dem Wort Fraktion zu suchen. Also legte ich eine Google-Docs-Tabelle an und fragte um Hilfe.

Mittlerweile gibt es einige Einträge. Überraschend fand ich, dass es in Bayern ein CDU-Mitglied mit einem Schlüssel gibt. Ansonsten dominieren derzeit die Piraten in den Landtagen.

Sind eure Abgeordneten in der Liste enthalten? Falls nicht, so schreibt denen doch mal eine E-Mail und fragt, ob sie einen Schlüssel besitzen oder wer in der Fraktion einen Schlüssel besitzt. Ich würde mich freuen, wenn ihr mir das Ergebnis zuschickt, hier kommentiert oder direkt in die Tabelle schreibt.

Update: Ich habe jetzt alle Fraktionen in den diversen Landtagen und Bürgerschaften angeschrieben. Dort fragte ich, ob bekannt ist, wer PGP/SSL/TLS oder anderes nutzt. Ich aktualisiere die Tabelle, sobald ich Antworten erhalte.

Überwachung ist überall. Mittlerweile gibt es verschiedene Initiativen, die sowohl politisch wie auch technisch etwas dagegen tun wollen. Eines dieser Projekte startet demnächst in Dresden. Unter dem Projekttitel »Echt Dezentrales Netz (EDN)« findet am 16. und und 17. Januar (folgendes Wochenende) ein Geekend statt. Am Freitag abend werden einige existierende Lösungen, wie Freenet, AN.ON und andere vorgestellt. Samstags geht es mit Vorstellungen weiter. Der Nachmittag ist dann für Workshops reserviert.

Falls ihr teilnehmen wollt, tragt euch im Dudle. Für Leute, die nicht nach Dresden kommen können, gibt es einen Mumble-Raum.

Die 5. Wahlperiode des Thüringer Landtages neigt sich dem Ende zu. Einer der letzten Beschlüsse ist die Drucksache 5/7583 mit dem Titel Verschlüsselte Kommunikation ermöglichen und befördern. In der Endfassung enthält der Beschluss die Bitte an die Landesregierung:

1. zukünftig Wege zu ermöglichen, welche die Vertraulichkeit des Inhalts elektronischer Kommunikation mit öffentlichen Stellen des Landes und der Nutzung ihrer elektronischen lnformationsdienste sowie des Inhalts elektronischer Kommunikation zwischen öffentlichen Stellen des Landes durch Angebote einer sicheren End-to-End-Verschlüsselung (Kryptografie) eröffnen,
2. die Bürger des Freistaats Thüringen in geeigneter Weise über die Möglichkeiten der Verschlüsselung elektronischer Kommunikation, insbesondere auf den Web-Seiten der Landesregierung, zu informieren.

Der Versuch

Darin steckt der Wunsch, TLS für Webseiten und Ende-zu-Ende-Verschlüsselung vielleicht mit OpenPGP zu machen.

Ich entschied mich, denselben Weg wie Anna Biselli zu gehen. Sie versuchte, verschlüsselt mit einem Abgeordneten zu kommunizieren. Ich besuchte die Webseiten der Fraktionen im Landtag und die der Abgeordneten. Dabei wollte ich jede Seite mit https öffnen und suchte nach einer Möglichkeit für verschlüsselte E-Mail-Kommunikation. Konnte ich beides nicht finden, so schrieb ich die Abgeordneten an. Was kam dabei heraus?

Fraktionen

Die CDU-Fraktion im Landtag bietet keinerlei Unterstützung für SSL/TLS an und es gibt auch keine Möglichkeit zur verschlüsselten E-Mail-Kommunikation.

Die Webseite der SPD-Fraktion begrüßt mich mit der Meldung SSL peer has no certificate for the requested DNS name. Eine verschlüsselte Verbindung zu der Seite ist damit nicht möglich und ich fand auch keinen OpenPGP-Schlüssel auf der Seite.

Die Webseite der FDP-Fraktion scheitert zunächst an den Einstellungen in meinem Browser und sagt Peer attempted old style (potentially vulnerable) handshake. Wenn ich die Einstellungen lockere, so präsentiert die Seite ein Zertifikat, was für die Domain web6.online-now.de ausgestellt ist. Wenn ich dann auch noch dieses akzeptiere, so erhalte ich von der resultierenden Seite die Meldung Die Domain “www.thl-fdp.de” ist nicht über https verfügbar. Die Unterstützung von OpenPGP ist wie bei den anderen Parteien.

Die Webseite der Fraktion der Grünen hat ein Zertifikat, welches seit Ende 2013 abgelaufen ist. Ich hatte den Fakt im Juli 2014 gemeldet. Zum Zeitpunkt des Blogeintrages hat sich an dem ungültigen Zertifikat nichts geändert. Wird dies akzeptiert, so werden die Inhalte der Webseite angezeigt. OpenPGP sucht man jedoch vergeblich.

Einzig die Fraktion der LINKEn unterstützt SSL/TLS vom Start weg und die Servereinstellungen sind sehr gut. Hier wäre nur zu wünschen, dass die Webseite alle Anfragen standardmäßig auf die verschlüsselte Seite umleitet. Die positiven Nachrichten reißen aber noch nicht ab. Denn die Kontaktseite bietet einen OpenPGP-Schlüssel zum Download an und weist den Fingerprint aus. Damit ist die LINKE eindeutig der Spitzenreiter, was verschlüsselte Kommunikation betrifft.

Abgeordnete

Von den knapp 90 Abgeordneten im Landtag gibt es nur zwei, die einen OpenPGP-Schlüssel anbieten:

• Dirk Adams (Grüne)
• Katharina König (LINKE)

Beider Webseiten sind auch per HTTPS zu erreichen. Jedoch verwendet die Seite von Dirk Adams ein falsches Zertifikat und die Seite von Katharina König bzw. der Provider blockieren Verbindungen über Tor. Falls ihr also die Seite mit Tor ansurft, kann es sein, dass sich diese nicht öffnet.

Uwe Barth (FDP) nutzt ein Wordpress-Blog als Webseite. Damit kann die Seite auch per HTTPS besucht werden. Die SPD-Abgeordneten David-Christian Eckardt, Uwe Höhn, Birgit Pelke und Claudia Scheerschmidt nutzen das Angebot von Sozinet. Das bietet ebenfalls HTTPS an.

Bei allen anderen Abgeordneten fand ich keine funktionierende Möglichkeit, per HTTPS auf die Seite zuzugreifen. Ebenfalls konnte ich keine Nennung von E-Mail-Verschlüsselung finden. Also schrieb ich E-Mails und fragte nach.

Die Abgeordneten der FDP haben das Wahlkampfmotto Wir sind dann mal weg wohl zu ernst genommen. Denn ich erhielt von keinem der angeschriebenen Abgeordneten eine Antwort.

Die CDU schien sich intern auf eine Antwort geeinigt zu haben. Alle Antworten hatten nahezu denselben Wortlaut und verwiesen darauf, dass der Beschluss eine Aufforderung an die Regierung enthält. Erst wenn diese eine Entscheidung getroffen hat, so werden die Abgeordneten diese umsetzen. Aus den Antworten wurde klar, dass vorher nichts zu erwarten ist.

Von der SPD antworteten einige wenige Abgeordnete. Allerdings treten diese nicht mehr zur Wahl an oder sind unsicher, ob sie wiedergewählt werden. Daher hatte das Thema keine Priorität.

Von den grünen Abgeordneten erhielt ich zwei Antworten. In einem Fall ist eine neue Webseite in Arbeit. Die neue Seite soll dann auch Verschlüsselung unterstützen. Im anderen Fall war die Meinung, dass Verschlüsselung nicht notwendig ist, da alle auf der Seite angebotenen Daten öffentlich sind.

Bei der Linken konnte ich einen interessanten Effekt beobachten. Anfangs erhielt ich von den Abgeordneten individuelle Antworten. Ab einem Zeitpunkt kamen eine Art Standardantworten mit ähnlichem Wortlaut. Ich vermute, dass sie sich intern auf eine Sprachregelung geeinigt haben. Bei den individuellen Antworten gab es Abgeordnete, die klar schrieben, dass sie sich mit dem Thema bisher noch nicht auseinandergesetzt haben und noch nicht wissen, wie sie damit umgehen. In einem Fall erhielt ich eine verschlüsselte E-Mail mit Schlüssel und hätte künftig verschlüsselt kommunizieren können.

Insgesamt gibt es bei den Abgeordneten noch viel zu tun. Natürlich verwiesen viele auf die bevorstehenden Sommerferien und Wahlen. Daher werde ich die Wahlen abwarten und später nochmal bei den Abgeordneten nachfragen. Vielleicht wird Thüringen der Verschlüsselungs-Standort Nr.1.

Lest ihr regelmäßig Bugreports oder Meldungen über Schwachstellen bei SSL/TLS? Wie fühlt ihr euch so? Zur Erinnerung:

Ausschnitt aus einer Folie aus dem MUSCULAR-Programm der NSA

• 22. Februar 2014: Apple wird wegen des goto-fail-Bugs belächelt
• 3. März 2014: Die freie Bibliothek GnuTLS hat einen ähnlich schweren Bug
• 7. April 2014: OpenSSL vermeldet die Heartbleed-Schwachstelle

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:

Passwort und Nutzername im Dump der Daten von Yahoo! Mail

• Netzpolitik.org: HeartBleed: Ein OpenSSL-Bug, der weitreichende Folgen haben könnte
• Heise: Passwort-Zugriff: Heartbleed-Lücke mit katastrophalen Folgen
• Heise Security: So funktioniert der Heartbleed-Exploit
• Zeit: Heartbleed – auf der Gruselskala bis 10 ist es die 11
• Ars technica: Critical crypto bug exposes Yahoo Mail, other passwords Russian roulette-style
• Vox: The heartbleed bug, explained
• existential type crisis : Diagnosis of the OpenSSL Heartbleed Bug
• The Register: Anatomy of OpenSSL’s Heartbleed: Just four bytes trigger horror bug
• Erweiterung Chromebleed für Google Chrome
• pacemaker – Client Exploit

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

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.

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:

Firefox

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.

Google Chrome and Chromium

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.

Opera

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.

Safari

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

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.

Others

I'll add more browsers later.

Updates:

1. Thanks to Brian for his comments on SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA and morphium for his comment on Opera
2. Recommended TLS 1.0 in Chrome because POODLE.
3. Mention that Tor Browser 4 comes without SSLv3.
4. Added info about IE

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.

Firefox

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.

Google Chrome und Chromium

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

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.

Safari

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.

Internet Explorer

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

Andere Browser werde ich eventuell später noch ergänzen.

Updates:

1. Felix “ href=”/blog/archives/1563-SSL-im-Browser-sicher-verwenden.html#c9071">wies darauf hin, dass er noch einen weiteren Ausschluss für den Chrome braucht.
2. Vielen Dank an @mr_moosbee, @remark73 und @kampfflunder für die Safari-Hinweise.
3. Ein paar Worte zum Tor Browser Bundle.
4. Brian Smith schickte mir den Link zu der Diskussion auf Github und morphium erwähnte in den Kommentaren Opera.
5. Verweis auf den Eintrag zum Firefox-Tuning im Wiki von Kai Raven.
6. Mit der POODLE-Schwachstelle muss mindestens TLS 1.0 verwendet werden.
7. Erwähnung von TBB 4.0 ohne SSLv3
8. Beschreibung zum Internet Explorer
   

Letzte Woche hielten Roger und Jake vom Tor-Projekt einen Vortrag an der TU München. Die Veranstaltung war eher ein Marathon aus Fragen und Antworten. Dabei erwähnten die beiden auch, dass es unter Windows keine Möglichkeit gäbe, die Software GnuPG sicher herunterzuladen. Ein Versuch bestätigte das. Doch wie kann man als Windows-Nutzer auf sichere Weise zu der Software gelangen?

Verschlüsslung von Mails und Dateien unter Windows erfolgt mit gpg4win. Es gibt eine Downloadseite mit verschiedenen Versionen. Ein digitale Unterschrift zu jeder Datei wird ebenso geboten. Wo liegt also das Problem. Der Download der Dateien erfolgt über HTTP. Das kann beliebig manipuliert werden, ohne das der Anwender etwas merkt. In Ländern wie Syrien, die Bluecoat-Rechner einsetzen, ist die Manipulation der Verbindung bereits jetzt Realität.

Ich fragte bei Intevation, dem Betreiber der Server, nach einer Lösung. Mir schwebte eine SSL/TLS-Verbindung für die Webseite vor. Nach der Antwort ist der komplette Betrieb einer HTTPS-Seite zu aufwändig. Allerdings gibt es für den Fileserver ein selbst-signiertes Zertifikat. Das kann über eine spezielle Seite heruntergeladen werden.

Damit sind alle Komponenten zusammen, um zumindest dem erfahrenen Benutzer einen sicheren Download zu ermöglichen. Ihr solltet dabei folgendermaßen vorgehen:

1. Besucht die SSL-Seite von Intevation. Mit Stand von August 2013 ist diese Seite durch ein von Geotrust unterschriebenes Zertifikat gesichert. Die aktuellen Browser akzeptieren das Zertifikat bedenkenlos.
2. Klickt auf das Intevation Root CA 2010. Euer Browser wird fragen, was er mit dem Zertifikat machen soll. Ihr könnt ankreuzen, dass dieses zur Identifizierung von Webseiten dient.
3. Nun könnt ihr zum Fileserver von gpg4win gehen. Die SSL-Verbindung wird nun ebenfalls akzeptiert.
4. Auf dem Fileserver wählt ihr die korrekte Datei und ladet die herunter. Daneben könnt ihr auch die Signatur laden und später vergleichen.

Auf dem Wege hat zumindest ein erfahrener Nutzer die Chance, sicher an die ausführbare Datei zu kommen. Viel Spass beim Verschlüsseln!

Mehr als zwanzig Jahre ist es nun her, als sich eine Gruppe von Leuten auf einer Mailingliste »traf«. Die Cypherpunks diskutierten in den folgenden Jahren Kryptografie, Anonymität und andere Techniken zum Schutz der Privatsphäre. Letztlich ist über verschiedene Ecken auch Bitcoin ein Produkt der Cypherpunks-Zeit. Allerdings diskutierten die Teilnehmer nicht nur, sondern viel wichtiger, sie programmierten. Ein Spruch aus den Zeiten lautet: »Cypherpunks write code.«

Nun fand ich eine E-Mail in meiner Inbox, die das erneute Aufleben der Mailingliste ankündigte. Und prompt trudelten hier einige E-Mails ein. Wer also an den Themen Kryptografie, Politik und Privatsphäre interessiert ist, kann sich dort eintragen. Allerdings kamen früher recht viele E-Mails über die Liste und auch in den letzten Tagen erhielt ich recht viele Nachrichten. Ihr solltet also mit eurem E-Mail-Client gut filtern.

Ich bin gespannt, ob die Liste neuen Drive gewinnt. Immerhin habe ich durch die Diskussion der letzten Tage ein paar Zufallszahlenerzeuger für den Rechner kennengelernt und habe nun was zum Testen.

Die beiden Kryptografen Shafrira »Shafi« Goldwasser und Silvio Micali erhalten den ACM Turing Award. Das ist so eine Art Nobelpreis in der Informatik. Goldwasser und Micali sind vermutlich nur Insidern bekannt. Sie lieferten allerdings wesentliche Beiträge zur Kryptografie. Die Begriffe der Semantic Security und Ununterscheidbarkeit eines Algorithmus’ vom Zufall gehen auf die Forscher zurück. Sie legten damit die Grundlagen für eine Formalisierung des Wissenschaftszweiges. Ich gratuliere beiden Wissenschaftlern für die Auszeichnung!

Pressemitteilung der ACM

Patrick Beuth hat für die ZEIT ein Experiment gemacht. Er stellte sich die Frage, wie schwierig es für Laien ist, sich anonym und sicher zu bewegen. Diese Erfahrungen schrieb Beutch in der Serie »Mein digitaler Schutzschild« nieder. Für das Experiment kaufte er sich einen neuen Rechner und installierte Ubuntu. Später machte er sich Gedanken zu sicheren Verbindungen über VPN und Tor, nutzte E-Mail-Verschlüsselung mit OpenPGP und verschlüsselte die Festplatte. Die Artikel sind aus der Sicht eines neuen Benutzers geschrieben und sehr interessant zu lesen.

• Mein digitaler Schutzschild
• Ubuntu – die Basis für einen sicheren Computer
• Tor – die Tarnkappe fürs Netz
• VPN – durch einen Tunnel ins Internet
• Hushmail – auch E-Mails können anonym sein
• OpenPGP – E-Mails verschlüsseln, damit sie keine Postkarten mehr sind
• TrueCrypt – der Tresor auf der Festplatte

ZEIT Online macht sogar den Sprung vom Artikel in die Praxis und organisiert am 26. Februar eine CryptoParty. Dort zeigen Patrick Beuth und die Organisatoren der CryptoPartys in Berlin, wie die verschiedenen Werkzeuge zu benutzen sind. So wird die anfängliche Hürde, derartige Werkzeuge zu benutzen sicher kleiner.

Die nächste Woche bietet zwei spannende Termine:

1. Der Datenkanal geht wieder auf Sendung. In der ersten Sendung im neuen Jahr wollen wir uns über den 29C3 unterhalten.
2. Es gibt wieder eine CryptoParty im Krautspace. Beim letzten Mal haben wir nur theoretisch diverse kryptologische Aspekte angesprochen. Dies schien Tim Thaler nicht ganz zu gefallen. Diesmal geht es mehr um die praktischen Aspekte. Im Wiki stehen schon einige Ideen drin. Wenn euch was interessiert, kommt einfach mit vielen Fragen vorbei. Wenn ihr keine Fragen habt, so wäre es schön, wenn ihr ein paar Kleinigkeiten zum Knabbern mitbringt.

Woody Guthrie mit Gitarre (Quelle: Wikipedia bzw. Library of Congress)

Der Titel des Buches klingt spektakulär: »Die Maschine, die Geheimnisse vernichtet«. Der Journalist Andy Greenberg berichtet im gleichnamigen Buch von dieser Maschine und hat an vielen Stellen spektakuläres zu berichten. Greenberg kam durch die Gitarre von Woody Guthrie auf den Titel. Die Gitarre trug den Aufkleber: »This machine kills fascists« (siehe Bild).

Die Maschine, die Geheimnisse vernichtet, beginnt mit den Pentagon-Papers ihr Werk. Daniel Ellsberg veröffentlichte die geheimen Dokumente damals mit Hilfe der NY Times. Julian Assange und neuere Entwicklungen sind noch lange nicht das Ende der Maschine. Vielmehr wird sie wohl lange weiterleben. Das Buch zeichnet den Weg der Maschine nach.

Im Prolog wird ein Treffen mit Julian Assange beschrieben. Julian kündigt dort die MegaLeaks an und verspricht einen Leak über eine US-Bank. Der erste Teil startet mit einer Gegenüberstellung von Ellsberg und Bradley Manning. Greenberg vergleicht im Kapitel »The Whistleblowers« ihre Herkunft und ihr Vorgehen. Ellsberg hatte seinerzeit die Berechtigung sehr geheime Dokumente zu lesen. Ein Privileg, was nur wenige mit ihm teilten. Manning auf der anderen Seite war einer von 2,5 Millionen Amerikanern, die aufgrund lascher Voreinstellungen auf viele geheime Dokumente Zugriff hatten. Beide waren der Meinung, dass »ihre« Dokumente an die Öffentlickeit müssen. Ellsberg war sich sicher, dass er für die Veröffentlichung der Pentagon-Papiere für den Rest seines Lebens im Gefängnis landen würde. Manning, auf der anderen Seite, schien Hoffnung zu hegen, dass er unerkannt davon kommt. Zumindest arbeitet Greenberg diesen Punkt im Buch heraus. Die realen Entwicklungen waren jedoch genau gegenteilig. Ellsberg wurde nicht bestraft und Manning wird aller Voraussicht nach lange Zeit im Gefängnis bleiben.

Das erste Kapitel ist sehr schön geschrieben. Man merkt hier schon, wie gut Greenberg seine Geschichte recherchiert hat. Mit der Gegenüberstellung der beiden Protagonisten gelingt ihm ein schöner Spannungsaufbau.

Cover des Buches

Die folgenden drei Kapitel widmen sich der »Evolution of Leaking«. Greenberg erzählt die Geschichte der Cypherpunks detailliert nach. Den Startpunkt bilden dabei die Lebensläufe von Tim May und Phil Zimmerman, der Erfinder von PGP. Mit Geschichten zu Julian Assange und John Young, dem Gründer von Cryptome geht es weiter. Schließlich spielen die Diskussionen auf der Mailingliste und der Artikel »Assassination Politics« von Jim Bell eine Rolle. Der Keynote-Sprecher des 29C3, Jacob Appelbaum, mit dem Tor-Projekt bilden den Abschluss.

Der dritte Teil hat die Zukunft (»The Future of Leaking«) zum Gegenstand. Dort geht es um »Plumbers«, »Globalizers« und »Engineers«. Das Kapitel beginnt mit Peiter Zatko. Mudge, wie er sich nannte, war einer der Köpfe der Hacker-Gruppe Cult of the Dead Cow und hatte engere Kontakte zu Assange. Mittlerweile arbeitet er bei der DARPA und soll Gegentaktikten zum Leaking entwickeln. Das langfristige Ziel des Projektes ist, Leaking komplett zu unterbinden. Greenberg beschreibt im Kapitel HBGary und den Anonymous-Hack sehr lebendig. Der Autor nutzt IRC-Logs und persönliche Gespräche und kann dadurch eine sehr detaillierte Sicht auf die Dinge bieten. Die Isländische Initiative zu modernen Medien (IMMI) und BalkanLeaks sind die Vorboten der Zukunft. Schließlich traf Greenberg zufällig den Architekten. Derjenige, der nur unter dem Namen »Der Architekt« agiert, war für die sichere Neugestaltung von WikiLeaks zuständig und arbeitet jetzt bei OpenLeaks. Greenberg traf ihn zufälligerweise beim Chaos Communication Camp.

Am Ende des Buches steht ein kurzer Abschnitt zur »Machine«. Greenberg macht klar, dass heute jeder zum Leaker werden kann. Mobiltelefone und andere elektronische Gegenstände erlauben es, Reportagen von Ereignissen anzufertigen oder eine Vielzahl elektronischer Dokumente zu kopieren. GlobaLeaks wird kurz beleuchtet. Das Projekt baut an einer Lösung für eine Leakingplattform mit Freier Software. Greenberg schließt mit den Worten:

We don’t yet know the names of the architects who will build the next upgrade to the secret-killing machine. But we’ll know them by their work.

Ich habe es sehr genossen, das Buch zu lesen. Zum einen hat Greenberg einen schönen, lebendigen Schreibstil. Obwohl ich viele Aspekte der Geschichten kannte, hatte das Buch einiges Neues zu bieten. Faktisch auf jeder Seite ist die gute Recherchearbeit des Autors zu spüren. Es war spannend für mich den Handlungssträngen zu folgen. »This machine kills secrets« war eines der Bücher, was ich nur schwer aus der Hand legen konnte und am liebsten am Stück durchgelesen hätte. Leseempfehlung!

Wer von euch einen Verlag kennt, der das Buch ins Deutsche übersetzen will, kann sich gern an mich oder an Andy Greenberg wenden.