Über die (Un-)Sicherheit von SSL und HTTPS

Normalerweise denkt man, eine Seite mit https:// in der Adresse sei sicher, die Daten seien verschlüsselt und man kommuniziere definitiv mit dem richtigen Gesprächspartner. Das zugrunde liegende Protokoll nennt man SSL bzw. TLS (ich werde hier nur noch von SSL reden, TLS ist der Name der neusten Version), wenn also in SSL ein Fehler gefunden wird, ist davon auch HTTPS betroffen.  Das Protokoll an sich ist größtenteils sicher. Die Angriffe beziehen sich auf meist die dahinterliegenden Strukturen, die teilweise unsicher sind. Ich rede dennoch etwas unkorrekt von Angriffen auf HTTPS bzw. SSL, weil die Angriffe auf die Strukturen im Hintergrund natürlich in der Praxis per HTTPS/SSP gesicherte Verbindungen unsicher machen. Hier möchte ich einen sowohl für Anfänger als auch für Fortgeschrittene interessanten Überblick geben, was von der Sicherheit zu halten ist, was noch sicher ist  und was unsicher. Ich gehe im Folgenden von Firefox aus, wer noch den Internet Explorer nutzt, ist selber schuld und tut mir leid.

Ich habe auch allgemeine Tipps für Anfänger eingebaut. Je nach Kentnissstand werden einige Abschnitte unverständlich kompliziert und einige andere langweilig sein. Auch Profis können interessante Probleme finden, aber die Seite richtet sich eher an Nutzer, denen SSL ein Begriff ist.

Der Artikel ist doch sehr lang geworden. Daher erstmal nur, was hier behandelt wird:

• Einleitung
• Funktionsweise von SSL und HTTPS (sehr grob)
• (Nicht) mögliche Angriffe
• Aufbau von Adressen
• Sicherheitsmerkmale im Browser
• EV-Zertifikate
• HTTPS ist kein Gütesiegel
• Die einzelnen Angriffe
  • 1. Debian OpenSSL weak keys
  • 2. Comodo stellt ungeprüft Zertifikate aus
  • 3. StartSSL stellt schlechte geprüft Zertifikate aus
  • 4. MD5-Kollisionsangriffe
  • 5. OpenSSL-Lücke
  • 6. „optimierte“ Umleitung, wenn zunächst http benutzt wird (sslstrip, IDN-Spoofing)
  • 7. Nullbytes im Hostname des Zertifikats
• Fazit

Vorab: Sicherheitstipps für Einsteiger in Kürze

• System sicher halten – In dem Moment, wo der Rechner von einem Angreifer z. B. mit einem Trojaner bearbeitet wurde, kann man die ganzen Sicherheitsmaßnahmen vergessen. Nur wenn der Rechner und die Software vertrauenswürdig sind, kann man sich auf die Ausgaben verlassen. Dafür sollte man:
  • Sichere Software verwenden – Software, die oft Sicherheitslücken hat, meiden. Je stärker die Software fremdem Inhalt ausgesetzt ist, desto sicherer muss sie sein. Ein unsicheres (Offline-)Spiel ist kaum ein Problem. Ein unsicherer Browser umso mehr.  Internet Explorer meiden, z. B. Firefox nutzen.
  • Software aktuell halten – Software hat immer Sicherheitslücken. Mit Updates werden bekannte Lücken geschlossen. Spielt man ein Update nicht ein, obwohl es eine bekannte Lücke gibt, wird diese meist bald ausgenutzt. Auch hier gilt: Vor allem Betriebssystem und Browser sowie die Browser-Plugins (Acrobat Reader, Flash, diverse Mediaplayer) müssen immer topaktuell sein.
  • Virenscanner und Firewalls sind ein zusätzliches Sicherheitsnetz. Updates sind viel wichtiger.
  • Nicht vertrauenswürdige Software nicht starten. Dazu zählen gerne auf dubiosen Seiten angebotene falsche Updates sowie illegale Kopierschutz-Knackprogramme.
• Wichtige Seiten direkt aufrufen – am Besten per Lesezeichen. Wer seine Bankseite immer per Google sucht, hat ein Problem, wenn ein Phisher es mal nach oben schafft.
• Beim Aufrufen direkt https:// benutzen – sonst kann ein Angreifer problemlos umleiten, siehe unten.
• Warnungen beachten – wenn der Browser sagt, dass irgendwas mit der Bankseite nicht in Ordnung ist, dürfte es stimmen, auch wenn bei irgendwelchen Hobbyseiten die Warnung oft „grundlos“ kommt.
• Für Seiten die man nicht direkt aufruft muss man leider https kennen, um sicher zu sein. Das ist für Anfänger nicht einfach.

