Skip to content

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.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : SSL: Flammen am benzingetränkten Kartenhaus

"SSL: Flammen am benzingetränkten Kartenhaus" vollständig lesen
Die Meldungen über Angriffe auf Zertifizierungsstellen (Certificate Authority, CA) und kompromittierte SSL-Zertifikate reißen nicht ab: In der vorigen Woche hat eine CA die Ausgabe von Zertifikaten eingestellt, einer anderen wurde von Micr

Dipl.-Inform. Carsten Eilers am : Neues zur Sicherheit von Webservern und -anwendungen, Teil 2

"Neues zur Sicherheit von Webservern und -anwendungen, Teil 2" vollständig lesen
Weiter geht es mit Informationen über interessante Vorträge zum Thema "Websecurity" auf den verschiedenen Sicherheitskonferenzen 2011. Den Anfang machen Vorträge rund um SSL: Moxie Marlinspike: SSL And The Future Of Authenticity

Dipl.-Inform. Carsten Eilers am : RSA und die schwachen Schlüssel, Teil 3: Die Gefahren

"RSA und die schwachen Schlüssel, Teil 3: Die Gefahren" vollständig lesen
Im ersten Teil haben Sie erfahren, wie RSA funktioniert, im zweiten Teil wurden die Forschungsergebnisse von Arjen K. Lenstra und seinen Kollegen vorgestellt. Im Folgenden werden weitere Forschungsergebnisse vorgestellt, außerdem geht es u

Dipl.-Inform. Carsten Eilers am : Apple geg. Kaspersky, Angreifer geg. PHP, Irgendwer geg. den Iran, und mehr

"Apple geg. Kaspersky, Angreifer geg. PHP, Irgendwer geg. den Iran, und mehr" vollständig lesen
Heute gibt es mal wieder eine bunte Mischung an Kommentaren: Apple erlaubt keine Virenscanner im App-Store, es gibt Angriffe auf die PHP-CGI-Schwachstelle, Yahoo! veröffentlicht einen privaten Schlüssel, eine Verbesserung für TLS soll

Dipl.-Inform. Carsten Eilers am : SSL - Der nächste Nagel im Sarg?

"SSL - Der nächste Nagel im Sarg?" vollständig lesen
Es gibt mal wieder schlechte Nachrichten über SSL. Diesmal wurde mal keine Zertifizierungsstelle gehackt, stattdessen haben Forscher festgestellt, dass die Prüfung von Zertifikaten in anderer Software als Webbrowsern ziemlich mangelhaft

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Smart Media am :

Man kann auch NoSSL verwenden. Funktioniert gut und einfach und ist noch kostenlos. Einziger Nachteil: kein Schutz gegen Man-in-the-middle attack.

Carsten Eilers am :

Ohne Schutz vor MitM-Angriffen kann man die Verschlüsselung auch gleich ganz bleiben lassen. Die wiegt die Benutzer dann nur in falscher Sicherheit.

NoSSL ist ein Aufruf "Greift mich an, hier gibt es was zu holen aber ich kann es nicht adäquat schützen".

Und "noch kostenlos" ist ein Totschlagargument - was kostet es denn mal? Will man das dann zahlen?

Kommentar schreiben

Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt

Kommentare werden erst nach redaktioneller Prüfung freigeschaltet!