Dipl.-Inform. Carsten Eilers

Jacob Appelbaum vom Tor Project vergleicht das bestehende Zertifizierungssystem mit einem benzingetränkten Kartenhaus:

"The Certificate Authority system as it stands today is a house of cards and we're witnessing in public what many have known for years in private. The entire system is soaked in petrol and waiting for a light."

Ich würde sogar so weit gehen und sagen, es glimmt zumindest an einer Ecke schon etwas. Und damit stellt sich die Frage, wie um alles in der Welt man ein Kartenhaus löscht, ohne es gleichzeitig zu zerstören. Evtl. ist es besser, das Kartenhaus kontrolliert abbrennen zu lassen und gleichzeitig ein neues, stabileres Haus zu bauen. Wobei das "kontrolliert abbrennen lassen" ja eigentlich schon begonnen hat, da mit DigiNotar einer nicht (mehr) vertrauenswürdigen CA das Vertrauen entzogen wurde.

Gibt es Alternativen?

Aber wie sieht es denn mit dem Bau eines neuen Hauses aus? Im Grunde gibt es zwei bekannte Ansätze, um "Vertrauen" aufzubauen: Zum einen hierarchische Zertifizierungssysteme wie das, das uns da gerade um die Ohren geflogen ist, zum anderen das "Web of Trust", wie es z.B. PGP/GPG verwendet. Das ist mit einem Reputationssystem vergleichbar: Je mehr man den Unterschriften unter einem Schlüssel vertraut, desto mehr Vertrauen bringt man auch dem Schlüssel entgegen.

Eine dritte Möglichkeit besteht darin, zusätzliche Informationen zur Entscheidungsfindung hinzuzuziehen. Im Fall von SSL kann dafür z.B. DNSSEC verwendet werden: Während der Schutz der Kommunikation wie gehabt von SSL übernommen wird, wird für die Prüfung der Identität der aufgerufenen Website DNSSEC hinzugezogen. DNSSEC stellt allerdings nur sicher, dass die von DNS-Server gelieferte IP-Adresse tatsächlich zum gewünschten Domainnamen gehört. Ob die Daten dann wirklich beim richtigen Server landen, ist ein anderes Problem.

SSL meets DNSSEC

Robert "RSnake" Hansen hat sich schon im Oktober 2009 Gedanken über die Absicherung der Transportschicht mit Hilfe von DNSSEC gemacht. Sein Vorschlag (der anderswo bereits davor diskutiert wurde): Man könnte ins DNS auch die Zertifikate für die Absicherung der Transportschicht aufnehmen, so dass die ebenfalls über DNSSEC geschützt sind. Dan Kaminsky hat in einem Kommentar zu RSnakes Vorschlag darauf hingewiesen, dass das DNS (und damit auch DNSSEC) einen entscheidenden Vorteil im Vergleich zum bestehenden CA-System für SSL hat: Auf dem Root-Level gibt es immer nur genau eine Root und nicht wie im Fall der SSL-CAs (viel zu) viele. Für jede Top Level Domain gibt es genau ein Unternehmen, dass für die Wurzel zuständig ist, im Fall von z.B. .com ist das Verisign. Wer einen DNSSEC-Eintrag für google.com fälschen möchte, muss also Verisign erfolgreich angreifen. Selbst wenn wie im aktuellen Beispiel DigiNotar das Opfer die Root für die TLD .nl verwalten würde, hätte der Angreifer dadurch nichts erreicht (außer den Eintrag für z.B. google.nl fälschen zu können).

In seinem eigenen Blog hat Dan Kaminsky im Dezember 2010 beschrieben, wie ein öffentlicher Schlüssel im DNS gespeichert werden kann. Eine mögliche Implementierung ist im von ihm entwickelten DNSSEC-Proxy Phreebird enthalten. Statt vollständiger Zertifikate wird dabei nur ein Verweis auf das Zertifikat im DNS gespeichert und per DNSSEC geschützt.

In Chromium wurde ebenfalls bereits 2010 "DNSSEC and TLS" implementiert, inzwischen ist die Implementierung auch in Chrome angekommen. Im wesentlichen ist das aber nur für Websites brauchbar, die zum einen mit selbst signierten Zertifikaten auskommen und zum anderen kein Problem damit haben, dass die anderen großen Browser mit dieser Lösung (noch?) nicht arbeiten können.

Vertrauen nur für den, der Vertrauen verdient

Ein Reputationssystem ist auch das von Moxie Marlinspike auf den Konferenzen Black Hat USA 2011 und DEF CON 19 vorgestellte 'Convergence'. Den Black Hat Vortrag "SSL And The Future Of Authenticity" gibt es als Video auf threatpost und YouTube. Ein Paper und/oder die Präsentationen wurde leider (noch?) nicht veröffentlicht.

Convergence ist aus dem Perspectives Project der Carnegie Mellon University hervorgegangen und baut auf einem "Web of Trust" auf. Ein benötigtes SSL-Zertifikat wird direkt geladen, gleichzeitig wird eine Reihe von vertrauenswürdigen sog. 'Notaries' gebeten, das Zertifikat ebenfalls zu laden und an den Benutzer zu schicken, der alle erhaltenen Zertifikate dann miteinander vergleicht. Ein Angriff würde beim Vergleich auffallen, da nicht alle Zertifikate überein stimmen. Als zusätzliche Sicherheitsstufe wird bei der Anforderung der Zertifikate von den Notaries ein Proxy-Notary zwischengeschaltet, so dass die Notaries nicht wissen, wer die Zertifikate anfordert.

Kern von Convergence sind die Notaries. Allein der Benutzer entscheidet, welchen Notaries er vertraut, außerdem kann das Vertrauen jederzeit entzogen und neu bzw. zusätzlich vergeben werden. Der Benutzer entscheidet auch, ob ihm ein Notary ausreicht oder ob er das Zertifikat von mehreren Notaries anfordert. Da der Notary-Code ebenfalls veröffentlicht wurde, kann jeder Benutzer selbst z.B. für seine Freunde als Notary auftreten.

Bisher gibt es Convergence nur als unsignierte Firefox-Erweiterung, die noch dazu nur über HTTP von der Projekt-Website geladen werden kann. Es wäre wünschenswert, die Erweiterung wäre signiert und der Download über HTTPS und von addons.mozilla.org möglich. Auch die Dokumentation ist deutlich verbesserungswürdig - bisher besteht sie lediglich aus einer Seite mit "Details", die wenig bis nichts verraten. So bleibt z.B. die Frage offen, ob und wie die Kommunikation mit den Notaries abgesichert wird. Denn wenn das System eingesetzt wird, ist im Falle eines Angriffs auch mit Man-in-the-Middle-Angriffen auf diese Kommunikation zu rechnen.

Alles in allem ist es ein sehr interessanter und vielversprechender Ansatz - wenn er denn ausführlich dokumentiert und auch von anderen Browsern unterstützt wird.

Es gibt also Alternativen zum bestehenden System der CAs - nur sind die bei weitem noch nicht ausgereift. Als vorübergehende Lösung bleibt also eigentlich nur eine Möglichkeit: Die viel zu große Anzahl der per Default als vertrauenswürdig eingestuften CAs muss reduziert werden. Auch wenn das vielen CA-Betreibern nicht gefallen wird.

In der nächsten Folge geht es wie bereits vor einiger Zeit angekündigt um Möglichkeiten zum Manipulieren von Anzeigen aller Art durch Right to Left Override (RLO) Unicode Tricks.

Carsten Eilers