zurück zum Artikel

Richtig verschlüsseln mit Firefox 3

Jürgen Schmidt

Bei Firefox 3 hat das Mozilla-Team den Umgang mit Zertifikaten überarbeitet, leider nicht immer zum Besseren. Doch ein paar Handgriffe schaffen mehr Komfort und letztlich auch mehr Sicherheit.

Normalerweise geht im Web erst mal alles im Klartext über die Leitung - auch wenn es sich dabei um kritische Informationen wie Passwörter oder Kontodaten handelt. Will man ungewollte Mitleser aussperren, müssen die übertragenen Daten verschlüsselt werden. Im Web erkennt man den Einsatz von Verschlüsselung daran, dass die URL in der Adressleiste mit "https" ("s" wie sicher) statt "http" beginnt.

Dabei muss man allerdings ganz sicher sein, dass sich am anderen Ende der Leitung tatsächlich der richtige Empfänger befindet. Die beste 256-Bit-AES-Verschlüsselung nutzt nichts, wenn dort der Angreifer sitzt und man ihm den Schlüssel somit frei Haus liefert. Deshalb lassen sich Betreiber eines Servers ihre Identität von einer vertrauenswürdigen Zertifizierungsstelle (CA) bestätigen. Deren digitale Unterschrift kann der Browser überprüfen und dann dem Anwender signalisieren, dass er sich auf der richtigen Website befindet.

Bis Version 2 tat Firefox dies, indem er die komplette Adresszeile gelb einfärbte und mit einem Schloss versah. Wenn man das einmal wusste, war es kaum zu übersehen und das Fehlen von Gelb und Schloss war ein deutliches Signal für fehlende Verschlüsselung. Seit Version 3 konzentriert sich Mozilla - wie im Übrigen auch Microsoft mit Internet Explorer 7 - auf die sogenannten Extended Validation (EV) Zertifikate.

Bei denen versprechen die Zertifizierungsstellen, die Identität des Antragstellers genauer zu prüfen; technisch unterscheiden sich EV-SSL-Zertifikate jedoch nicht von herkömmlichen SSL-Zertifikaten. Da EV-Zertifikate recht teuer sind, konnten sie sich außer bei Banken bislang nicht durchsetzen. Anfang 2008 zählte Netcraft nur etwas über 4000 weltweit. Von den über 800.000 gültigen, also von Standard-CAs unterschriebenen, normalen SSL-Zertifikaten sind das gerade mal 0,5 Prozent.

Favicon ahmt SSL nach

Im Kontext ganzer Seiten verschwindet der Unterschied zwischen dem Favicon und der SSL-Kennzeichnung fast.

Die normalen SSL-Zertifikate kommen somit nach wie vor beim Gros der Online-Shops zum Einsatz, bei denen man persönliche Daten, Kreditkarteninformationen und Ähnliches eingeben muss. Trotzdem behandelt Firefox sie mittlerweile sehr stiefmütterlich. Das beginnt damit, dass das Schloss in der Adresszeile und deren Färbung entfallen. Was bleibt, ist ein kleiner blauer Rahmen um das Favicon der Seite, der sich mit einem gut gemachten Favicon so nachahmen lässt, dass die Täuschung zumindest nicht ins Auge springt.

about:config

Das kann man jedoch leicht verbessern. Dazu muss man die Pseudo-URL about:config aufrufen, wovor Firefox allerdings mit einem "Hier endet möglicherweise die Gewährleistung!" warnt. Nach dem eingeforderten Versprechen, vorsichtig zu sein, führt die Eingabe von identity im Suchfeld zur Einstellung browser.identity.ssl_domain_display deren Wert man von 0 auf 1 setzt.

SSL-Adressleisten

Nach der Änderung zeigt Firefox wie in Zeile 2 die aktuelle https-Domain auf blauem Hintergrund.

Damit gleicht Firefox die Adresszeile von https-Sites der von EVSSL-Sites an, verwendet aber die Farbe Blau statt Grün. Die Verwechslungsgefahr mit ungesicherten Seiten ist damit minimal.

Seiteninformation

Ein weiteres Problem sind die sehr unglücklich gewählten Formulierungen in den weiterführenden Informationen zu https-Sites, die den erweiterten Obulus an Verisign & Co verweigert haben. Trotz des gültigen, von einer Zertifizierungsstelle beglaubigten Zertifikates erhalten die Besucher Meldungen wie diese:

Die widersprüchlichen Aussagen "Diese Website bietet keine Informationen an, um ihre Identität zu bestätigen" und "Diese Website bietet ein Zertifikat an, um ihre Identität zu bestätigen" verwirren den vorsichtigen Anwender statt ihn zu informieren. Nützlicher sind da schon die ebenfalls hinzugekommenen Informationen, ob und wie oft man die Seite bereits besucht hat.

