Skip to content

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

SSL im Browser sicher verwenden

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:

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

Internetoptionen beim IEOpera 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

Cypherpunks reloaded

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.

Offener Brief an Google

Heute haben 38 Akademiker und Forscher einen offenen Brief (HTML-Version)an den CEO von Google, Eric Schmdit, geschrieben. So fordern auf sechs Seiten (plus zwei Seiten Fußnoten) die Standardnutzung von HTTPS und somit adäquate Sicherheit und den Schutz der Privatsphäre für die Nutzer.

Aus der Zusammenfassung:

Google already uses industry-standard Hypertext Transfer Protocol Secure (HTTPS) encryption technology to protect customers’ login information. However, encryption is not enabled by default to protect other information transmitted by users of Google Mail, Docs or Calendar. As a result, Google customers who compose email, documents, spreadsheets, presentations and calendar plans from a public connection (such as open wireless networks in coffee shops, libraries, and schools) face a very real risk of data theft and snooping, even by unsophisticated attackers. Tools to steal information are widely available on the Internet.

Google supports HTTPS encryption for the entire Gmail, Docs or Calendar session. However, this is disabled by default, and the configuration option controlling this security mechanism is not easy to discover. Few users know the risks they face when logging into Google’s Web applications from an unsecured network, and Google’s existing efforts are little help.

Support for HTTPS is built into every Web browser and is widely used in the finance and health industries to protect consumers’ sensitive information. Google even uses HTTPS encryption, enabled by default, to protect customers using Google Voice, Health, AdSense and Adwords. Google should now extend this degree of protection to users of Gmail, Docs and Calendar.

Rather than forcing its customers to “opt-in” to adequate security, Google should make security and privacy the default.

Rückblick auf ein Jahr Remailer-Betrieb

Na gut, eigentlich ist es schon mehr als ein Jahr, dass ich den Mixmaster-Remailer in Betrieb habe. Aber die paar Tage machen den Kohl nicht fett.

Nachdem ich desöfteren mit Mixmaster, Mixminion und Co. herumgespielt hatte und das im Buch Anonym im Netz lang und breit beschrieb, wollte ich einen langlebigeren Mixmaster-Server als Remailer anbieten. Meiner Meinung nach sollte ein vServer hierfür reichen und durch die Suche bei Webhostlist stiess ich auf ein Angebot der Firma Xantron. Diese bot einen vServer mit 1 GB RAM, 1 GB Festplatte und unbegrenztem Traffic an. Für den Anfang sollte das ein hinreichendes Angebot sein.

Anfangs liess ich testweise einen Tor-Server dort laufen. Denn der Eintrag der FAQ z u Tor auf virtuellen Servern sagte damals, es würde nicht funktionieren. Bei meinem Test klappte es jedoch ohne Probleme. Ich konnte Tor auf dem Server über mehrere Wochen ohne Einschränkungen laufen lassen. Irgendwann aktualisierte ich dann auf eine neue Version und der Tor-Prozess startete kurz, um gleich wieder abzusterben. Es gab keine Core-Datei. Das Log blieb ohne Anzeichen auf irgendwelche Probleme. Der gesamte Fall schien sehr mysteriös. Die Seite mit (un)geeigneten ISPs für Tor brachte mich dann auf eine Idee. Ich legte ein kleines Shell-Skript an, welches den Namen Tor trug und führte das aus. Kurze Zeit später brach es ab. Eine weitere Analyse ergab dann, dass der Provider wahrscheinlich einen Cronjob laufen hatte, der nach Prozesses mit dem Namen “tor” suchte und diese beendete. Sobald ich die ausführbare Datei von tor in nichttor oder ähnliches änderte, klappte wieder alles. Nach diesem Zwischenspiel richtete ich dann den Remailer ein.

Die Einrichtung ist in meinem Buch beschrieben und recht einfach zu machen. Entweder beantwortet man Fragen über ein Menu oder editiert eine Datei mit den Einstellungen.Danach sollte getestet werden, ob der Remailer wirklich so funktioniert, wie er sollte. Falls das der Fall ist, können die anderen Operatoren über den neuen Remailer informiert werden. Nun treffen nach und nach Nachrichten ein und der neue Remailer wird in das Netz der bestehenden integriert.

Mein Remailer nennt sich devurandom und hat momentan die beste Uptime im Netz. :-) Er bewegt etwa 5.000 E-Mails am Tag durch das Netz. Ein Großteil davon sind Nachrichten, die an andere Remailer weitergegeben werden. Nur ein etwa ein Fünftel der eingehenden Nachrichten verlässt das Remailer-Netzwerk und geht an den endgültigen Empfänger. Daneben gibt es eine Handvoll Postings in das Usenet.

monatliche Load des Serervs

