Skip to content

Firefox verbessert den Schutz der Privatsphäre

Als das Tor-Projekt den Tor-Browser entwarf, machten sie sich viele Gedanken zum Schutz der Privatsphäre. Sie versuchten jegliche Gefahren zu identifizieren und diese zu umschiffen. Daraus entstand das Design zum Tor-Browser. Seitdem versuchen die Entwickler, die Schwachstellen in Bezug auf die Privatsphäre im Mozilla Firefox im Griff zu behalten. Neben dem Tor-Button kommen viele individuelle Patches zum Einsatz. Die meisten davon wurden bisher von Mozilla nicht in den Firefox eingepflegt. Doch dies ändert sich jetzt.

Seit Anfang Mai gibt es im Wiki von Mozilla eine Seite, die sich Tor Uplift nennt. Mozilla fängt nämlich nun doch an, Patches vom Tor-Projekt in den Firefox wieder einzubauen. Auf der Wikiseite wird der Fortschritt festgehalten. Bisher kamen 26 Änderungen weiter und an sechs wird gerade aktiv gearbeitet. Sören Hentzschel beschreibt in seinem Blogbeitrag, welche neuen Optionen es im Firefox gibt und wie diese aktiviert werden können.

Insgesamt ist das ein guter Schritt der Entwickler, den Schutz der Privatsphäre im Firefox weiter zu erhöhen. Wie Sören in seinem Beitrag schreibt, engagiert sich Mozilla auch weiterhin stark im Tor-Projekt. Weiter so! :-)

Warum kannte die Polizei die Terroristen und fing sie nicht?

Die Nachrichten über die schlimmen Terroranschläge in Brüssel ziehen am Nachrichtenticker vorbei und schon beginnen wieder die üblichen Diskussionen. Die Innenpolitiker fordern mehr Überwachung, andere machen die Flüchtlinge oder Angela Merkel verantwortlich, wieder andere weisen darauf hin, dass Flüchtlinge gerade vor dem Terror geflohen sind etc. Es tauchen auch, wie bei anderen Anschlägen, Meldungen auf, dass die Kriminellen schon vorab den Behörden bekannt waren und es wird die Frage gestellt, warum nichts gemacht wurde. Einer der Gründe ist die Mathematik, die gegen die Behörden spielt. Warum ist das so?

Zu Anfang treffe ich ein paar Annahmen: Ich verwende Belgien als Beispiel. Das Land hat ca. 11 Millionen Einwohner. Weiterhin bräuchte ich eine Zahl potenzieller Terroristen. Jetzt nehme ich mal an, es gäbe nur islamistischen Terrorismus. In Deutschland meldet das Bundesamt für Verfassungsschutz ein islamistisches Personenpotenzial von knapp 44.000 Menschen. Angenommen die Zahl lässt sich 1:1 auf Belgien übertragen, so leben dort gerundet 5.500 Menschen mit einem islamistischen Personenpotenzial. Das Ziel der Behörden ist nun, diese Personen zuverlässig zu filtern und ggf. zu beobachten.

Dazu werden Überwachungs-, Datenauswerte- und Kontrollmaßnahmen installiert. Das System ist so leistungsfähig, dass es 99,9% aller Terroristen erkennt. Also nur in einem Tausendstel der Fälle wird ein Terrorist nicht als solcher erkannt. Aber es erkennt auch Normalbürger in einem Prozent der Fälle fälschlicherweise als Terroristen.

Das System ist in Betrieb und bringt einen Alarm, dass es einen Terroristen erkannt hat. Aber ist dies wirklich einer und wie hoch ist die Wahrscheinlichkeit? Geht mal in euch und versucht, eine Schätzung abzugeben.

Um die Frage zu beantworten, stellen wir uns vor, dass System würde ganz Belgien durchleuchten. Es würden also 5.495 Terroristen erkannt werden. Daneben erkennt das System auch 110.000 Einwohner als Terroristen, die keine sind. Das heißt, insgesamt wird 115.495 Mal Alarm geschlagen. Aber der Alarm war nur in 4,7 % der Fälle korrekt. Das heißt, das System schlägt in mehr als 95 % der Fälle falschen Alarm.

Das heißt, dass zwar viele Personen und besonders viele Terroristen von so einem System erkannt würden. Dennoch sind auch hier die Mehrzahl unbescholtene Bürger und die Strafverfolger haben die Arbeit, korrekt zu filtern. Diese Arbeit sieht im Nachhinein sehr einfach aus. Aber üblicherweise fehlen bei der Suche vor einem Anschlag viele konkrete Hinweise. Letztlich müssen wir akzeptieren, dass es perfekte Sicherheit nicht herstellbar ist. Ich bin der Meinung, dass nicht mehr Überwachung, Datenaustausch und Repression die Lösung ist, sondern die Politik (»wir«) sollte sich Gedanken machen, wo die Gründe liegen und diese beseitigen.

Browser gegen LogJam absichern

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

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

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.

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:

chromium --cipher-suite-blacklist=0x0004,0x0005,0xc011,0xc007TLS Cipher Suite Registry.

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
tweetbackcheckcronjob