Mit Sicherheit unsicher

Seit Monaten ärgert mich mein Jabber-Client. Seit Wochen ärgere ich mich über Thunderbird, und die seltenen Einsätze von Firefox fördern auch immer wieder wahre Perlen an falsch verstandenen Sicherheitsfunktionen zu Tage. Es geht um selbst ausgestellte Zertifikate für verschlüsselte Verbindungen, und es geht mir vor allem um den Umgang mit diesen Zertifikaten.

Beispiel 1: Psi (Instant Messaging Client)

Ah ja. Stimmt. Das Zertifikat ist sicherlich selbst ausgestellt, schließlich kann und will nicht jeder Anbieter eines Jabber-Servers für Hundert(e) Euro im Jahr ein vertrauenswürdiges Zertifikat von Thawte und Co. kaufen. Als Nutzer interessiert mich doch eigentlich vor allem dreierlei:

1. Ich will die Identität des Servers überprüfen (Authentifizierung).
2. Ich will bei aufeinanderfolgenden Besuchen informiert werden, wenn sich das Zertifikat ändert (Schutz gegen Man in the Middle Angriffe).
3. Verschlüsselung der Kommunikation.

Um Authentifizierung erreichen, gibt es zwei Methoden: Vertrauenswürdige Zertifizierungsstellen befragen oder das Zertifikat selbst überprüfen.

Alle gängigen Webbrowser, E-Mail-Programme und auch Betriebssysteme verfügen über sogenannte Stammzertifikate bestimmter, als vertrauenswürdig eingestufter Zertifizierungsstellen (Thawte, Verisign etc.). Hat ein Betreiber etwa einer Webseite sich erfolgreich bei einem solchen Anbieter ausgewiesen, bekommt er vom Anbieter ein individuelles Zertifikat. Weil dieses zum Stammzertifikat des Anbieters passt, kann der Browser/E-Mail-Client/etc. die Authentifizierung durchführen. Das heißt, nicht ich vertraue dem Serverbetreiber, sondern ich vertraue der Zertifizierungsstelle, dass sie ihm vertraut.

Der Bezug des Zertifikates kostet allerdings eine Menge Geld, weshalb gerade im privaten Bereich oftmals selbst signierte Zertifikate verwendet werden. Dabei macht sich der Betreiber quasi selbst zur Zertifizierungsstelle. Die ist aber natürlich den Browsern und sonstigen Anwendungen nicht bekannt. Deshalb brauche ich vor allem den sogenannten Fingerabdruck des Zertifikates, der üblicherweise als MD5- oder SHA1-Hash angegeben wird. Der Betreiber des Servers veröffentlicht hoffentlich auf seiner Webseite oder per E-Mail ebenfalls den Fingerabdruck. Die beiden Fingerabdrücke kann ich dann vergleichen. Sind sie identisch, dann habe ich relativ große Gewissheit, dass ich tatsächlich mit dem gewünschten Server kommuniziere. Et voila, das ist Authentifizierung.

Ziehen wir kurz die Verschlüsselung vor: Egal mit welchem Server ich da kommuniziere, die Verbindung zwischen Client und Server ist verschlüsselt, und somit kann ich relativ sicher ausschließen, dass irgendjemand verwertbare Inhaltsdaten aus meinem Netzwerkverkehr herauszieht – egal ob mein Mitbewohner, mein Internetprovider oder auch das BKA.

Allerdings habe ich keine Lust, die Authentifizierung jedes Mal zu machen, wenn ich mich mit dem Server verbinde. Computer sind viel besser darin, diese Aufgabe zu übernehmen. Und hier beginnt das Problem: Psi bietet keine Möglichkeit, das Zertifikat dauerhaft als gültig zu akzeptieren. Dabei müsste das Programm lediglich den Fingerabdruck speichern und bei späteren Verbindungsversuchen den Fingerabdruck mit jenem des Server-Zertifikates vergleichen. Unterscheiden sich die Fingerabdrücke, dann hat entweder der Serveranbieter das Zertifikat getauscht, oder ich spreche mit einem ganz anderen Server (vielleicht wird er von meinem Mitbewohner betrieben oder vom Internetprovider oder vom BKA). In beiden Fällen möchte ich als Nutzer nun schauen, was es damit auf sich hat und ggf. den Serveranbieter kontaktieren.