Die Last, die das System erzeugt, ist zu vernachlässigen. Die Grafik zeigt einen Überblick über die Systemlast des letzten Monats. Es gab mal eine Spitze von 0,5. Aber in der Regel liegt die Last bei unter 0,1. Auch die sonstigen Parameter des Systems weisen nicht auf irgendeine Überlastung hin. Vielmehr langweilt sich der vServer die meiste Zeit des Tages. Die einzige Sache, die mich hin und wieder stört, sind viele zurückgestellte (deferred) E-Mails. Momentan liegen über dreihundert E-Mails rum, da ein Remailer an einem DSL betrieben wird und der Rechner ist wahrscheinlich gerade aus.Die Grafik der zurückgestellten E-Mails sieht daher wie ein Börsenkurs aus. ;-)

Eine Frage, die wahrscheinlich viele der Leser interessiert, ist der Missbrauch. Wie oft wird der Dienst missbraucht? Wieviele Hausdurchsuchungen hatte ich schon? Letzte Frage lässt sich einfach beantworten: 0. Wie oft Missbrauch geschieht, kann ich leider nicht sagen. Denn als Betreiber sieht man nur die Spitze des Eisberges. Nur wenn ich jede E-Mail lesen und auswerten würde, hätte ich genaue Zahlen. Daher will ich mich auf Beschwerden von dritter Seite konzentrieren.

Im letzten Jahr gab es insgesamt drei Fälle, in denen sich eine dritte Seite an mich gewendet hat. Anfang 2008 rief mich ein Rechtsanwalt an. Das Telefonat war etwas wirr. Aber soweit ich es verstanden habe, hat sein Klient eine E-Mail von meinen Remailer erhalten. In der E-Mail waren Links zu Bildern, die angeblich urheberrechtlich geschützt sind. Er wollte natürlich den Urheber der E-Mail wissen. Ich habe ihm dann in einer längeren E-Mail das Wesen des Dienstes erklärt und ihm auch gesagt, dass ich den Urheber nicht kenne. Seitdem habe ich nichts mehr gehört.

Der zweite Kontakt war ebenfalls wieder über einen Rechtsanwalt. Er schrieb mir einen formellen Brief. Ein Nutzer hat seinen Klienten beleidigt und auch er wollte den Urheber wissen. Ich ging wieder wie oben vor und auch hier gab es nie eine Antwort oder Rückmeldung.

Der bisher letzte Kontakt war auch der spannendste. Den Vorfall hatte ich schon im Beitrag Ihre Kriminalpolizei bittet um Mithilfe beschrieben. Damals hatte jemand eine Drohmail über den Remailer verschickt und die Polizei wollte den Urheber wissen. Nach einer Erklärung über die Funktionsweise des Remailers und der Bemerkung, dass ich nicht logge, war am anderen Ende ein Grummeln zu hören. Jedoch kam der Beamte noch auf die Idee, dass ich ihm doch einen Abzug des RAM machen könne. Nachdem ich auch das verneint hatte, kam am anderen Ende die Bemerkung, dass ja jetzt eh Feierabend sei und man daher die Akte schließen werde. Ich habe auch von diesem Vorfall nichts wieder gehört.

Der Vertrag über den Server wurde kürzlich wieder verlängert und ich werde auch in diesem Jahr den Mixmaster weiter laufen lassen. Sobald ich Zeit habe, kommt noch ein Mixminion-Server hinzu.

Ziviler Ungehorsam

Der Hostblogger kündigte in einem Posting an, auch ab dem nächsten Jahr die VDS nicht umsetzen zu wollen. Er setzt dabei auf ein Urteil, was kürzlich gegen (oder besser für :-)) BT gefällt wurde. Die brauchen auch nichts zu speichern, da es keine Aufwandsentschädigung gibt. Ich will stark hoffen, dass er mit seinem “zivilen Ungehorsam” durchkommt und ihm das BVerfG dann auch recht gibt.

Der Jurist Patrick Breyer hat sich auch mit der VDS auseinandergesetzt und kam zu dem Schluss, dass unentgeltlich angebotene Dienste nicht der Vorratsdatenspeicherung unterliegen. Der Beitrag klingt vielversprechend. Jedoch diskutieren die Juristen über die Redewendung “in der Regel”. Hier önnte es sein, dass der Ansatz von Patrick flasch ist. Denn nach Meinung der Bundesnetzagentur ist es beispielsweise bei E-Mail-Anbietern die Regel, die Dienstleistung gegen ein Entgelt bzw. gegen Werbeeinblendungen anzubieten. Es zählt also nicht, was der jeweilige Anbieter in der Regel tut, sondern “was der Markt macht”. Nichtsdestotrotz wünschte ich, dass er recht hätte.

Wer an den letzten Entwicklungen zur VDS kurz vor Toresschluss interessiert ist, sollte unbedingt den 25C3 besuchen. Roger Dingledine wird in einem Vortrag den Stand der Dinge erklären.

cronjob