Einleitung

Diese Seite wird von mir regelmäßig geändert und aktualisiert. Einige Sachen werden am Beispiel der Postbank erklärt, weil das die erste Bankseite war, die mir einfiel. Die Seite wird nur als Beispiel verwendet, die Beispiel-Phishingseiten sind frei erfunden und in Wirklichkeit entweder nicht existent oder vermutlich harmlose Seiten. Als Beispiel für Phishingseiten dienen meist recht offensichtliche Adressen, in Wirklichkeit benutzen Angreifer natürlich möglichst seriös aussehende Namen wie „postbank-sicherheit“. Als Faustregel: Postbank.de und example.com sind hier „gute“ Seiten, alles mit .ru am Ende sind Phishingseiten-Beispiele.

Funktionsweise von SSL und HTTPS (sehr grob)

Zunächst einmal ein grober etwas vereinfachender Überblick, wie SSL funktioniert und warum es theoretisch sicher ist. Wen die Details nicht interessieren, kann diesen Teil überspringen, einige Erklärungen basieren aber darauf. Wer sich wirklich mit dem Protokoll beschäftigen will sollte andere Quellen heranziehen, da ich es oft vereinfacht habe (oft biete ich Links zum Weiterlesen an). Wer beim Lesen einen Fehler gefunden hat und deswegen denkt das Verfahren sei unsicher, hat entweder was übersehen oder ich habe zu stark vereinfacht. Unter den gegebenen Annahmen ist das Verfahren sicher. Wenn die Annahmen nicht erfüllt sind, kann es unsicher werden, und genau das ist in der Vergangenheit passiert und ich möchte einige Beispiele nennen.

Es gibt mehrere Firmen, sogenannte (Stamm-)Zertifizierungsstellen oder (Root-)CAs, welche sogenannte Zertifikate ausstellen. Ein Zertifikat bestätigt, dass ein privater Schlüssel einem bestimmten Server gehört. Zu den Servernamen mehr sehr wichtiges siehe unten. Es hat unter anderem ein Gültigkeitsdatum und ist mit dem privaten Schlüssel der CA unterschrieben. Jedes Betriebssystem oder Programm, welches SSL bzw. HTTPS nutzt (z. B. Firefox) hat eine Liste der vertrauenwürdigen Root-CAs inklusive der öffentlichen Schlüssel. Mit einem öffentlichen Schlüssel kann man eine Signatur prüfen, die mit dem privaten Schlüssel erstellt wurde. Signaturen kann man nur mit dem privaten Schlüssel erstellen und sie sind sehr fälschungssicher, eine Änderung des Inhalts macht die Signatur ungültig. Das ganze basiert meist auf RSA, einem als sicher anerkannten Verfahren.

Ein Server hat also seinen privaten Schlüssel und ein Zertifikat, welches den öffentlichen Schlüssel beinhaltet und die Bestätigung der CA „ich bestätige hiermit dass dieser Schlüssel zur Domain example.com gehört“. Das ganze ist von der CA signiert. Wenn man nun mit example.com per https kommunizieren will, zeigt der Server, dass er den privaten Schlüssel besitzt (indem er Zufallsdaten signiert) und liefert das Zertifikat mit. Firefox prüft dann, ob das Zertifikat von einer vertrauenswürdigen CA ausgestellt und korrekt unterschrieben wurde und ob der öffentliche Schlüssel zum privaten Schlüssel des Servers passt. Wenn das alles stimmt, kann man davon ausgehen, mit dem richtigen Server eine sichere Verbindung aufgebaut zu haben.

(Nicht) mögliche Angriffe

Einfach abhören oder an den Daten rumbasteln geht nicht, weil die Daten zwischen Firefox und Server verschlüsselt und signiert sind und ein Angreifer die Schlüssel nicht hat. Er könnte aber versuchen, sich als Server auszugeben, sodass Firefox sich mit ihm statt dem echten Server verbindet. Firefox weiß aber, dass die Verbindung zu example.com gehen soll. Der Angreifer hat den privaten Schlüssel von example.com nicht, kann also das echte Zertifikat nicht nutzen (Firefox würde merken, dass der private Schlüssel nicht zum Zertifikat passt, und die Verbindung abbrechen). Er kann auch kein anderes Zertifikat vorzeigen, denn Zertifikate können nicht gefälscht werden und keine CA wird ihm ein Zertifikat geben, welches seinen Schlüssel mit example.com zusammenbringt. (Soweit die Theorie!)