Nun könnte man sagen, gut, das ist eine Schwäche dieses Programms, andere machen das besser. Aber wenn man sich die Situation anschaut, ist es eine äußerst weit verbreitete Unsitte, die hier dargelegten Aufgaben von Server-Zertifikaten falsch zu behandeln.

Beispiel 2: Thunderbird (E-Mail Client)

Thunderbird macht das gleiche wie Psi: Er erkennt (zutreffenderweise) ein Problem mit dem Zertifikat, bietet aber keine Möglichkeit, dieses Problem dauerhaft zu ignorieren und das Zertifikat so lange zu akzeptieren, wie der Fingerabdruck sich nicht ändert. Das bedeutet, dass ich pro Sitzung 2 Mal diesen Dialog wegklicken darf, bevor ich E-Mails lesen bzw. senden kann.

Beispiel 3: Firefox (Webbrowser)

Auch Firefox erkennt korrekterweise, dass hier kein Zertifikat einer der bekannten Certificate Authorities verwendet wird. Nun muss man den Entwicklern zu Gute halten, dass der schlechte Umgang mit selbst ausgestellten Zertifikaten in der Vergangenheit zu vielen Problemen geführt hat. Vor allem neigen Nutzer dazu, Hinweise auf ungültige oder nicht vertrauenswürdige Zertifkate einfach wegzuklicken oder zu ignorieren und weiterzumachen, als wäre nichts gewesen. Diese User haben das Konzept der Authentifizierung nicht verstanden: Nur wenn ich sicher davon ausgehen kann, dass ich mich mit banking.example.org verbinde und dass die Verbindung verschlüsselt ist, sollte ich dort meine Kontozugangsdaten eingeben. Andernfalls… verdient man sicher gerne Geld, damit es dann von Betrügern abgephisht wird.

Aber erneut: Wenn ich dem Betreiber des Servers vertraue und das Zertifikat anhand des Fingerabdrucks als gültig erkläre, ist für mich alles okay. Seit Firefox 3 ist es aber ein geradezu irrsinniger Aufwand, das dem Browser beizubringen. In ihrem Feldzug gegen ungültige und selbst ausgestellte Zertifikate sind die Firefox-Entwickler meiner Meinung nach völlig über das Ziel hinaus geschossen. Immerhin: Wenn man beharrlich „Jaja, das weiß ich, nerv nicht“ klickt, kann man irgendwann eine persistente Ausnahme hinzufügen, die der Browser sich dann merkt, sodass die Meldung nicht beim nächsten Besuch wieder angezeigt wird. Damit kann ich dann tatsächlich recht sicher Man in the Middle Angriffe ausschließen und erhalte dadurch ein echtes Plus an Sicherheit.

Beispiel 4: Internet Explorer 8 (Webbrowser)

Wenn man glaubt, schlechter geht es nicht… hat Microsoft unter Garantie noch was in petto:

• Es gibt keine Informationen über den Inhalt des Zertifikates.
• Der vom IE selbst angebotene Link zum Schließen des Fensters erzeugt eine Warnmeldung.
• Nach dem nicht empfohlenen Fortsetzen kann ich mir weitere Infos über das Zertifikat anzeigen lassen.

Man kann ja dieser Tage ohnehin berechtigte Zweifel an der Verbreitung des gesunden Menschenverstandes haben, aber dass Microsoft nichts davon abbekommen hat, zählt offenbar zu den wenigen Konstanten des Universums.

Ergo

Worauf ich mit diesem Post hinaus will: Mehr denn je gibt es gute Gründe, möglichst viele Kommunikationskanäle im Internet zu verschlüsseln. Elementarer Bestandteil der Verschlüsselung ist die Authentifizierung der Server, sonst kann ich auch gleich alle meine Passwörter und sonstigen Geheimnisse bei Facebook und Co. kund tun. Der hirnrissige Umgang zahlreicher verschlüsselungsbereiter Programme mit Authentifizierung und langfristiger Kontrolle der Fingerabdrücke bewirkt aber genau das Gegenteil, nämlich dass die Authentifizierung ausbleibt und ich letztlich nicht weiß, an welchem Server sich meine Programme eigentlich gerade anmelden und welchem Server sie dann teils vollautomatisch meine Zugangsdaten mitteilen. Na herzlichen Dank…