Alternativen zum SSL-CA-Zertifizierungssystem
Spätestens seit dem Angriff auf DigiNotar und seinen Folgen dürfte jedem klar geworden sein, dass das bestehende Zertifizierungssystem für SSL-Zertifikate unsicher ist und eine permanente Bedrohung darstellt. Wenn man den Zertifizierungsstellen nicht mehr mehr oder weniger bedingungslos vertrauen kann, bricht das ganze System zusammen.
Ein Benzingetränktes Kartenhaus
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.
Trackbacks
Dipl.-Inform. Carsten Eilers am : SSL: Flammen am benzingetränkten Kartenhaus
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Neues zur Sicherheit von Webservern und -anwendungen, Teil 2
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : RSA und die schwachen Schlüssel, Teil 3: Die Gefahren
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Apple geg. Kaspersky, Angreifer geg. PHP, Irgendwer geg. den Iran, und mehr
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : SSL - Der nächste Nagel im Sarg?
Vorschau anzeigen