Firefox gibt eine Warnung aus, wenn mit der Verbindung etwas nicht stimmt. Wenn der Benutzer die Warnung einfach wegklickt, ist er selbst schuld. Die Warnungen stehen nicht ohne Grund da!

Einige Seiten benutzen nicht korrekt signierte Zertifikate (um Geld zu sparen), bei kleineren Foren können solche Warnungen also auch ohne einen Angriff kommen. Wenn aber das Datum des Computers stimmt (wegen dem Gültigkeitsdatum der Zertifikate), sollte bei Banken etc. nie eine Warnung kommen. Wenn doch, ist was faul. Die Seiten mit nicht korrekt signierten („selbstsignierten“) Zertifikaten sind übrigens immer noch sicherer als eine Seite die über http unverschlüsselt übertragen wird. Für einen Angriff auf eine https-Verbindung mit selbstsigniertem Zertifikat muss man aktiv Daten manipulieren, während das Abhören unverschlüsselter Daten trivial ist.

Wenn der Angreifer den privaten Schlüssel kopieren kann, kann er sich natürlich für den Server ausgeben. Dazu müsste er aber erstmal in den Server eindringen, und Banken benutzen außerdem spezielle Hardware, aus der der Schlüssel überhaupt nicht herauskopiert werden kann. Wenn der Angreifer ein Zertifikat fälschen könnte, oder eine CA ihm ein Zertifikat geben würde ohne dass example.com ihm gehört, wäre der Schutz dahin. Und es gibt viele CAs und es reicht wenn eine einen Fehler macht.

Das ganze gilt nur für https-gesicherte Verbindungen. Oft werden zusätzlich/vorher ungesicherte Verbindungen genutzt, die ein Angreifer beliebig manipulieren kann.

Aufbau von Adressen

Der Aufbau von Adressen ist extrem wichtig, denn Phisher verwenden oft echt aussehende, aber falsche Adressen. Adressen im Internet sind wie folgt aufgebaut:

http://www.example.com/content/seite.html

Hierbei ist der Teil vor dem :// das Protokoll. Hier ist es http, also unverschlüsselt. Wenn die Verbindung verschlüsselt ist, steht dort https. Der gesamte Teil vor dem nächsten / – egal was da steht – ist der äußerst wichtige Servername (siehe unten). Dieser ist von rechts nach links zu lesen. Ein Rechner auf ru.sicherheit.postbank.de würde also sehr wohl zur Postbank aus Deutschland gehören, während ein Rechner namens de.postbank.sicherheit.ru ein willkürlich „de.postbank“ genannter Rechner ist, welcher zur russischen Seite sicherheit.ru gehört – also eher eine gefälschte Seite! Eigentlich sind für diesen Teil nur Buchstaben, Zahlen, Punkte und Bindestriche erlaubt, mit einer Erweiterung (internationale Namen, siehe unten) ist jedoch mehr möglich. Insbesondere können wie ein / aussehende, aber nicht so interpretierte, Zeichen auftauchen!

Wenn man per https mit dem richtigen Server verbunden ist, ist man eigentlich „in Sicherheit“. Das gilt aber nur, solange der Server sicher ist. Ansonsten kann es einem Angreifer möglich sein, über diverse Angriffe den Server dazu zu bringen, seinen Inhalt auszuliefern (d.h. der echte Postbank-Server liefert die Phishing-Seite, ist einigen anderen Banken schon passiert). Die meisten der Angriffe funktionieren nur, wenn der Nutzer auf einen präparierten Link klickt. Solche Links sind für das geschulte Auge oft erkennbar, aber für unerfahrene Nutzer nicht, zumindest nicht zuverlässig. Das ist aber nur ein Problem, wenn der echte Server unsicher ist, was in der Regel nicht der Fall ist.

Sicherheitsmerkmale im Browser

Woran erkennt man überhaupt, ob man auf einer sicheren Seite ist? Wer keinen Firefox nutzt, hat entweder Ahnung und weiß wo er schauen muss (Linux-Browser, exotisches Zeug, etc.), sollte dringend auf Firefox wechseln weil es sonst eh hoffnungslos ist (Internet Explorer) oder muss halt selbst schauen (Opera, Safari) oder wechseln. Bei Firefox 3 erkennt man sichere Seiten am Schloss-Symbol und Domainnamen in der Statusleiste (ganz unten, rechts) und dem blauen oder grünen Hintergrund im Kasten links neben der Adressleiste (ein Schloss an dieser Stelle ist nicht das echte Symbol, sondern kann belebig gefälscht werden!)