Noch schlimmer als die Sites mit herkömmlichen SSL-Zertifikaten trifft es die Betreiber von Servern, die kein Geld ausgeben und sich ihr Zertifikat von einer Community-basierten Zertifizierungsstelle wie CAcert unterschreiben lassen oder das einfach selber tun. Deren Besucher bekommen mit Firefox 3 nämlich statt einer Warnung, die man wegklicken kann, eine Fehlerseite mit der Überschrift "Sichere Verbindung fehlgeschlagen".

Den Versuch, eine Ausnahme zu definieren, quittiert der Browser zunächst mit dem Hinweis, dass man das besser sein lassen sollte. Damit dürfte ein Großteil der potenziellen Besucher abgewimmelt sein. Nur wer hartnäckig darauf beharrt, eine Ausnahme hinzufügen zu wollen, landet beim nächsten Dialog, wo man das Zertifikat laden kann.

Doch ausgerechnet hier bleiben die sicherheitsbewussten Entwickler auf halbem Weg stehen und versäumen es, darauf hinzuweisen, dass man den Fingerabdruck des Schlüssels überprüfen muss, um sich Gewissheit über dessen Echtheit zu verschaffen.

Dummerweise blockiert die Zertifikatsansicht dann auch noch das Browser-Fenster, sodass man sich nicht einmal im Web weitere Informationen zu den dargestellten Rohdaten verschaffen kann. Und obwohl die meisten Ausnahmen wohl eher "nur mal eben schnell ..." angelegt werden, speichert sie Firefox standardmäßig gleich dauerhaft ab.

Insbesondere im universitären Umfeld wird viel mit selbst signierten Zertifikaten gearbeitet, aber auch firmenintern sehen es Admins oft nicht ein, für die Intranet-Server jährliche Gebühren an eine CA abzuführen. Hier muss man die Anwender möglichst gezielt durch diesen Ausnahmedschungel leiten, um beispielsweise das Zertifikat der Firmen-CA zu importieren. Das Wichtigste dabei ist es, sie dazu zu bewegen, den MD5- oder SHA-1-Fingerabdruck mit vertrauenswürdigen Informationen aus einer unabhängigen Quelle zu vergleichen. Eine E-Mail mit dem Link zum CA-Zertifikat gehört übrigens nicht in diese Kategorie.

Für Endanwender haben Studenten der Carnegie Mellon School of Computer Science ein neues Konzept für sichere Verbindungen im Internet entworfen. Die Grundidee ist, dass aktuelle Browser sehr oft an Zertifikaten etwas auszusetzen haben, aber nur in den allerseltensten Fällen tatsächlich ein konkreter Angriff dahinter steckt. Diese seltenen Fälle will man herausfiltern und die Warnungen darauf beschränken.

Das Belauschen von verschlüsselten Datenübertragungen geschieht meist durch sogenannte "Man in the Middle"-Attacken. Dabei klinkt sich ein Angreifer in die Verbindung zwischen Anwender und Website ein. Dies kann völlig unbemerkt passieren, wenn der Browser die Identität der Website am anderen Ende nicht ausreichend prüft.

Solche MITM-Angriffe erfordern es normalerweise, dass der Angreifer die Verbindung über sich umleitet. Diese Umleitungen wirken zumeist nur lokal - also beispielsweise bei ARP-Spoofing nur im Firmennetz oder WLAN, bei DNS-Cache-Poisoning nur für die Nutzer des vergifteten DNS-Servers. Unabhängige Dritte irgendwo draußen im Internet sehen dabei weiterhin die reguläre Site und deren Zertifikat.

Perpectives

Wenn mehrere "Notare" über einen längeren Zeitraum den gleichen Schlüssel sehen, ist das ziemlich sicher kein MITM-Angriff.

Das Projekt Perspectives setzt darauf, dass im Netz verteilte Beobachter diese lokalen Manipulationen aufdecken können. Dazu vergleichen sie die Fingerabdrücke der aktuell von der Site angebotenen Zertifikate untereinander und mit denen der letzten Tage.

Konkret bietet Perspectives ein Firefox-Add-on, das bei Zertifikaten, die der Browser moniert, vier sogenannte Notare befragt. Das sind spezielle Server, die derzeit noch von amerikanischen Universitäten betrieben werden. Sehen mindestens drei das gleiche Zertifikat wie der Anwender, geht das Add-on davon aus, dass das schon seine Richtigkeit hat, erstellt eine temporäre Ausnahme und überschreibt die Fehlermeldung des Browsers. Die Ausnahmeregel verfällt mit dem Beenden der Browser-Sitzung.

Eine einmal angefragte Website wird ab sofort kontinuierlich überwacht, sodass nach einer Startphase auch die zeitliche Konstanz in die Bewertung einfließen kann. Man muss ganz klar sagen, dass dieses Konzept nicht unbedingt der Weisheit letzter Schluss ist. Schließlich überschreibt es ohne weitere Nachfragen auch Fehlermeldungen, wenn beispielsweise ein kompromittiertes Zertifikat vom Herausgeber gesperrt wurde. Paradoxerweise kommt es unter Umständen sogar gerade dann, wenn der Server-Betreiber ein unsicheres Zertifikat durch ein neues, sicheres ersetzt, zu Angriffswarnungen durch Perspectives.

