Skip to content

ZenMate als Anonymisierungsprogramm

Kürzlich führte ich einen Workshop zum technischen Datenschutz und Verschlüsselung durch. Während Workshops zeigte ich den Teilnehmern verschiedene Werkzeuge, unter anderem auch den Tor Browser. Dabei meinte ein Teilnehmer, dass er ZenMate einsetzt und dies genauso sicher wie der Tor Browser ist.

Wechsel des Orts bei ZenMateWas ist ZenMate? Auf der Webseite verspricht die Anwendung Verschlüsselung sowie anonymes Browsen. Der Internetverkehr wird durch virtuelle private Netze (VPNs) geleitet. Das Plugin lässt sich einfach installieren und fragt anschliessend nach einer E-Mail-Adresse. Nachdem eine E-Mail-Adresse eingegeben wurde, wird das Plugin nach einer kleinen Wartezeit aktiv. In der Browserleiste im Firefox erscheint ein grünes Schild und nach einem Klick lässt sich rechts unten der Ort wechseln (Change Location). Auf Empfehlung des Teilnehmers wählten wir im Kurs Hong-Kong aus und fühlten uns geschützt. Doch wie sieht die Realität aus?

Ich nutze für Tests auf Anonymisierung meist die Seite IP-Check. Nach dem Start des Tests und einer kurzen Wartezeit ergab sich folgendes Bild:

Anzeige der realen IP-Adresse in ZenMate

Das Plugin leitet zwar die Verbindungen über das VPN weiter und nutzt einen Server in Hong-Kong (oder auch anderen Städten). Weitere Browsereinstellungen bleiben jedoch unangetastet. Im Beispiel oben war es das Flash-Plugin, was in vielen Browsern standardmäßig aktiv ist, das sogar die reale, gerade verwendete IP-Adresse preisgegeben hat. Mit der manuellen Deaktivierung von Flash wird die eigene IP-Adresse nicht mehr unmittelbar erkannt. Allerdings bleiben noch genügend andere Möglichkeiten übrig das Onlineverhalten der Benutzer zu verfolgen.

Letztlich stecken die Entwickler des Tor Browsers sehr viel Zeit und Energie, Lücken im Firefox zu schließen. Daher wäre es schon sehr verwunderlich, wenn sich gleiches Ziel, nämlich anonymes Browsen, mit einem einfachen Plugin erreichen ließe.

Wer also ZenMate einsetzen will, sollte sich der Risiken im Klaren sein und ggf. selbst weitere Anpassungen im Browser vornehmen. Eventuell funktioniert die Kombination des JondoFox-Profils mit ZenMate besser. Diesen Versuch überlasse ich euch. Ihr könnt gern einen Kommentar hinterlassen. :-)

Verschlüsselung im Thüringer Landtag -- Ein Versuch

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:

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. :-)

Wie funktioniert eigentlich Heartbleed

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

SSL added and removed here!
Ausschnitt aus einer Folie aus dem MUSCULAR-Programm der NSA

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

Firefox 27 mit TLS 1.2

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.

Neues SSL-Zertifikat für kubieziel.de

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. Continue reading "Neues SSL-Zertifikat für kubieziel.de"

Noch jemand ohne TLS1.2?

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.

Using SSL securely in your browser

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:

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

Internet Options within IEChrome 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
cronjob