Neben dem Schlosssymbol in der Statusleiste steht der Rechnername, mit dem man verbunden ist. Dieser ist vergleichsweise schwer zu fälschen und einer der zuverlässigeren Indikatoren auf den man achten sollte. Die Adresse in der Adressleiste ist, wenn man weiß wie man Adressen zu lesen hat, ein weiteres, gutes Merkmal.

Besonders sicher sind sogenannte EV-Zertifikate. Besonders kritische Websites wie Banken sollten damit gesichert sein. Dabei wird der Firmenname neben der Adresse auf grünem Grund gezeigt, und wenn da steht „Deutsche Postbank AG (DE)“, dann kann man sich unabhängig von anderen Umständen recht sicher sein, auf der echten Postbank-Seite zu sein.

Früher wurde bei sicheren Verbindungen die Adressleiste gelb eingefärbt, das ist leider wieder abgeschafft worden. Das lässt sich manuell korrigieren (über die userchrome.css), unerfahrene Nutzer sollten aber die Finger davon lassen.

Keine Sicherheitsmerkmale sind insbesondere Schlosssymbole an irgendwelchen anderen Stellen, auch alles in der Website-Fläche (zwischen Symbolleiste und Statusleiste) ist völlig irrelevant, weil von Angreifern beliebig fälschbar.

EV-Zertifikate

Es gibt inzwischen zwei Arten von SSL/HTTPS-Zertifikaten, die „normalen“ und die „EV“-Zertifikate. EV steht für Extended Validation (erweiterte Überprüfung) und für diese Zertifikate wird geprüft, welche Firma das Zertifikat anfordert, und es werden sicherere Verfahren genutzt, auch können nicht alle CAs solche Zertifikate ausstellen. EV-Zertifikate erkennt man daran, dass Firefox in der Adressleiste links neben der Adresse den Firmennamen auf grünem Grund anzeigt. Diese Zertifikate sind deutlich sicherer, bei Banken etc. sollte man darauf achten, dass ein solches Zertifikat genutzt wird.

HTTPS ist kein Gütesiegel

Zunächst einmal: https bedeutet auch wenn es richtig funktioniert nur, dass man mit der angegebenen Seite kommuniziert. Wenn diese Seite nun postbank-de-security-validation.ru ist (also eine fremde russische Domain zum Phishing), dann kann diese auch problemlos über https aufgerufen werden, es bleibt eine Phishingseite. (Update: Übrigens kann man sich bei nicht-EV-Zertifikaten eher nicht auf die Besitzer-Infos im Zertifikat verlassen, weil die nicht ernsthaft geprüft werden, siehe hier.) https sagt also nichts über die Seriosität von Seiten oder Onlineshops aus. Ein https-gesicherter Onlineshop kann einen genauso betrügen wie ein nicht-https-gesicherter. Allerhöchstens kann ein normaler Onlineshop, der kein https einsetzt, kritisiert werden, weil er Kundendaten nicht ausreichend schützt.

Eine Ausnahme sind hier die EV-Zertifikate. Der dargestellte Firmenname wird geprüft, wenn also „Postbank AG“ im grünen Feld steht, dann hat die CA bestätigt, dass diese Adresse tatsächlich der Postbank gehört. Über die Vertrauenswürdigkeit einer Firma sagt es aber auch nichts aus, höchstens durch die höheren Kosten und etwas genaueren Prüfungen für diese Zertifikate könnten Betrüger abgeschreckt werden, vor allem wenn es sich um „Wegwerf-Domains“  handelt. Verlassen sollte man sich darauf aber nicht.

http bleibt unsicher

Wenn man per unverschlüsseltem http auf eine Website geht, und dann einen Link anklickt, kann ein geschickter Angreifer einen natürlich auf beliebige Seiten weiterleiten. Wenn man sich also bei diversen Mailanbietern (oder einer gewissen großen, gerne von Phishern angegriffenen US-Bank) einloggen will und neben dem Login-Feld steht, dass die Daten per SSL verschickt werden, aber in der Adressleiste (noch) http statt https steht, dann kann es durchaus sein, dass die eingegebenen Daten statt an https://example.com an http://example.com geschickt werden, wenn ein Angreifer „gebastelt“ hat. Alles funktioniert wie gehabt, es gibt keine Sicherheitswarnung, die Daten werden sogar an den richtigen Server geschickt, gehen aber unverschlüsselt über die Leitung, sodass der Angreifer sie abhören kann. Er muss die Seite noch nichtmal auf https://example.com.phishingsite.ru umleiten, auch wenn das natürlich genauso möglich wäre. Es ist aber unnötig, da ein Angreifer bei unsicherem http die Inhalte auch so austauschen kann. Garniert werden kann der Angriff noch mit einem gefälschten Schlosssymbol, siehe unten.

