datenritter blog

Aufgrund der schon etwas älteren Einträge zu Mailman-ssls hier und hier wurde ich gefragt, wie der aktuelle Stand des Projekts sei.

Wer auf dem Laufenden bleiben will, sollte sich diese Mailingliste abonnieren: https://ulm.ccc.de/cgi-bin/mailman/listinfo/ssls-dev — da tut sich noch was.

Der Mailman-ssls-Patch vom 18.07.2009 enthält Fehler. Mails können unverschlüsselt versandt werden, wenn der Schlüssel des Empfängers ungültig ist, obwohl im das Webinterface "Force" (erzwingen) ausgewählt wurde. Außerdem können Administratoren keine Schlüssel austauschen, beim Austragen eines Mitglieds wird der alte Schlüssel nicht gelöscht. Die ersten beiden Fehler sind mit dem folgenden Patch gegen das hier verlinkte Sourcecode-Paket leicht zu beheben:

"Mailman-ssls 2.1.12 kleinere Bugfixes" ... »

In diesem Eintrag zu Mailman-ssls ist der gepatchte Code in Version 2.1.11 verlinkt.
Hier nun die neue Version: mailman-ssls-2.1.12.tar.bz2 herunterladen.

Und noch zwei Ergänzungen:

• Ich würde beim configure-Durchlauf noch --with-mail-gid=nogroup anhängen, um Ausführungsproblemen vorzubeugen.

• Unbedingt beachten: Nur die englischen Templates der Weboberfläche wurden gepatcht. Die deutsche Oberfläche erlaubt es nicht, öffentliche Schlüssel der Listenteilnehmer einzutragen, und Mailman-ssls treibt Admins, die es auf anderen Wegen versuchen, in den Wahnsinn.

Für verschlüsselte Mailinglisten gibt es verschiedene Ansätze. Leicht ist das Leben, wenn man Mailman-ssls einsetzt. Die erweiterte Version kann all das, was die verbreitete Mailingslistensoftware Mailman auch kann, beherrscht zusätzlich aber diverse Verschlüsselungsfeatures.

Mails an die Liste werden nur noch mit dem Listenschlüssel verschlüsselt, Mailman-ssls entschlüsselt die Mails und verschlüsselt sie dann wieder für jeden Abonnenten einzeln. Nicht verschlüsselte Mails können abgelehnt werden, Empfänger ohne Schlüssel bekommen keine Kopie. Natürlich müssen die öffentlichen Schlüssel der Empfänger dem Server zur Verfügung stehen. Mailman-ssls hat dafür eine Verwaltungsfunktion.

Der große Vorteil von Mailman-ssls ist, dass die Listenteilnehmer nicht die Schlüssel aller anderen haben müssen oder gar selbst in ihren Mailprogrammen Listen pflegen. Den Komfortgewinn bezahlt man mit ein wenig Zentralismus, was auch ein Nachteil ist, denn der Server muss unbedingt absolut sicher sein, sonst könnten alle Listenmails offengelegt werden. Das heißt, er muss vor Hackerangriffen, aber auch vor physikalischem Zugriff sicher sein. Wie so oft läuft das schnell auf die Frage hinaus, ob man seinem Hoster vertraut, doch dies soll hier nicht diskutiert werden.

Erhalten bleibt auf jeden Fall der Vorteil, dass Mails auf der eigenen Festplatte verschlüsselt abgelegt bleiben, Angriffe gegen einzelne Teilnehmer einer Cryptoliste sind also nicht erfolgversprechender als sonst auch. Mailman-ssls führt aus Sicherheitsgründen standardmäßig kein Archiv und beherrscht OpenPGP-Schlüssel genauso wie X.509-Zertifikate.

Leider hat sich die Einrichtung auf einem Debian-System als etwas schwierig erwiesen, den weiten Weg zum Ziel fasse ich in diesem HowTo zusammen. "verschlüsselte Mailinglisten mit ... »

Die Förde-Sparkasse verteilt nicht nur Server-Fingerprints auf Papier, sie zeigt auch rechtzeitig die neuen Fingerprints auf der Webseite an:

Der Ihnen bekannte Fingerabdruck (Fingerprint) verliert demnächst seine Gültigkeit. Damit Sie auch weiterhin die Zertifikatsprüfung durchführen können, teilen wir Ihnen nachfolgend den zukünftig gültigen Fingerabdruck mit. Bitte drucken Sie sich diesen aus.

Das ist wirklich vorbildlich.

Das kam jetzt natürlich völlig überraschend: Laut einer Meldung im heise-Newsticker und dem zugehörigen Artikel in der c't 13/08 benutzen viele Webshops Server-Zertifikate mit schwachem Schlüssel.

Bei einer Untersuchung von über 4300 gültigen Zertifikaten, die im Browser keine Warnung erzeugten, fand c't, dass etwa jedes dreißigste einen solchen schwachen Schlüssel nutzt. Darunter fanden sich auch Online-Shops, die zum Beispiel zur Eingabe von Kreditkartennummern auffordern.

(...)

Alle von c't befragten CAs erklärten, man könne bei ihnen schwache Zertifikate kostenlos widerrufen und durch neue ersetzen lassen. Doch offenbar machen von dieser Möglichkeit bislang nur wenige Zertifikatseigner Gebrauch.

Die Shop-Betreiber sind vermutlich nicht gerade Spezialisten, was OpenSSL angeht. Die Frage ist, wo sie ihre Zertifikate her haben, und warum sie nicht gewarnt werden. Möglicherweise weil die entsprechenden Dienstleister nicht besonders pflichtbewusst sind, oder das Problem nicht verstanden haben.

Doch selbst ein Widerruf der schwachen Zertifikate schafft das Problem nicht aus der Welt. Denn die meisten aktuellen Browser überprüfen die Widerrufslisten in ihrer Standardkonfiguration nicht. (...) Das Online Certificate Status Protocol (OCSP) (...) ermöglicht den Test einzelner Zertifikate. Allerdings unterstützen das viele CAs noch nicht.

So ist es.

Unglaublich, aber heute habe ich zum ersten Mal gesehen, dass eine Bankkundin, die sich für Online-Banking entschieden hat, von ihrer Bank den Fingerprint ihres OpenSSL-Serverzertifikates ausgehändigt bekam.

Die Förde-Sparkasse druckte diesen auf ein Blatt, welches mit den Worten "wichtige Information" überreicht wurde. Dabei steht er offenbar einmal als MD5- und einmal als SHA-1-Fingerprint darauf, doch derart genaue Angaben, die den Kunden verwirren konnten, hat man sich geschenkt. Einer der beiden müsse stimmen, schreibt die Bank lapidar, und das sei ihr gestattet.

Die Förde-Sparkasse wechselt ihre Zertifikate sogar jährlich und zeigt den neuen Fingerprint auf der Online-Banking-Webseite "in einem geschützten Dokument" an. Eine Anleitung zur Überprüfung gibt es auch.

Ob die Sparkassen das schon länger, oder erst seit dem Debian-OpenSSL-Debakel machen, weiß ich nicht, auf jeden Fall ist mir aber von anderen Banken nichts vergleichbares bekannt.

Die Überprüfung des Fingerprints schützt vor Man-In-The-Middle-Angriffen und sogar gegen Unterwanderung der ohnehin zweifelhaften Public-Key-Infrastruktur durch Geheimdienste und andere Kriminelle.

Damit und durch die Aushändigung eines TAN-Blockes gleich in der Filiale hat ausgerechnet die früher(?) als träge und unflexibel geltende ehemalige "Beamtenbank" ihre Konkurrenten in puncto Sicherheit und Komfort mit einem Satz überholt.

Liebe Sparkasse, willkommen in der Gegenwart!

Die Angriffsmöglichkeit durch alte Zertifikate hat sich bestätigt. Laut einem Artikel bei heise Security bestehen zudem die Möglichkeit, dass die Systeme, die mit schwachen Schlüsseln ausgestattet waren, bereits früher angegriffen bzw. belauscht wurden.

Es ist schon übel, dass der heise-Newsticker vorgestern nur am Rande in WWW, der "Wochenschau von Hal Faber" über die bestehende Angriffsmöglichkeit durch das OpenSSL-Debakel berichtete:

Es gibt Leute, die viel davon verstehen und die erklären können, wie selbst unsere Selbsteintreibungs-Software ELSTER davon betroffen ist, dass Revocation Lists für Zertifikate nicht funktionieren: Skalierender Schlüsselrückruf ist ein ungelöstes Problem.

Die von mir hervorgehobene Formulierung suggeriert, dass das schon das Ende der Gefahrenstange sei. Das ist nicht der Fall, es kann auch Online-Banking-Webseiten oder andere sensible Bereiche treffen. Nach einem Hinweis antwortete mir Jürgen Kuri, er werde die Leute bei heise Security noch einmal darauf hinweisen.

Heute erschien dann die Meldung "Tausende deutsche Server laden zum Einbruch ein". Dort wird berichtet, dass viele ihre SSH-Schlüssel noch nicht ausgetauscht haben, Provider ihre Kunden nicht benachrichtigen:

Kurze Stichproben von heise Security enthüllten Erschreckendes: In den Netzen von Root-Server-Providern verwendeten von 1938 erreichbaren SSH-Servern 114 bekanntermaßen schwache Schlüssel – das sind immerhin rund fünf Prozent.

Das ist schlimm, aber wartet, es kommt schlimmer.

Man hat sich bei heise Security auch die Mühe gemacht, einen interessanten Artikel über die verschiedenen Gefahren zu schreiben — leider steht zu befürchten, dass den schon aufgrund der Länge kaum jemand liest. Das ist schade, denn auf Seite drei steht der erschreckende Sachverhalt, vor dem ich warnte, in einem Absatz zusammengefasst:

Insbesondere für Phishing und Pharming sind Originalzertifikate eines Webservers zusammen mit den passenden privaten Schlüsseln Gold wert. Gelänge es einem Phisher, seine Opfer beispielsweise mittels des sogenannten Pharmings seine Opfern per DNS-Spoofing oder untergeschobene Hosts-Einträge auf seine eigene Seite umzudirigieren, so könnte der Anwender den Angriff nicht mehr erkennen. Sein Browser würde anzeigen, dass das Sicherheitszertifikat des Servers zur eingegebenen URI passt und dass es von einer vertrauenswürdigen CA ausgestellt wurde.

Und tatsächlich: Alexander Klink berichtet auf der Mailingliste full disclosure, er habe eine Bank ausgemacht, deren altes Zertifikat schwach war. Das Zertifikat ist noch etwa 3 Jahre gültig - so lange sind Man-In-The-Middle-Attacken auf diese Bank möglich.

Als wäre das nicht genug, erklärt der Artikel auch noch, dass aufgezeichnete verschlüsselte Verbindungen nun nachträglich entschlüsselt werden könnten. Es ist durchaus davon auszugehen, dass immer dann, wenn sensible Daten abgegriffen werden sollten, auch verschlüsselte Verbindungen auf Vorrat aufgezeichnet wurden, gerade im Bereich Industriespionage dürfte das üblich sein.

Doch der wahre Schrecken lauert auf Seite fünf:

Wer immer sich in den vergangenen 20 Monaten die Mühe gemacht hat, eine Datenbank mit (...) öffentlichen Schlüsseln zu pflegen, konnte vermutlich ungefähr ab Oktober 2006 die erstaunliche Beobachtung machen, dass in dieser Datenbank Kollisionen auftreten, wo eigentlich keine passieren dürften. Aufgrund des Geburtstagsparadoxons genügen schon 500 schwache Schlüssel gleicher Länge, um unter ihnen mit rund 95-prozentiger Wahrscheinlichkeit ein Duplikat zu finden. Vom Entdecken eines solchen Duplikats ist es nur noch ein kleiner Schritt, um über den ungefähren Zeitpunkt und den Kontext der betroffenen Schlüssel auf das Debian-Betriebssystem zurückzuschließen und die in dem Zeitraum vorgenommenen Änderungen am Quellcode der kryptographisch relevanten Programmpakete zu untersuchen.

Das ist DESASTRÖS. Denn es ist mehr als wahrscheinlich, dass Kriminelle, Geheimdienste, vielleicht auch andere Organisationen Schlüssel gesammelt und das Problem bereits vor langer Zeit bemerkt und für Einbrüche und Lauschaktionen genutzt haben.

Felix von Leitner schreibt in seinem Blog über eine wirklich gefährliche Angriffsmöglichkeit, die sich aus dem OpenSSL-Debakel ergibt. Alle Verbindungen zu Servern, die ein "schlechtes" SSL-Zertifikat hatten, sind wahrscheinlich immer noch verwundbar. Felix berichtet, dass dies bei einem Server von Akamai der Fall ist, und über Akamai werden Daten für das Steuerprogramm ELSTER übermittelt.

Wie es funktioniert

Die Angreiferin, nennen wir sie Carol, ruft Daten von einer Webseite ab, deren URL mit https beginnt, also über eine SSL-verschlüsselte Verbindung — z.B. beim Online-Banking. Sie erhält dabei das Zertifikat der Webservers, welches sie speichert. Dieses Zertifikat und der geheime Schlüssel dazu sind nun aber mit der kaputten Version von OpenSSL erzeugt worden.

Mit dem Zertifikat und dem enthaltenen öffentlichen Schlüssel alleine kann Carol nichts anfangen, es ist ganz normal, dass man diese übermittelt bekommt. Wichtig ist allerdings, dass das Zertifikat von einer Zertifikatsautorität (CA) signiert wurde, wodurch die Echtheit sozusagen "offiziell" beglaubigt ist.

Der geheime Schlüssel ist außerdem dank des OpenSSL-Fehlers leicht ermittelbar — Carol erzeugt alle möglichen geheimen Schlüssel einfach selbst und prüft, welcher zu dem öffentlichen Schlüssel des Servers passt.

Nun hat Carol also sowohl den geheimen Schlüssel, den eigentlich nur der Server kennen sollte, als auch ein "von offizieller Stelle" signiertes Zertifikat.

Die Zertifikate der "offiziellen Stellen", also der CAs sind in jedem Webrowser vorinstalliert, das heißt jeder Webbrowser erkennt auch das Zertifikat ohne weitere Prüfung oder Abfrage als gültig an, obwohl es unsicher ist:



Natürlich haben die Betreiber die verwundbaren Zertifikate schon ausgetauscht. Aber Carol war schnell, und hat das alte vorher gespeichert, gleich nachdem der OpenSSL-Fehler bekannt wurde. (Zukünftig wird Carol dies automatisieren, ein kleines Programm speichert die Zertifikate während sie im Web surft. Denn vielleicht gibt es nochmal so einen Fehler.)

Zwar überprüft ein Browser das Ablaufdatum, welches unveränderlich im Zertifikat steht und dieses nach einer bestimmten Zeit automatisch ungültig macht, aber das ist schlichtweg noch nicht erreicht.

Dagegen gibt es natürlich auch einen Schutzmechanismus, nämlich zentrale Stellen, die Listen mit vorzeitig für ungültig erklärten Zertifikaten enthalten, sogenannte CRLs (Certificate Revocation Lists). Doch diese Listen muss der Browser auch abrufen.

Tut er aber nicht:



Die Standard-Einstellung des Browsers Firefox ist, keine CRLs abzurufen. Das dürfte bei vielen Programmen so sein, und auch E-Mail-Programme, Homebanking-Programme und Programme zur Übermittlung der Steuererklärung benutzen SSL.

Schaltet man die Prüfung ein, so funktioniert sie möglicherweise nicht, was die Funktion einfach nur lästig macht:



Mit dem privaten Schlüssel und dem signierten Zertifikat kann Carol nun dem Browser irgendeines Users glaubhaft vormachen, ihr eigener (manipulierter) Server sei der Server, dessen Zertifikat sie "übernommen" hat. Sie kann sich also als Mittelsmannfrau in die vermeintlich geschützte Verbindung einklinken, und somit Daten mitlesen, unterdrücken oder gar verändern, also zum Beispiel Schadcode, etwa einen Trojaner, einschleusen.

Man nennt dies eine Man-In-The-Middle-Attacke, kurz MITM. (Oder WITM. Wegen der Gleichberechtigung.)

Der Haken beim PKI-Verfahren

Wie Felix ganz richtig schreibt, ist das ganze Prinzip der PKI, der Echtheitsprüfung durch irgendwelche Zentralstellen, die der User gar nicht kennt, ihnen also auch nicht vertrauen kann, schon allein durch die Zahl der standardmäßig installierten CA-Zertifikate der eigenartigsten CAs höchst zweifelhaft.

Es ist keine Diskriminierung, sondern reine Vernunft, wenn ich sage, dass ich eigentlich nicht möchte, dass die mir völlig unbekannte Stelle "TÜRKTRUST Bilgi İletişim ve Bilişim Güvenliği Hizmetleri A.Ş" (Türkei) oder die"NetLock Minositett Kozjegyzoi (Class QA) Tanusitvanykiado" (Ungarn) Zertifikate für gültig erklärt, mit denen mein Browser verschlüsselte, also vermeintlich sichere Verbindungen aufbaut.

Ich muss überhaupt nicht an Geheimdienste denken, ganz normale Kriminelle werden schon ihre Wege finden, die ein oder andere CA für ihre Zwecke zu missbrauchen.

Was tun?

Das einzige, was Server-Betreiber gegen diesen Angriff tun können, ist das alte Zertifikat dadurch unbrauchbar zu machen, dass sie ihre Domain ändern, bis die alten Zertifikate abgelaufen sind. Dumme Sache.

Benutzer müssen bei vielen Webseiten, die keine "offiziell beglaubigten" Zertifikate haben, ohnehin selbst entscheiden, ob sie das Server-Zertifikat

• nur temporär akzeptieren (es könnte gefälscht sein)
• dauerhaft akzeptieren (sie kommunizieren zumindest immer mit dem selben Server und halten es für unwahrscheinlich, dass Carol dahinter steckt) oder
• verifizieren.

Um diese Entscheidung immer selbst zu fällen, können sie alle CAs, denen sie nicht vertrauen — das werden wohl nahezu alle sein — in den Einstellungen ihrer Software deaktivieren.

Wenn es wichtig ist, und sie das Zertifikat verifizieren müssen, — die Fingerprints überprüfen, in dem sie den Betreiber anrufen.

Bei so etwas wichtigem wie dem Online-Banking oder der Steuerrerklärung z.B. sollte man das unbedingt tun!

Banken und Behörden werden sich natürlich wundern, aber es ist deren Schuld, schließlich schicken die den Kunden zwar stapelweise Papier mit PINs, TANs und iTANs, aber die Fingerprints ihrer Banking-Webseiten und Steuerdatenserver fehlen in den Unterlagen.

Aus bekannten Gründen müssen auch X.509-Zertifikate, welche zwischen September 2006 und Mai 2008 auf Debian-Systemen erzeugt wurden, neu generiert werden.

Mit EASY-RSA, einer Sammlung von Scripten aus dem OpenVPN-Paket, oder TinyCA, einem Frontend für OpenSSL, bekommt man zwar relativ leicht seine eigene Zertifikats-Hierarchie aufgebaut. Doch alle mir bekannten OpenSSL-Howtos zur manuellen Vorgehensweise sind eher mittelmäßig, da oft wichtige Details untergehen oder ganz fehlen und die Konfigurationsdateien chaotisch sind. Und über die Man-Pages der OpenSSL-Werkzeuge kann man bestenfalls sagen, dass sie eine gute "Idiotenbremse" sind.

Nicht jede in diesem Howto gezeigte Einstellung ist auch nötig oder hundertprozentig korrekt. Die verwendeten Parameter ermöglichen aber eine schnelle und systematische Erzeugung der Zertifikate, und die Konfigurationsdateien sind lesbar. "eigene X.509-Zertifikats-Hierarchie mit ... »