datenritter blog - SSL/TLS

Zertifikat? Welches Zertifikat? Ach, das...

nospam@example.com (datenritter) — Tue, 06 Apr 2010 14:39:00 +0200

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

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

Konsequenz:

Root-Zertifikate in Firefox entfernen.

Und unter Debian:

Root-Zertifikate unter Debian aus dem System werfen.

Grmbl.

Wie erwartet: Regierungen lesen SSL-Verbindungen mit

nospam@example.com (datenritter) — Thu, 25 Mar 2010 11:16:00 +0100

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.

X.509 ist kaputt. Ende.

nospam@example.com (datenritter) — Sat, 16 Jan 2010 07:09:00 +0100

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!

Mailman-ssls 2.1.12 kleinere Bugfixes

nospam@example.com (datenritter) — Sat, 22 Aug 2009 13:23:35 +0200

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" vollständig lesen

Mailman-ssls 2.1.12 Sourcecode

nospam@example.com (datenritter) — Mon, 27 Jul 2009 15:39:00 +0200

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.

verschlüsselte Mailinglisten mit Mailman-ssls

nospam@example.com (datenritter) — Wed, 15 Apr 2009 16:24:00 +0200

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 Mailman-ssls" vollständig lesen

Sparkasse zeigt neuen Fingerprint rechtzeitig

nospam@example.com (datenritter) — Mon, 03 Nov 2008 08:52:00 +0100

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.

Zertifikatsautoritäten sind Angriffsvektoren

nospam@example.com (datenritter) — Tue, 30 Sep 2008 21:37:00 +0200

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.

Debian-OpenSSL-Debakel: Problem auf Layer 8

nospam@example.com (datenritter) — Tue, 10 Jun 2008 14:31:00 +0200

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.

Sparkasse verteilt Server-Fingerprints auf Papier

nospam@example.com (datenritter) — Mon, 09 Jun 2008 16:36:00 +0200

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!