Daher sollte man, insbesondere wenn man Onlinebanking betreibt, nicht erst die Bankseite per http aufrufen und dann den Links folgen, sondern von vorne herein explizit https schreiben (oder ein entsprechendes Lesezeichen anlegen). Siehe auch unten zu einem aktuellen Angriff, der dies ausnutzt.

Aktuelle Angriffe

Die Sicherheit von SSL (und damit https) basiert auf einigen Annahmen. Diese wurden vor allem in letzter Zeit öfter verletzt, wodurch das Verfahren teilweise unsicher wurde. Da sich die Angriffe häufen, wollte ich einen Überblick zum Verlinken haben, und habe mich entschlossen gleich eine etwas weitere Übersicht zu geben.

1. Debians openssl-Zufallsgenerator

Links: Heise, Golem

Für SSL benötigt man Software. Eine weit verbreitete Software ist openssl. Das wird auch von einigen anderen, weit verbreiteten Programmen genutzt, und ist unter Linux das am Meisten benutzte Programm für die Schlüsselerzeugung. Bei der Erzeugung von Schlüsselpaaren (privater und öffentlicher Schlüssel) müssen Zufallszahlen benutzt werden. Damit das Verfahren sicher ist, bemüht man sich, möglichst viele verschiedene Werte auf die Ermittlung der Zahlen Einfluss nehmen zu lassen um eine möglichst hohe Zufälligkeit zu erzeugen. Eines der Verfahren bestand darin, unbenutzten Speicher hinzuzuziehen, was aber bei der Überprüfung der Software Warnungen produzierte (normalerweise sollte Software nie auf unbenutzten Speicher zugreifen, und wenn sie es tut ist es ein Fehler). Statt die Warnung zu ignorieren, entschied man sich, in Zukunft keinen uninitialisierten Speicher zu benutzen, und entfernte die Zeile. Das hätte der Sicherheit nicht nennenswert geschadet, ein OpenSSL-Entwickler war auch der Meinung und die Änderung wurde durchgeführt. Eigentlich wäre das Verfahren auch immer noch sicher und die Zahlen ausreichend zufällig, wenn nicht auch noch ein zweites Vorkommen dieser Zeile entfernt worden wäre. Die Zeile war absolut identisch, stand jedoch in einem anderen Kontext. Statt „hole uninitalisierten Speicher und füge ihn zum Zufallsgenerator hinzu“ bedeutete sie hier „füge nächsten gewünschten Wert zum Zufallsgenerator hinzu“. Dadurch war der Zufallsgenerator kaum noch zufällig und somit unsicher. Der Zufallsgenerator konnte nur noch ca. 32000 verschiedene Werte ausgeben, sodass es pro Kombination aus Schlüssellänge, -art, grobem Prozessortyp etc. nur 32000 private Schlüssel gab. Die Sicherheit moderner Kryptoverfahren aber beruht darauf, dass es so viele Schlüssel gibt, dass keiner sie durchprobieren kann, und nur wenn das gegeben ist ist ein Verfahren sicher. 32000 mag viel klingen, für einen Computer sind das jedoch Peanuts. Nach einigen Stunden Rechenzeit hat man also alle in Frage kommenden privaten Schlüssel. Diese Lücke war ca. 3 Jahre unbemerkt geblieben!

Was bedeutet dies nun? Wenn ein Server einen Schlüssel mit OpenSSL erzeugt und dafür ein Zertifikat erhalten hat, kann jeder den privaten Schlüssel ermitteln. Wenn der private Schlüssel aber dem Angreifer bekannt ist, ist SSL bzw. HTTPS nicht mehr sicher. Selbst wenn der Server danach den Schlüssel wechselt – wenn der Angreifer noch das passende Zertifikat hat, kann er es weiterhin nutzen, bis es ungültig wird. Eben für solche Fälle gibt es eine weitere Sicherung: Eine Zertifizierungsstelle kann ein Zertifikat für ungültig erklären. Firefox prüft das aber nicht, wenn es nicht auf eine bestimmte Art geschieht. Und die Zertifizierungsstelle, die für Akamai ein Zertifikat ausgestellt hat, hat die falsche Methode benutzt. Akamai ist eine große Firma und wickelt unter anderem die Downloads vom Finanzamt (ELSTER-Software) ab. Muss ich noch dazusagen, dass sie einen Debian-Schlüssel hatten? Wenn ich mich recht erinnere waren sie damit monatelang angreifbar. Inzwischen ist das Zertifikat zum Glück abgelaufen. Der „private“ Schlüssel liegt als Andenken im Heise-Forum. Für das ebenfalls auf OpenSSL aufbauende OpenSSH wurden Pakete mit einem Großteil der schwachen Schlüssel veröffentlicht, inklusive einiger bösartiger Karikaturen.

Folgen für den Normalnutzer: Wenn ein Server jemals ein Zertifikat mit einem schwachen Schlüssel eingesetzt hat, sind Verbindungen zu diesem Server unsicher, bis das Zertifikat abläuft oder wirksam für ungültig erklärt wird. Als Schutz kann man die OpenSSL Blacklist für Firefox installieren (und zwar inklusive der 60 MB großen Datenbank, sonst bringt es nicht viel). Die meisten Zertifikate sollten abgelaufen sein, aber es gibt sicher noch einige die es nicht sind.

2. Comodo stellt ungeprüft Zertifikate aus

Links: Offenlegung der Entdeckung, Genauere Beschreibung

Eine der „vertrauenswürdigen“ CAs heißt Comodo. Ein von Comodo ausgestelltes Zertifikat wird von Firefox als gültig angesehen. Comodo hat allerdings Reseller, und lässt die auch die Überprüfung machen, ob einem Antragsteller eine bestimmte Domain wirklich gehört. Einer dieser Reseller  hat auf diese Überprüfung vollständig verzichtet. (Der Reseller hat wohl auch Spam verschickt und als einer der Chefs einer anderen CA das untersucht hat ist ihm die Lücke aufgefallen.) Wenn also jemand gesagt hätte „ich will ein Zertifikat für paypal.com“ und (s)einen public key dazugepackt hat, dann hätte über diesen Reseller Comodo ein Zertifikat „Ich bestätige hiermit, dass der beigefügte public key zu paypal.com gehört“ ausgestellt. Der Fehler war wohl mehrere Tage lang vorhanden. Comodo hat seine Reseller-Praktiken nicht geändert und ist bei mir daher keine vertrauenswürdige CA mehr, von Comodo signierte Zertifikate werden bei mir als unsicher verworfen.

Folgen für den Normalnutzer: Hoffentlich keine. Comodo behauptet, alle über diesen Reseller ausgestellten Zertifikate geprüft und dabei keinen Missbrauch festgestellt zu haben. Einige unklare Zertifikate wurden widerrufen und sind damit ungültig. Wie das ganze geprüft wurde, weiß ich nicht, es kann sein dass es möglich war. EV-Zertifikate waren nicht betroffen.

3. StartSSL stellt schlechte geprüft Zertifikate aus

Links: Blogeintrag des Entdeckers, Stellungnahme der CA

Eine weitere CA hat wohl einen unschönen Fehler gemacht und zu sehr auf vom Browser übermittelte Angaben vertraut. Im Gegensatz zu Comodo sind sie offen mit ihrem Fehler umgegangen und haben umfangreiches Material veröffentlicht, wie es zum Fehler kam und wie die Folgen minimiert werden sollen.

Folgen für den Normalnutzer: Keine. Es wurde dargelegt, wie die bisher ausgestellten Zertifikate geprüft wurden (es wurde kein Missbrauch festgestellt), und das Verfahren ist glaubwürdig. Die zum Ausprobieren der Lücke erstellten Zertifikate wurden natürlich widerrufen. StartSSL gilt für mich weiterhin als sicher und vertrauenswürdig. EV-Zertifikate waren nicht betroffen.

4. MD5-Kollisionsangriffe

Links: Ankündigung des Vortrags und Folien, Website mit genauer Beschreibung, Kurzfassung, Heise, Golem

Einer Gruppe von Sicherheitsforschern ist es gelungen, die „sicheren“ Signaturen doch zu fälschen. Das war möglich, weil einige CAs ein veraltetes und unsicheres Verfahren zur Signatur benutzen. Dadurch konnten die Forscher unter Einsatz massiver Rechenleistung (200 Playstation2-Konsolen, 3 Tage lang) zwei noch nicht signierte Zertifikate erzeugen. Das eine war ganz normal und wurde von einer der CAs mit dem unsicheren Verfahren signiert, das andere war ein „allmächtiges“ CA-Zertifikat, mit dem man neue Zertifikate ausstellen kann. Dank des unsicheren Verfahrens konnte die für sicher gehaltene Signatur in das andere Zertifikat kopiert werden. Dadurch wurde es als gültig akzeptiert. (Die Signatur wird erstellt, indem eine mathematische Funktion, Hashfunktion genannt, auf das unsignierte Zertifikat angewendet wird und nur das Ergebnis dann signiert wird. Diese Funktion ist so aufgebaut, dass es praktisch unmöglich sein sollte, zwei Eingaben zu finden die das gleiche Ergebnis produzieren. Es gibt mehrere solcher Funktionen, z. B. MD5 und SHA-1, und erstere wurde verwendet und dafür können solche „Kollisionen“ erzeugt werden, und genau das haben die Wissenschaftler getan. Die beiden Zertifikate haben das gleiche Ergebnis, wenn man ihren MD5-Wert berechnet, und somit ist die gleiche Signatur gültig).