Außerdem erleichtert das Add-on Phishing-Angriffe mit SSL-Tarnung. Denn die Anschaffung eines gültigen SSL-Zertifikats ist eine gewisse Hürde, die durch den Freibrief für global sichtbare Zertifikate entfiele. Wer sich aber eingesteht, dass er wie die meisten Anwender Fehler in Zertifikaten praktisch immer ignoriert, fährt mit dem Perspectives-Add-on allemal besser. Damit kann er wenigstens vorher eine externe Meinung einholen. Und wenn er dabei dann noch das komfortable, aber riskante automatische Überschreiben der Browser-Fehlermeldung abschaltet, ergibt sich ein echter Sicherheitsgewinn.

Wie sich herausgestellt hat, funktioniert das System zum Sperren von Zertifikaten in der Praxis eigentlich nicht. Durch einen Fehler in der Krypto-Bibliothek erzeugten Debian-Systeme über anderthalb Jahre hinweg SSL-Zertifikate [1], deren Schlüssel sich einfach erraten lassen. Tausende von Servern setzten deshalb schwache SSL-Zertifikate ein, die die Betreiber nach Bekanntwerden des Problems widerrufen mussten.

Seit Version 3 überprüft Firefox immerhin standardmäßig den Status von Zertifikaten, die eine URL für das Online Certificate Status Protocol (OCSP) aufweisen. Dummerweise ist das, wie unsere Tests gezeigt haben, noch immer die Minderheit. So stellt eine der größten deutschen CAs, das Trust Center der Deutschen Telekom T-Systems, noch immer neue Zertifikate ohne OCSP-URL aus. Die enthalten zwar eine URL für die Widerrufsliste der CA - den sogenannten CRL Distribution Point -, doch damit kann wiederum Firefox noch nichts anfangen.

Einzig Internet Explorer 7 unter Vista wertet CRLs per Default aus. Bei Firefox muss man derzeit jede CRL einzeln lokalisieren und von Hand eintragen, was praktisch unmöglich ist. Ein echtes Manko ist auch die Tatsache, dass die Mozilla-Entwickler immer noch keinen Test auf schwache Zertifikate eingebaut haben. Denn selbst widerrufene Zertifikate ohne OCSP-URL lassen sich immer noch für gefälschte Websites missbrauchen.

So gelang es heise Security, mit einem widerrufenen schwachen T-Systems-Zertifikat die Übertragung einer Kreditkartennummer an T-Pay zu belauschen, ohne dass der Anwender mit seinem Firefox 3 eine Warnung zu sehen bekam. In die Bresche springt das Add-on SSL-Blacklist von Màrton Anka, das schwache Zertifikate erkennt und meldet. Als Add-on hat es allerdings keinen Zugriff auf den SSL-Verbindungsaufbau, sondern kommt erst zum Zug, nachdem bereits Daten übertragen wurden und das Kind unter Umständen bereits im Brunnen liegt. Eine saubere Lösung müsste in die Krypto-Infrastruktur von Mozilla, also die Network Security Services integriert werden. Immerhin moniert Ankas Blacklist-Add-on auch Zertifikate, die den unsicheren Hash-Algorithmus MD5 [2] einsetzen.

Warnung vor schwachem Zertifikat

Auch knapp ein Jahr nach dem Debian-Debakel setzen noch Shops schwache SSL-Zertifikate ein.

Das Dreipunkteprogramm für sicheres Online-Shopping mit Firefox 3 lautet somit: SSL Blacklist [3] mit lokalen Blacklist-Datenbanken installieren. Das bedeutet zwar einen Download von 30 MByte, ist aber sicherer als die DNS-Abfrage. Als zweites Perspectives [4] einrichten und dabei das automatische Überschreiben von Sicherheitswarnungen abschalten. Damit kann man zusätzliche Informationen zu Zertifikatsfehlern einholen und bei Bedarf mit gutem Gewissen Ausnahmen erstellen. Um es zu vereinfachen, verschlüsselte Verbindungen zu erkennen, als drittes noch die verbesserte Kennzeichnung von SSL-Sites aktivieren. Und das kombiniert man mit einer gesunden Portion Misstrauen - vor allem gegenüber Dingen, die zu gut sind, um wahr zu sein. (ju [5])


URL dieses Artikels:
https://www.heise.de/-270114

Links in diesem Artikel:
[1] https://www.heise.de/hintergrund/Gute-Zahlen-schlechte-Zahlen-270078.html
[2] https://www.heise.de/hintergrund/Konsequenzen-der-erfolgreichen-Angriffe-auf-MD5-270106.html
[3] http://codefromthe70s.org/sslblacklist.aspx
[4] http://www.cs.cmu.edu/~perspectives/firefox.html
[5] mailto:ju@ct.de