Heartbleed Bug? Neues https-Zertifikat für Indy linksunten!

The Heartbleed Bug

Am 8. April wurde der Heartbleed Bug bekannt, ein schwerwiegender Programmierfehler in der OpenSSL-Bibliothek. Wir haben unmittelbar nach der Veröffentlichung die Debian-Sicherheitsupdates installiert und nun auch unseren https-Schlüssel und unser Zertifikat ausgetauscht.

 

Indymedia linksunten verwendet seit 2012 überall https und seit dem Upgrade auf Debian wheezy auch Perfect Forward Secrecy auf unserem Mayfirst-Server. Dadurch wird für jede verschlüsselte Verbindung ein neuer Sitzungsschlüssel benutzt, so dass selbst bei Vorratsdatenspeicherung nur durch die Kenntnis des geheimen Hauptschlüssels nicht die Daten, die von und an linksunten.indymedia.org gesendet wurden, nachträglich entschlüsselt werden könnten.

 

Durch den Heartbleed-Bug war nicht nur ein Diebstahl von https-Schlüsseln, sondern auch von Sitzungsschlüsseln prinzipiell möglich. Es gibt für uns leider keine Möglichkeit herauszufinden, ob ein solcher Angriff stattgefunden hat. Ein Man-in-the-middle-Angriff ist zwar grundsätzlich immer möglich, doch wenn der geheime Schlüssel bekannt ist, kann dieser nicht einmal durch einen Vergleich der Fingerprints entdeckt werden. Aus diesem Grund wurde als Vorsichtsmaßnahme ein neuer https-Schlüssel und ein neues Zertifikat erstellt.

 

Der SHA1-Fingerprint unseres neuen Zertifikats lautet:

80:DB:3E:66:1D:8B:BF:A1:21:A3:D8:B3:06:EB:C6:DD:F0:BD:DB:1E

Zeige Kommentare: ausgeklappt | moderiert

Sollte nochmal explizit gesagt werden, dass der aktuelle OpenSSL-Bug nicht nur Linksunten betrifft sondern "große Teile des Internets"  (Web, E-Mail, eingeschränkt auch Tor). Für Banken (die halt auch "nur" auf HTTPS setzen) z.B. ist die Lücke ein ziemlicher GAU. Insbesondere Server-Betreiber sind deshalb seid gestern fleißig am Updaten auf die aktuelle OpenSSL-Version. Ein Exploit (also die Möglichkeit für jede_rmensch, die Lücke einfach auszunutzen) ist zwar noch nicht in Umlauf, allerdings ist dies nur eine Frage der Zeit und nicht auszuschließen, dass Behörden mit entsprechendem Budget bereits dazu in der Lage sind.

 

Danke für das schnelle patchen @Linksunten-Admins

der Bug ist sehr leicht auszunutzen und das bereits von Anfang an!
http://www.heise.de/newsticker/meldung/Passwort-Zugriff-Heartbleed-Lueck...

Ein Modul für Metasploit existiert z.B. ebenfalls.
http://www.heise.de/newsticker/meldung/SSL-Gau-So-testen-Sie-Programme-u...

Bin mal gespannt ob die Amateure von indymedia.de das auch mal gefixt bekommen. Der Browser meckert sowieso immer über deren selfsigned Zertifikat. Warum bei denen nicht grundsätzlich auf https gesetzt wird war mir auch schon immer unklar.

Naja, das läuft eh im Juni ab, spätestens dann werden die sich wohl mal was überlegen müssen....

Deren System baut auf statischen Mirror-Servern auf, so dass sie für jeden Mirror ein Zertifikat (oder ein Wildcard-Zertifikat) bräuchten. Das ist unschön, aber machbar. Warum sie immer noch ein selfsigned-Zertifikat benutzen, verstehe ich auch nicht.

de.indymedia benutzt fürs surfen bisher überhaupt kein ssl.

da kann insofern auch nix kompromitiert sein ;)

