1. Abhörverbot
Seit Jahrzehnten nimmt die NSA Einfluss auf Verschlüsselungsverfahren. Sie wirken bewusst auf Designschwächen hin, um Algorithmen gezielt abzuschwächen. Unter anderem wurde das National Institute of Standards and Technology (NIST) unterwandert. In den Beiträgen Perfect Forward Secrecy mit Apple Mail? und NSA abhörsichere SSL-Verschlüsselung für Apache und nginx bin ich darauf bereits eingegangen – allerdings nur aus Serversicht.
Auch Anwender haben die Möglichkeit bestimmte Chiffriermethoden (Cipher-Suiten) in ihrem Browser zu bevorzugen. Veraltete oder unsichere Verschlüsselungsvarianten lassen sich gezielt abschalten. Bereits Anfang des Jahres hat Dan Bernstein in einer Präsentation deutlich gemacht, dass RC4 mit ausreichend finanziellen Mitteln und Manpower knackbar sei. Über beides verfügt die NSA – daher liegt es nahe diese Verschlüsselungsvariante im Browser endlich abzuschalten.
Jacob Applebaum twitterte am 06. November:
RC4 is broken in real time by the #NSA – stop using it.
Ebenso kommentierte Bruce Schneier:
Someone somewhere commented that the NSA’s „groundbreaking cryptanalytic capabilities“ could include a practical attack on RC4. I don’t know one way or the other, but that’s a good speculation.
2. Firefox
2.1 RC4 abschalten
RC4 gilt spätestens seit Anfang des Jahres als unsicher. Dennoch bieten noch viele Webserver RC4 als Verschlüsselungstechnik an. Selbst das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat erst seit wenigen Tagen Abstand davon genommen. Noch bis zum 13. November hat der Webserver des BSI RC4-Stromchiffren angeboten.
Standardmäßig unterstützt Firefox 25.0.1 rund 35 verschiedene SSL Cipher-Suiten. Über die Webseite der Universität Hannover lassen sich diese auslesen.
RC4 sollte allerdings nicht weiter benutzt werden und lässt sich mittels einem manuellen Eingriff in die about:config abstellen. Nach Eingabe von »rc4« in die Suchmaske sollten 6 Werte angezeigt werden, die per Doppelklick alle auf »false« gesetzt werden.
Eine erneute Prüfung der unterstützten Cipher-Suiten reduziert die Anzahl auf 29.
2.2 Minimum TLS 1.0
Das Transport Layer Security (TLS) Protokoll ist eine standardisierte Weiterentwicklung von Secure Sockets Layer (SSL). Dennoch ist der Begriff SSL weitläufiger und wird allgemein verwendet. In Firefox ist die minimale Anforderung für die Aushandlung einer verschlüsselten Verbindung SSL 3.0. Die maximale Anforderung hingegen TLS 1.0. Die Weiterentwicklung TLS 1.1 und TLS 1.2 hingegen werden standardmäßig nicht als Anforderung für eine verschlüsselte Verbindung herangezogen. Stark vereinfacht bedeutet das:
- SSL 3.0 ist die unsicherste Variante, die spätestens seit dem 15.10.2014 als »geknackt« gilt
- TLS 1.0 hat SSL in der Bezeichnung abgelöst und ist vergleichbar mit SSL 3.1
- TLS 1.1 und TLS 1.2 sind jeweils Weiterentwicklungen des Vorgängers und implementieren neue Verschlüsselungsstandards
In der about:config sind folgende Standardwerte eingetragen:
Diese Werte lassen sich folgendermaßen anpassen:
- 0 steht für SSL 3.0
- 1 steht für TLS 1.0
- 2 entspricht TLS 1.1
- und 3 entspricht TLS 1.2
Viele Server-Betreiber kümmern sich allerdings nicht um ihre SSL-Konfiguration, weshalb höhere Werte bei vielen Seiten in einem Verbindungsabbruch enden. Sofern sich Client und Server auf keine Verschlüsselungsmethode einigen können, bricht die Verbindung ab. Daraus lässt sich schließen, dass der Server lediglich veraltete Cipher-Suiten anbietet. Dennoch lässt sich das Minimum anpassen – TLS 1.0 sollten die meisten Server mittlerweile unterstützen.
Update
15.10.2014: In Anbetracht der neuen Poodle-Schwachstelle von SSL 3.0 solltet ihr die Variable »security.tls.version.min« mindestens auf »1« setzen und damit nur noch verschlüsselte Verbindungen ab TLS 1.0 zulassen.Hilf mit die Spendenziele zu erreichen!
Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.
Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.
2.3 Perfect Forward Secrecy
Mit Perfect Forward Secrecy (PFS) wird verhindert, dass eine in der Vergangenheit verschlüsselt aufgezeichnete Kommunikation durch Bekanntwerden des geheimen Schlüssels wieder entschlüsselt werden kann. PFS nutzt das Diffie-Hellman-Schlüsselaustauschverfahren, bei dem sich beide Kommunikationspartner auf einen temporären Sitzungsschlüssel einigen. Dieser Schlüssel wird nicht zwischen den Kommunikationspartner ausgetauscht und kann daher nicht aufgezeichnet werden. Eine nachträgliche Entschlüsselung wird damit unmöglich.
Auch diese Cipher-Suiten lassen sich in Firefox manuell erzwingen – allerdings werden dann vermutlich 98% der Webseiten auf SSL-Basis nicht mehr funktionieren. Die Verbreitung der Technik ist einfach noch zu gering.
Nach Eingabe von »security.ssl3« in die Suchmaske sollten alle SSL-Cipher-Suiten erscheinen. Per Doppelklick werden alle Einträge auf »false« gesetzt, die weder DHE oder ECDHE im Namen tragen.
Entsprechend unterstützt Firefox dann lediglich noch 16 SSL-Ciphers.
3. Google Chrome
Auch in Google Chrome lässt sich RC4 deaktivieren – allerdings umständlicher als in Firefox. Über eine Blacklist müssen die Cipher als Parameter direkt beim Start übergeben werden. Entsprechende Hexcodes müssen zunächst aus dem Quellcode extrahiert werden.
chrome --cipher-suite-blacklist=0x0001,0x0002,0x0004,0x0005,0x0017,0x0018,0xc002,0xc007,0xc00c,0xc011,0xc016,0xff80,0xff81,0xff82,0xff83
Update
15.10.2014: In Anbetracht der neuen Poodle-Schwachstelle von SSL 3.0 solltet ihr Google Chrome mit dem zusätzlichen Befehl »–ssl-version-min=tls1« starten und damit nur noch verschlüsselte Verbindungen ab TLS 1.0 zulassen.4. Internet Explorer
In einem Security Advisory 2868725 hat das Security Research & Defense Team von Microsoft beschrieben, wie sich in Windows und damit für den Internet Explorer RC4 abschalten lässt.
Über den Registry-Editor sind folgende Werte anzupassen:
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128] "Enabled"=dword:00000000 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128] "Enabled"=dword:00000000
5. Fazit
Eine Umstellung der SSL-Cipher-Suiten im Browser beendet nicht die Abhöraktionen der Geheimdienste. Davon sind wir weit entfernt. Erreicht wird dadurch lediglich ein zusätzlicher Schutz gegen die grenzenlose Datenschnüffelei – und dazu sind nur wenige Handgriffe notwendig. Webserver die weiterhin lediglich RC4 als Verschlüsselungsvariante anbieten sollten in Zukunft boykottiert werden.
Wir bewegen uns weiter in einer Spirale des Misstrauens. Tag um Tag wächst die Skepsis gegenüber der Bundesregierung und damit dem Staat, die verdachtlose Überwachung in Deutschland zu beenden – oder es jedenfalls zu versuchen! An dieser Stelle möchte ich noch eine Twitter-Meldung von Sascha Lobo zitieren:
Immer, wenn man gerade denkt, Hans-Peter Friedrich sei der schlechteste Bundesinnenminister jemals – hat man recht.
Bildquellen:
Uncle Sam is watching you: „#53956151“, https://de.fotolia.com/id/53956151
Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:
37 Ergänzungen zu “Unsichere SSL-Verschlüsselung im Browser abschalten”
Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-ForumAbschließender Hinweis
Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.
wie immer super Infos. Auf 98% aller Internet-Seiten kann ich leider nicht verzichten, aber RC4 habe ich gleich mal abgeschaltet und die TLS-Werte geändert.
Mal sehen, wie sich das Internet danach „anfühlt“.
Danke, weiter so, bin immer auf die nächsten Infos gespannt.
Eine Frage hätte ich noch dazu: Wenn ich RC4 abschalte, stellt der Server automatisch auf eine „sicherere“ Verschlüsselung um? Am Besten wäre natürlich ein Addon, mit dem man für jede Seite die Verschl.methode bestimmen könnte.
Der Server bietet dem Client eine Liste mit von ihm untersützten Cipher-Suiten an. Sollte RC4 dabei sein, dann ignoriert der Browser in Zukunft diesen Vorschlag. Beide einigen sich anschließend auf eine SSL-Cipher-Suite die BEIDE unterstützen.
Falls sich Server und Client (Browser) auf keine Verschlüsselung einigen können, wird keine SSL verschlüsselte Verbindung zustande kommen.
Danke für Ihre ganzen Bemühungen rund um das Thema „Sicherheit“. Eigentlich sollten Sie in den öffentlichen Auftreten und das ganze Volk aufklären, aber wegen den „Shows“ wie Lanz, Illner usw. hätte man eh kein Sendeplatz für diese „banalen“ Dinge ;)
„Der Server bietet dem Client eine Liste…“
Kann man von einem fremden Server diese Liste mit einfachen Mittel (z.b. openssl) auslesen oder gibt es nur Try and Error?
Danke
Das geht mit sslscan oder sslyze ganz einfach.
(1) sslscan –no-failed IP-Adresse
(2) sslyze IP-Adresse –regular
Vielen Dank. :-)
Ich wünsche dir (und allen Anderen auch) ein gutes Jahr 2014.
Herzlichen Dank für die präzisen Informationen und ganz besonders für die Anleitung, wie ich meinen Firefox sicherer einstellen kann. Das habe ich bisher auch bei Heise vermisst.
Welche Möglichkeiten gibt es, diese Einstellungen auch bei Opera 17 und höher auf dem PC vorzunehmen?
Bei Opera auf dem Android sowie Firefox auf Android war beide Male mittels about:config alles gut zu konfigurieren.
Beste Grüße
Clemens
Zu Opera habe ich keine Infos – vielleicht jemand anderes?
Da Opera angesprochen wurde, würde ich gerne was loswerden. Opera (neue Version) sagt in den Nutzungbedingungen ganz klar, dass bei jeder Installation eine Browser „ID“ angelegt wird. Einige dürften sich an alte Chromezeiten erinnert fühlen. Anscheinend ähnelt nicht nur der Look, sondern auch die Datensammlerei. Fazit: Firefox ist immer noch der sicherste Browser (natürlich nur mit NoScript, Request Policy usw.)
Bei mir funktionert im Firefox der Ebay-login nicht mehr wenn ich security.ssl3.rsa_aes_128_sha oder security.ssl3.rsa_aes_256_sha auch auf false setze.
Einer der beide muss auf true stehen damit es funktionert.
Gehören die wirklich auch zu RC4 weil in dem Names nichts von RC4 drin steht?
Wenn es zu RC4 gehört, ist die einzige Lösung ein separates Firefox Profil dafür zu nutzen?
Wenn dieser Eintrag drinn bleibt, wäre die ganze andere Arbeit umsonst und ich hätte trotzdem diese Sicherheitslücke drin?
Danke (auch für diesen Interesanten Artikel),
Frank
Bei der Internet Bank meines „vertrauens“ ist das bebenfalls so.
Jetzt komme ich nicht mehr auf meine Fritzbox zu Hause.
(Fehlercode: ssl_error_no_cypher_overlap).
Kann ich an der FB die Einstellung ändern oder brauche ich ein zweites Profil im FF?
Hab jetzt mal wieder alles zurückgestellt. Jetzt frage ich mich allerdings ist meine Fritzbox 7490 überhaupt sicher?
Danke
Alfred
Welche Schritte hast du alle durchgeführt? Versuche mal nur die RC4-Cipher zu deaktiveren.
ich musste dazu security.ssl3.rsa_rc4_128_md5 oder security.ssl3.rsa_rc4_128_sha aktivieren.
einen anderen Cypher bietet Fritz OS6 nicht an. Habe mich mal bei AVM beschwert (am besten auch machen!)
…warum Bruce Schneier auf seiner Webpräsenz weiterhin auf RC4 setzt: Weil die Verschlüsselung dort sowieso irrelevant ist, weil:
– keine (Client-)Authentisierung stattfindet und somit
– ausschliesslich öffentlich zugängliche Informationen präsentiert werden
Tja, wenn ich RC4 im Firefox abschalte, funktionieren die Videos bei Youtube nicht mehr (die Werbung schon, aber die richtigen Videos nicht.)
Das kann ich bestätigen!
mit FF v. 28 und exakt wie beschrieben umgestellt, funktionieren bei mir nicht mehr:
– Xing
– LinkedIn
– Inoreader
– Bitbucket
Fehlermeldung: Cannot communicate securely with peer: no common encryption algorithm(s). (Error code: ssl_error_no_cypher_overlap)
– Facebook
– Dropbox
laufen nur in einem „nichtgrafischen“ Modus
– Fritzbox
funktioniert!
Gruß Wolfram
Die interessante Frage ist immer: WELCHE der Settings wurden aus dem Beitrag übernommen? Alle? Nur RC4? Im Text steht der Hinweis, dass vermutlich 98% der Webseiten nicht mehr funktionieren, falls folgendes umgesetzt wird:
Ich habe alle Settings übernommen, also RC4, DHE und ECDHE, sowie sowie die von „3 – 0“ zu „3 – 1“. Der Hinweis, dass danach ca. 98% der Seiten nicht mehr funktionieren, ist mir nicht entgangen. Ich war nur sehr erstaunt darüber, dass noch nicht einmal die großen Player hier mitmachen. Mir ist natürlich nichts anderes übrig geblieben als die dhe und ecdhe betreffenden Änderungen wieder zurück zu nehmen.
Gruß Wolfram
Kann ich deine Einstellungen zu rc4 und TLS 1.1 auch für Thunderbird übernehmen?
Dort sind in der Konfig bei TSL min 0 und max 1 eingestellt. Ich habe es jetzt erhöht auf 1 und 2.
Das weiss ich nicht. Aber da sowohl Firefox, als auch Thunderbird von Mozilla kommen ist es ein naheliegender Gedanke. Vielleicht hilft das hier weiter: http://kb.mozillazine.org/Secure_connections_-_Thunderbird
Hallo Mike!
Habe lange keine YouTube-Videos mehr angeschaut. Erst jetzt stelle ich fest, dass viele Videos (all?) nicht mehr zu sehen sind. Es erscheint die Meldung, es sei ein Fehler aufgetreten und ich solle es später noch einmal versuchen.
Jetzt fand ich dank Deines Blogbeitrags hier heraus, dass Google (im Gegensatz zu früheren Zeiten) plötzlich zwingend die Akzeptanz von ssl3_rsa_rc4_128_sha verlangt. Sobald ich diese unsichere Verschlüsselung in der about:config zulasse, werden alle Videos einwandfrei abgespielt.
Angesichts der Beliebtheit von YouTube und der extrem hohen Nutzerzahlen wäre es denkbar, dass Google die Nutzer dazu zwingt, eine unsichere Verschlüsselung zuzulassen, damit… (bitte beliebieg einsetzen: NSA, GCHQ usw.) möglichst ungehindert spionieren können.
Gibt es einen Workaround, wie man YouTube-Videos auch bei sicherer Einstellung in Firefox anschauen kann?
Beste Grüße
Clemens
Clemens, einzige Idee die ich hab, IE benutzen oder einen anderen Browser oder ein neues FF Profil aufsetzen.
@frank
Dein Vorschlag löst doch das grundsätzliche Problem nicht, dass Google uns bei der Nutzung von YouTube de facto dazu zwingt, eine unsichere Verschlüsselung zuzulassen, um Videos gucken zu können!
Mache ich also meinen Browser offen für diese unsichere Verschlüsselung, habe ich spätestens beim Besuch aller möglicher anderer Websites ein Sicherheitsrisiko.
Unverständnis weckt bei mir deine Nennung des Internet Explorers, weil er sich ja nun bekannter Weise niemals mit dem Begriff Sicherheit verträgt.
Die Idee, ein weiteres Firefox-Profil aufzusetzen, könnte die Lösung sein, falls es möglich wäre, je Benutzerprofil unterschiedliche Verschlüsselungen einzutragen in der about:config.
Aktuell behelfe ich mich damit, vor Besuch der YouTube-Seite die about:config zu ändern und nach dem Besuch wieder zurück zu ändern. Sehr lästig!
Ferner hat sich gezeigt, dass nicht alle Videos unter unsicherer Verschlüsselung zugänglich sind, sondern etliche kann man auch mit sicherer Browser-Einstellung betrachten. Ich habe noch nicht heraus gefunden, wonach sich der Unterschied richtet. (ha auch zu wenig Zeit dafür, mich eingehend damit zu beschäftigen. IT ist nun wirklich nicht mein Kerngeschäft.
Beste Grüße
Clemens
Nun, wenn Google uns zwingt eine unsichere Verschlüsselung zu benutzen, was kann man da tun? Ich wüßte keinen Ausweg.
Ich wollte mit dem IE Vorschlag nur sagen das man für YT alleine IE nutzen können und für den Rest FF. Ich könnte damit leben ein unsicheres YT zu haben wenn der Rest sicher ist.
Warum nicht einen Youtube-Proxy als FF-Addon benutzen?
Wenn man Google nicht vertraut, sollte man auch keinen anderen Browser benutzen.
Wenn allerdings auch andere Seiten Probleme bereiten, müsste ein eigenes Addon her oder man muss sich einen Proxy mieten/Tor benutzen.
Hallo,
ich bekomme nun seit einiger Zeit von verschiedenen Seiten die Meldung: Fehlercode: ssl_error_inappropriate_fallback_alert
Habe versucht, die Fallbacks auf 2 und auf 3 zu erhöhen. Aber keine Besserung. Wenn ich auf 3 erhöhe – also die niedrigste TLS Verschlüsselung – bekomme ich die Meldung: Fehlercode: ssl_error_no_cypher_overlap
Was kann man da machen?
version.fallback-limit auf 0 (nicht 3) ist die niedrigste Version ;)
Es kann schon vorkommen, dass alte Server mit SSL 3 jetzt Probleme machen, da es (vlt bereits von Mozilla?) im Browser abgeschaltet wurde, da es eben unsicher ist.
Hm, okay, mit 0 hat es auch nicht geklappt.
Es handelt sich dabei u.a. um diese URL: https://www.java.com/en/download/installed.jsp
Kommt bei jmd von euch vllt die selbe Meldung? Wenn ja, dann soll es mir egal sein. Wenn nicht, liegt ein Problem vor
Lösch mal die Cookies zu den Seiten; deaktiviere Addons wie Certificate Patrol und setze security.tls.version.min auf 1.
Hi Alex,
hat nichts gebracht die cookies zu löschen. TLSmin war bereits auf 1 und Addons habe ich keine installiert, die eine Verschlüsselung beeinflussen.
3DES würde ich ebenso wie RC4 abschalten, denn die eff. Sicherheit entspricht nicht 168 Bit sondern nur 112 Bit.
Also mit der portablen Verison klappt es. Muss dann wohl an meiner Version liegen. Keine Ahnung was da passier sein sollte…
ganz aktuell
Firefox 39 entfernt SSLv3 und RC4
https://www.heise.de/newsticker/meldung/Firefox-39-entfernt-SSLv3-und-RC4-2734444.html
Um es zusammenzufassen: allzuviel ist aktuell nicht mehr übrig…
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) Forward Secrecy 128
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) Forward Secrecy 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) Forward Secrecy 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) Forward Secrecy 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) Forward Secrecy 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) Forward Secrecy 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa)
sind die Verfahren die vor Qualys SSL Labs noch bestehen und zugleich auch nicht als „exotisch“ oder „langsam“ gelten wie z.B. CAMELLIA- oder „POLY“ Algorithmen. Die verwendet anscheinend fast keiner. 3DES ist nur aufgrund seiner Kaskadierten Verschlüsselung „sicher“ aber halt deswegen auch langsam. 2^112 (bzw. sind auch das eigentlich 2^168, egal ob beim 2. Gang vor- oder rückwärts gerechnet wird, der Key ist ja stets ein anderer ohnehin, deswegen stellen beide Richtungen m.E. jeweils einen wirksamen „Modus“ dar letztlich, nur die komplette Auflösung mit demselben Key ist eine effektive Entschlüsselung, eine mit dem falschen bewirkt letztlich und vielmehr immer nur eine erneute „Verschlüsselung“, da das Ergebnis dann jeweils wieder etwas „pseudozufälliges“ ergibt !).
Die beiden DHE-Suiten die noch da sind bewertet Qualys als sicher gegen „Logjam“ (kurze Bitlängen per „MITM-Downgraderequest“ sind damit also bei FF auch nicht mehr möglich).
MS hat aktuell noch weitere Suiten (weitere GCM-Modi mit 256 und 384 Bits) im Angebot, die aber auch FF gut zu Gesicht stehen würden. (bisher GCM nur mit AES128+SHA256 im Moment).