Qbi's Weblog

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
   

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:

• Anonymity Smackdown: NSA vs. Tor von Robert Graham. Er traf einige falsche Annahmen und hat diese zum Teil durch Updates korrigiert.
• Antwort zu obigem Beitrag von Roger Dingledine auf der libtech-Mailingliste
• Should I warn against Tor? auf der Tor-talk-Mailingliste

Update: Link zum DK25: National Security Agency eingebaut. Ein wenig Eigenwerbung muss sein.

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!

Woher kommen eigentlich Viren, Würmer und andere Schadsoftware? Über welchen Weg brechen Angreifer in Computersysteme ein? In vielen Fällen heißt die Antwort »Buffer Overflow« oder Pufferüberlauf. Jörg und ich sind der Frage nachgegangen, was so ein Buffer Overflow eigentlich ist. Wir versuchen anhand einer Analogie mit Kisten und deren Inhalten das Wesen des Überlaufs zu erklären. Anschließend bieten wir einige Lösungen für das Problem an. Neugierig geworden? Dann hört mal in den Datenkanal 19 rein:

• DK19 als MP3
• DK19 als OGG

Durch Bitlove könnt ihr beide Dateien über BitTorrent herunterladen.

• MP3 als BitTorrent
• OGG als BitTorrent

Viel Spass beim Anhören und, falls ihr mögt, könnt ihr flattrn.

Ende letzten Jahres zog ich mit der Webseite auf einen anderen Server um. Der alte Server war etwas schwach auf der Brust. Einige Trafficspitzen bei meinen Seiten sorgten dafür, dass die Load sehr hoch ging. Der neue Webserver verträgt die Last sehr gut. Die Seiten werden daher schneller ausgeliefert und offensichtlich erzeugt, das jetzt mehr Traffic. Seit dem Umzug habe ich jeden Tag konstant mehr Traffic. In der Statistik ergibt sich folgendes Bild:

Die zweite gute Nachricht ist, dass Uberspace Server Name Indication (SNI) beim Webserver einsetzen. Das heißt, ich kann für die Seite ein eigenes SSL-Zertifikat nutzen. Daher könnt ihr ab sofort auf https://kubieziel.de/ aufrufen. Ich nutze hierfür ein Zertifikat von StartCOM. Im Gegensatz zu CAcert haben die den Vorteil, im Browser integriert zu sein. Der Nutzer muss sich also nicht durch eventuell unverständliche Meldungen quälen.

Ich werde versuchen, einen Eintrag in der Erweiterung HTTPS Everywhere zu bekommen. Wer also Firefox oder Chrome benutzt und das Plugn installiert hat, kommt dann automatisch zu den SSL-Seiten.

Im Februar 2013 wird hier also alles noch schöner, toller und überhaupt.

Geek and Poke beschreibt sehr schön, wie sich ein Security-Geek in einem Restaurant beschweren kann: