SSL/TLS

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.

Ein Wort zur Nacht – bzw. zur Sinnhaftigkeit der PKI.

Momentan im Fokus der Medien ist der Wurm "Stuxnet", der Industrieanlagen mit Steuersystemen der Firma Siemens angreift. In der FAZ hat Frank Rieger etwas darüber geschrieben. Und in seinem Blog. Bei heise gab's schon vor ein paar Tagen was dazu. Und wired.com hat ebenfalls einen längeren einen Artikel. Aus diesem möchte ich nur einen Satz zitieren:

The malware is digitally signed with legitimate certificates stolen from two certificate authorities.

Ende der Durchsage.

So, nun wird diese ganze SSL-Problematik langsam unheimlich.

Erklärung: http://blog.fefe.de/?ts=b544bbc7.

Konsequenz:



Und unter Debian:



Grmbl.

Gulli berichtet:

Eine neue wissenschaftliche Arbeit kommt zu dem Schluss, dass die US-Regierung mit vielen SSL-Zertifizierungsstellen kooperiert, um das Mitlesen verschlüsselter Verbindungen zu ermöglichen.

Die IT-Sicherheitsforscher Christopher Soghoian und Sid Stamm kommen zu dem Schluss, dass die Regierung vielfach die Schlüssel von SSL-Zertifikaten von den Zertifizierungsstellen (Certificate Authorities - CAs) erhält. So können sie Websites vortäuschen und die Benutzer in Sicherheit wiegen. Mit Hilfe von Forensik-Tools können sogenannte Man-in-the-Middle-Angriffe sogar automatisiert durchgeführt werden. Die Konsequenz: die US-Regierung ist offenbar in der Lage, routinemäßig SSL-Verbindungen mitzulesen, ohne den Schlüssel knacken zu müssen.

Es ist absolut nicht überraschend, dass eine Zertifikatsautorität für "Bedarfsträger" falsche Zertifikate ausstellen kann, das sieht der X.509-Standard so vor.

Stand hier schon 2008.

Und wie schon erwähnt erzählt Dan Kaminsky einiges dazu in seinem Vortrag auf dem 26C3.

Dass eine Regierung von dieser Möglichkeit Gebrauch macht ist eine Selbstverständlichkeit. Wenn eine Vertrauensstelle in einem System vorkommt, sei es eine Bank, ein Offizier, ein Programmierer oder eben eine Zertifikatsauthorität, dann ist diese immer ein möglicher Angriffspunkt, daran lässt sich auch kaum etwas ändern. Aber X.509 setzt darauf, dass wir den Autoritäten vertrauen, denen die Browserlieferanten vertrauen. Allen. Allen gleichzeitig. Selbst schuld.

Ich sag nix mehr zu SSL bzw X.509. Es ist einfach schlimm. Fefe fasst es prima zusammen:

(...) die Israelis (...) bieten einen SSL-Zertifikat-Dienst an, der auch den privaten Schlüssel für dich generiert. How convenient! Und sie haben plausible deniability, weil es auch einen Button zum Hochladen seines eigenen CSR gibt. (...)

Das ist noch besser, als ein schnöder Man-in-the-middle-Angriff, den sowieso jede von den gängigen Browsern anerkannte Zertifikatsautorität spielen kann. So hat man nicht nur gültigen Ersatz, sondern gleich das Original. Ich bin mit den Details des TLS-Verbindungsaufbaus nicht so vertraut, vermute aber mal, dass man damit sogar nachträglich noch den halben aufgezeichneten Datenstrom entschlüsseln kann. Wer das Angebot annimmt, ist selbst schuld.

Wer das technische Verständnis hat, kann sich ja auch die Aufzeichnung von Dan Kaminskys Vortrag auf dem 26C3 ansehen. Er beschäftigt sich mit ein paar Problemchen der X.509-PKI. Und da bleibt kein Stein auf dem anderen.