die mirror wiederum sind nur fürs surfen.

bisher wird ssl bei de.indymedia nur fürs veröffentlichen benutzt, daher reicht dort ein zertifikat aus.und das ist jetzt leider kompromitiert gewesen über zwei jahre. das ist das eigentlich schlimme an der sache.

der leak aber sollte kein grund sein, auf de.indymedia rumzuhacken. die sicherheitslücke hat so gut wie alle progressiven seiten betroffen.

(war de.indymedia überhaupt betroffen? bei derem alten system kann ich mir vorstellen, dass deren open-ssl version nicht mal betroffen war ;-) )

 

die frage, ob ein selbstgezeichnetes zertifikat benutzt wird oder auf eine kommerzielle zertifizierungsstelle zurück gegriffen wird ist eine politische.

einzig cacert ist wirklich unkommerziell, bietet aber kaum vorteile, da das cacert root-zertifikat nicht in browsern standard-mäßig installiert ist.

nur weil eine zertifizierungsstelle nix kostet ist sie noch lange nicht unkommerziell.

sicherer wird es durch die zertifizierungsstelle nicht wirklich - nur praktischer weil keine warnmeldung des browsers mehr erfolgt und du nicht mehr selbst den key überprüfen musst. das web-of-trust bei ssl-zertifizierungsstellen ist allerdings derart löchrig, dass das imho eher unter praktisch als unter sicherer fällt.

bei de.indymedia war die sicherheitspolice daher bisher so, dass ja nur leute, die veröffentlichen wollen sich damit auseinander setzen müssen.

und da die anonymisierung den nutzenden nicht abgenommen werden kann wurde bisher immer darauf verwiesen, dass sich gedanken gemacht werden muss, wie anonymisiert wird und dazu gehörte auch der abgleich des ssl-zertifikats.

ich denke aber, dass de.indymedia in zukunft einen anderen weg einschlagen wird, da sie ja auch bald verschlüsselt surfen anbieten wollen - und da ist die warnmeldung ein zu großes hindernis, ssl zu benutzen für unbedarfte nutzende. daher wird wohl auch hier auf ein kommerzielles, aber kostenloses angebot aus dem web-of-trust zurückgegriffen werden. alternativ wurde (wird?) diskutiert, ob nicht progressive seiten wie riseup, indymedia, nadir, activix etc. ein gemeinsames root-zertifikat aufsetzen. das würde aber das problem nicht wirklich lösen, da es wieder ein außerhalb des web-of-trust stehendes root-zertifikat wäre und damit wieder die warnmeldung kommt solange das entsprechende root-zertifikat nicht installiert wird.

 bisher wird ssl bei de.indymedia nur fürs veröffentlichen benutzt 

bei de.indymedia war die sicherheitspolice daher bisher so, dass ja nur leute, die veröffentlichen wollen sich damit auseinander setzen müssen.

 

Nebbisch. Jeder der dort kommentiert muß das via SSL tun. Und was heißt über haupt "nur veröffentlichen"? Gerade das veröffentlichen sollte besonders geschützt sein.

"gerade das veröffentlichen sollte besonders geschützt sein"

äh ja... ist es ja auch. sogar besonders besonders, weil alles andere (surfen) nicht geschützt ist.

und nu?

und fällt kommentare veröffentlichen nicht auch unter veröffentlichungen?

willst du nur stänkern oder verstehe ich dein post einfach nicht?

die frage, ob ein selbstgezeichnetes zertifikat benutzt wird oder auf eine kommerzielle zertifizierungsstelle zurück gegriffen wird ist eine politische.

Nicht ganz. Bei einem selbstsignierten Zertifikat erhälst du eine Warnung, die du vermutlich (wie viele andere auch) einfach wegklickst. Wer sich dieses Wegklicken von Warnungen angewöhnt, fällt einfach auf Man-in-the-Middle-Attacken herein. Um solch eine Attack sonst durchzuführen, müssten AngreiferInnen dir ein von einer bei dir installierten Certificate Authority signiertes Zertifikat unterschieben, was nochmal eine Stufe schwieriger ist.