Die Forscher könnten somit für jede beliebige Website falsche Zertifikate ausstellen, die von jedem gängigen Browser akzeptiert würden. Allerdings haben die Forscher das gefälschte Zertifikat absichtlich mit einer Gültigkeit bis 2004 versehen, damit es ungültig ist und nicht für Angriffe missbraucht werden kann.

Die Forscher sagten, dass der Angriff schwierig zu reproduzieren ist und erhebliches Wissen benötigt, welches nicht öffentlich verfügbar ist. Daher gehen sie nicht davon aus, dass irgendwer diesen Angriff durchgeführt hat. Auf bereits bestehende Zertifikate die nicht mit diesem Angriff erstellt wurden hat der Angriff keine Auswirkungen, da sowohl das signierte als auch das falsche Zertifikat nach einem bestimmten Muster berechnet werden müssen, man kann also keine neuen falschen Zertifikate anhand bereits bestehender korrekter erstellen. Die CAs haben nach eigenen Angaben aufgehört das unsichere Verfahren zu nutzen oder planen es und haben anderweitige Schutzmaßnahmen getroffen, die den Angriff in der Praxis für die Zukunft verhindern dürften.

Folgen für den Normalnutzer: EV-Zertifikate sind nicht betroffen, da sie MD5 nicht zulassen (die Probleme mit MD5 sind seit vielen Jahren bekannt). Es ist unwahrscheinlich, aber nicht völlig ausgeschlossen, dass irgendwer (Geheimdienste/kriminelle Gruppen) einen solchen Angriff durchgeführt hat. Wenn dies der Fall wäre, wäre dies kaum festzustellen und würde SSL größtenteils unsicher machen. Vermutlich wird im Verlauf der nächsten 2 Jahre MD5 aus den Browsern genommen und der Angriff auch durch frühere Zertifikate dadurch endgültig verhindert. Wer vor MD5-Zertifikaten (die leider noch recht verbreitet sind) gewarnt werden will, kann die bereits erwähnte OpenSSL Blacklist für Firefox installieren.

5. OpenSSL-Lücke

Laut Heise hat OpenSSL einen Fehler, wodurch es sich gefälschte Zertifikate unterschieben lässt. (Update: Noch ein Fehler.) Da Firefox SSL soweit ich weiß selbst macht, dürfte HTTPS über Firefox nicht betroffen und weiterhin sicher sein. Die Folgen für den Normalnutzer sollten daher nahe null sein, Serverbetreiber haben aber eventuell ein Problem.

6. „optimierte“ Umleitung, wenn zunächst http benutzt wird (sslstrip, IDN-Spoofing Teil 2)

Link: Präsentation des Angriffs

Siehe oben – wenn ein Nutzer zunächst eine http-Seite nutzt, um auf die https-Seite zu gelangen, können die Links manipuliert werden. Es ist aber noch ein weiterer Trick dabei: Um sogenannte IDNs, internationale Domainnamen (also Domains mit z. B. Umlauten) zu ermöglichen, unterstützen Browser viele fremde Zeichen, die teilweise fast genauso wie lateinische Buchstaben aussehen, aber natürlich nicht gleich sind. Darüber liefen früher einige Phishing-Attacken, bei denen die Adresse der Phishingseite wie die echte Adresse aussah. Um das zu vermeiden, haben aktuelle Browser wirksame Schutzmaßnahmen und zeigen bei Fälschungsgefahr lieber die technische Schreibweise statt der menschenlesbaren an, sodass die Fälschung auffällt. Nun, dieser Schutz hat bei den gängigen Browsern einen Fehler und ist gegen einen aktuellen Angriff wirkungslos. Wenn man einmal auf der falschen Seite ist, merkt man es nicht mehr so leicht, weil der entscheidende Schrägstrich (siehe „Aufbau von Adressen“ oben) gefälscht ist. Auch wenn ich hinschauen würde würde ich den Angriff vermutlich übersehen. Es wird nicht lange dauern, bis das gepatcht ist, denke ich.