Ironie: Beim Aufruf von https://events.ccc.de/congress/2009/Fahrplan/events/3658.en.html bekomme ich eine Warnung, weil das Zertifikat des Servers eine MD5-Signatur hat. Arrg!

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 Problem mit den ePässen ist offenbar, dass die Terminals selbstsignierte Daten akzeptieren. (Siehe auch: heise-Meldung.) Das lässt sich leicht ändern, in dem man Signaturen zwingend verlangt.

Doch der Beitrag über den schon erwähnten Hack des elektronischen Personalausweises, erklärt sehr prägnant, warum die Zertifikatsautoritäten einer Publik-Key-Infrastruktur (PKI) selbst ein ernsthaftes Problem sein können. Die Kritik lässt sich auf andere Einsatzfelder der PKI anwenden, zum Beispiel bei SSL-geschützten Webseiten:

Using a Certification Authority (CA) could solve the attack but at the same time
introduces a new set of attack vectors:

1. The CA becomes a single point of failure. It becomes the juicy/high-value target for the attacker.
Single point of failures are not good. Attractive targets are not good.

Das ist die wichtigste Erkenntnis: Die Zertifikatsautorität (CA) ist der "single point of failure" und ein hochwertiges Ziel für einen Angreifer.

Any person with access to the CA key can undetectably fake passports. Direct attacks, virus,
misplacing the key by accident (the UK government is good at this!) or bribery are just a few
ways of getting the CA key.

Ich übersetze mal sinngemäß: Wer auch immer Zugang zum Schlüssel einer CA hat kann unbemerkt Ausweise fälschen. Durch direkte Angriffe, Viren, irrtümliche Preisgabe des Schlüssels oder Bestechung könnte man an den Schlüssel gelangen. Dass gelegentlich USB-Sticks, Festplatten, ja sogar Kameras mit geheimen Daten in Umlauf gelangen, dürfte bekannt sein.

Nun folgen ein Punkt, der zu Diskussionen führt und nicht oberflächlich betrachtet werden darf:

2. The single CA would need to be trusted by all governments. This is not practical as this
means that passports would no longer be a national matter.

Dass es keine multinationale CA geben kann, ist offensichtlich, doch:

3. Multiple CA's would not work either. Any country could use its own CA to create a valid
passport of any other country. (...)

Diese Behauptung ist die am häufigsten kritisierte und gilt vermutlich nur für schlecht aufgesetzte ePass-Terminals. Selbst wenn alle Terminals derart nachlässig sind, wird man dies bald ändern. Doch gilt sie uneingeschränkt für SSL-Zertifikate, z.b. für Webseiten, denn ein Browser kann nicht wissen, welche CAs für meine Bank zuständig sein sollen und welche nicht.

Und für den ePass gilt:

This option also multiplies the number of 'juicy' targets. It makes it also more likely for a CA key to leak.
Revocation lists for certificates only work when a leak/loss is detected. In most cases it will not be detected.

Denn es kommt bei einer Fälschung vielleicht nicht unbedingt darauf an, aus welchem Land der falsche Pass stammt.

Sicher ist:
• Die Pässe sind beschreibbar. Man kann also die Daten einer anderen (z.B. ähnlich aussehenden) Person auf den eigenen Chip schreiben — inklusive der gültigen Signatur.
• Angriffe auf CAs sind außergewöhnlich lohnend.
• Viele CAs sind viele Angriffsmöglichkeiten. Zu viele.
• Rückruflisten helfen nur, wenn die Fälschung überhaupt bemerkt wird. Das ist sehr unwahrscheinlich.

Ich empfehle als Notbehelf für den ePass die Mikrowelle. Sie verhindert wenigstens, dass ein Dritter die eigenen Daten ausliest und verwendet. Für Webseiten gibt es auch weiterhin keine einfache Lösung, außer der händischen Prüfung des Fingerprints.