Allgemein ist SSL "broken by design". Alexander Heidenreich hat einen guten Artikel dazu geschrieben.

Was übrigens auch schon seit spätestens letztem November abgeschaltet gehört its RC4. Das gilt als kompromittiert

http://www.heise.de/security/meldung/Web-Seiten-von-Bund-und-BSI-mit-gef...

 

Alle vier erfordern eine Verschlüsselung mit RC4, die man heutzutage eigentlich nicht mehr einsetzen sollte. "Die Stromchiffre RC4 hat bekannte kryptographische Schwächen" erklärt das BSI in seiner sehr guten Technischen Richtlinie für Kryptographische Verfahren. Die folgende Einschätzung, dass diese "nicht zu praktischen Angriffen führen" darf allerdings mittlerweile als überholt gelten. Nach aktuellen Erkenntnissen sollte man vielmehr davon ausgehen, dass die NSA die RC4-Verschlüsselung in Echtzeit knacken kann.

 

sslscan --no-failed linksunten.indymedia.org|grep RC4
Accepted SSLv3 128 bits ECDHE-RSA-RC4-SHA
Accepted SSLv3 128 bits RC4-SHA
Accepted TLSv1 128 bits ECDHE-RSA-RC4-SHA
Accepted TLSv1 128 bits RC4-SHA
SSLv3 128 bits ECDHE-RSA-RC4-SHA
TLSv1 128 bits ECDHE-RSA-RC4-SHA

sslscan --no-failed posting.de.indymedia.org|grep RC4
Accepted SSLv3 128 bits RC4-SHA
Accepted SSLv3 128 bits RC4-MD5
Accepted TLSv1 128 bits RC4-SHA
Accepted TLSv1 128 bits RC4-MD5

Das ist eine bewusste Entscheidung. Wir hatten RC4 deaktiviert, aber dann konnten BenutzerInnen von alten Versionen des Internet Explorers die Seite nicht mehr aufrufen. Diese Browser sind leider immer noch sehr verbreitet, zum Beispiel in Internet-Cafés. Deshalb haben wir RC4 als Fallback-Cipher behalten.

danke für diese erklärung, sie zeigt schön auf, worin das dilemma liegt.

die admins von riseup, indymedia und co können euch nicht sicher machen!

sie können nur es von ihrer seite "so sicher wie möglich" machen. wenn ihr mit einem alten browser surft, euer betriebssystem offen wie ein scheunentor ist, gleichzeitig natürlich auch skype läuft weil ja so praktisch etc. pp. dann kann all das all die sicherheitsbemühungen der admins ad absurdum führen.

die informationspolitik sollte das immer im auge haben, da sich nutzende sonst in falscher sicherheit wiegen.

und genau da liegt die krux:

je sicherer es von admin-seite gemacht wird, desto unkomfortabler wirds für die nutzenden.

das sicherste für eine seite wie indymedia wäre, alles nur noch über das tor-netzwerk zu erlauben (mindestens das veröffentlichen von beiträgen) und da dann dementsprechend restriktiv vorgehen. z.b. über einen hidden-service (die aber durch heartbleed auch betroffen sind).

das allerdings würde so viele nutzende ausschließen, dass der anspruch, möglichst viele nutzende zu erreichen, aufgegeben werden muss. nur ein bruchteil der nutzenden benutzt doch überhaupt tor, davon wiederum ein bruchteil weiß, was ein hidden service ist.

und dann macht indymedia keinen sinn mehr.

das beispiel mit rc4 ist da geradezu ein paradebeispiel für. die nachteile wurden ja vom linksunten admin schön veranschaulicht mit dem internet-cafe.