Bei Firefox wird außerdem bei SSL-Verbindungen die Domain nochmal rechts unten in der Statusleiste neben einem Schlosssymbol gezeigt. Sowohl die Domain-Angabe als auch das Symbol sind deutlich verlässlicher als die in der Adressleiste. Da die Domain angezeigt wird, sieht man leicht, ob man sich auf postbank.de oder postbank.de-contentdisplay-onlinebanking-blubb.phishingsite.ru befindet. In der Adressleiste kann man das eher übersehen: Wenn der Angreifer statt Bindestrichen ähnliche Sonderzeichen nutzt, kann plötzlich statt postbank.de/contentdisplay/irgendwaslanges postbank.de|contentdisplay|irgendwaslanges da stehen (nur dass der Unterschied zum echten Schrägstrich kleiner ist). Der ganze Teil gehört dann zur (Sub-)Domain und nicht zum Pfad.

Folgen für den Normalnutzer: Diese neue IDN-Spoofing-Attacke ist eine Gefahr für jeden Nutzer (gegen die EV-Zertifikate jedoch schützen). Es dürfte aber nicht lange dauern bis ein Patch erscheint. Umgehen lässt sich die ganze Problematik in jedem Fall dadurch, dass man direkt die https-Adressen verwendet (der Server muss es natürlich unterstützen, wenn vom Server direkt auf http umgeleitet wird ist das wieder unsicher).

Workaround: Um diese Fälschungsangriffe über internationale Domains (IDN-Spoofing) ein für allemal zu erledigen, können Firefox-Nutzer in der Adressleiste about:config eingeben,network.IDN_show_punycode raussuchen und auf true setzen. Dann wird jede IDN-Domain im „Maschinentext“ angezeigt, aus handyzubehör.de wird xn--handyzubehr-0fb.de und damit ist das Problem vom Tisch. Mir ist beim normalen surfen bisher noch keine einzige Domain aufgefallen, die IDN sinnvoll und aktiv nutzt. In Sprachen mit nichtlateinischem Zeichensatz (Chinesisch, Japanisch, Arabisch) wird das sicher häufiger vorkommen, nur ist es mir aus offensichtlichen Gründen vergleichsweise egal, ob ich für mich unverständliche arabische Schriftzeichen oder unverständlichen lateinischen Zeichensalat sehe.

7. Nullbytes im Hostname des Zertifikats

Link: Heise-Artikel über Veröffentlichung eines Exploits

Wenn im Hostnamen im Zertifikat ein Nullbyte (also ein Sonderzeichen mit dem Zahlenwert „0“) auftaucht, ignorieren einige Programme alles was dahinter steht. Dadurch kann ein Zertifikat für *(nullbyte).blah.example.com (also dank dem *-Wildcard eigentlich alle Subdomains von blah.example.com die mit einem Nullbyte enden) als für alle existierenden Webseiten im ganzen Netz gültig angesehen werden.

Folgen für den Normalnutzer: Im Endeffekt war ist HTTPS bei der betroffenen Software komplett unsicher, bis ein Patch erschienen ist erscheint und installiert wird. Ein Nutzer dürfte keine Chance haben, den Angriff zu bemerken. Patches für Firefox und Opera wurden zügig bereitgestellt, veraltete Versionen sowie mindestens Internet Explorer, Safari und Chrome sind jedoch noch angreifbar. Wildcards für * (also alles) funktionieren im IE zwar nicht, er kann aber mit speziell für eine Domain angepassten Zertifikaten getäuscht werden. EV-Zertifikate sind nicht betroffen, da bei diesen keine Wildcards zulässig sind dürften über Zertifikate für einzelne Domains auch betroffen sein. Volltreffer, versenkt.

Fazit

SSL ist für den Normalgebrauch durchaus ausreichend, insbesondere die EV-Zertifikate bieten immer noch guten Schutz für Onlinebanking etc. Allerdings sollten die bisher entdeckten Angriffe zeigen, dass da durchaus noch neue Lücken auftauchen können. Insbesondere wird vermutlich MD5 bald noch mehr geknackt werden, und auch SHA-1 bröckelt schon. Auch CAs werden weiterhin ab und zu mit unsicheren Verifizierungsverfahren „glänzen“. Insbesondere für selbstgenutzte 1:1-Verbindungen (VPN, rein selbst genutzte Server, …) sind selbstsignierte, manuell geprüfte und fest eingetragene Zertifikate bzw. Schlüssel aber eine sehr interessante Option.

Und wer sich ungeschickt anstellt, kann reinfallen.