allerdings ists fraglich, ob dann überhaupt noch verschlüsselt werden braucht und ob nicht eine warnmeldung im browser reichen würde, dass entgegen der sicherheitsrichtlinien gerade unverschlüsselt gepostet wird weil das eigene system (bzw. der browser im internetcafe) es nicht zulässt zu verschlüsseln.

quintessenz: die verantwortung der nutzenden über ihr verhalten im netz kann nicht von admins aufgefangen werden.

Es kommt aber immer drauf an, gegen wen mensch sich verteidigen will. RC4-Verschlüsselung ist immer noch besser als keine Verschlüsselung, dann kann vielleicht wenigstens der Nachwuchsblackhat am Nachbartisch im Internetcafé nicht mitlesen.

geht an meiner kernaussage vorbei.

denn wenn von admins aus immer nur kommuniziert wird, alles sei sicher, dann wähnt sich der user sicher.

auch mit internet explorer uralt.

"die von linksunten haben das doch sicher gemacht" funktioniert einfach nicht. es sei denn es wird so restriktiv, dass der internet-cafe-user und auch der normale user draußen bleiben weil sie nicht wissen, was sie machen müssen.

Ob man sich nun an den unvorsichtigsten Zeitgenossen im Kundenkreis orientieren sollte, die mit TOTAL unsicheren Clients an TOTAL unsicheren Orten unterwegs sind? Wer mit einem Fahrrad mit abgefahrenen Reifen und vorne und hinten jeweils nur einer Bremsbacke am Straßenverkehr teilnimmt handelt auf eigene Verantwortung und es besteht kein Grund wegen ihm die Höchsgeschwindigkeit auf 10km/h abzusenken

Heartbleed hat nun immerhin bewirkt das ihr ein neues Zertifikat ausgestellt habt. Im vorherigen war nämlich der RC4 Rotz als "Preffered" eingestellt, was dazu führte, das man diese unsichere Methode im Browser nicht ausstellen konnte, weil man ansonsten auf linksunten gar nicht mehr zugreifen konnte. Fakt ist das ihr das Problem Monate ignoriert habt.

In einem Zertifikat kann kein Cipher als "Preffered" eingestellt werden, das ist eine Einstellung des Webservers (bzw. bei uns des SSL-Offloaders). Diese Einstellung wurde aber gar nicht geändert und deshalb lässt sich, um in deinem Jargon zu bleiben, dein Kommentar in einem Wort zusammenfassen: Rotz.

Ich habe seit Monaten RC4 im Browser ausgeschaltet und hatte bisher keine Probleme mit linksunten.

Erst behauptest du, dass eine auf RC4 basierende Cipher Suite bei Indymedia linksunten als "Preffered" eingestellt gewesen sei. Das ist falsch, denn mein Browser hat nach der Umstellung von linksunten auf Perfect Forward Secrecy als Verschlüsselungsalgorithmus TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 genutzt. Der basiert auf AES und benutzt den als sicher geltenden SHA256-Hash. Wie kommst du zu deiner Behauptung?

 

Weiter behauptest du, dass RC4 sogar der einzige Verschlüsselungsalgorithmus gewesen wäre, der vor dem Heartbleed-Bug von Indymedia linksunten angeboten wurde, denn mit deaktiviertem RC4 konnte "man ansonsten auf linksunten gar nicht mehr zugreifen". Das ist eine falsch, denn ich hatte RC4 ausgestellt und konnte dennoch auf linksunten zugreifen.

 

Im nächsten Satz machst du einen schwerwiegenden Vorwurf: "Fakt ist das ihr das Problem Monate ignoriert habt." Dieser Vorwurf basiert auf den falschen Fakten, die du zuvor aufgezählt hast. Als Schlussfolgerung ergeben sich für mich zwei Möglichkeiten: du hast technisch wenig Ahnung und machst anmaßende Vorwürfe. Oder du lügst und versuchst linksunten zu diffamieren. Beides macht dich unglaubwürdig und unsympathisch.