Wie das BSI unsere Daten „schützt“. Ein Rant über die Schwachstelle im GSTOOL.

TL;DR: Das BSI gibt ein Tool heraus, welches sensible Daten über die IT-Sicherheit von deutschen Firmen vor ausländischen Industriespionen schützen soll. Die Verschlüsselung ist derartiger Murks, dass sie als Spielzeug für Hacker verwendet wird. Sie lässt sich innerhalb von Sekunden bis Minuten knacken. Das BSI reagiert auf Sicherheitsforschung mit juristischen Drohungen – was dazu geführt hat, dass das BSI erst Jahre nach der ersten Entdeckung des Problems davon erfahren hat. Ein Sicherheitsupdate ließ über eineinhalb Jahre auf sich warten, und die Sicherheitswarnungen haben nicht alle Kunden erreicht. Es entsteht leicht der Eindruck, dass das BSI vor allem daran interessiert war, dass die peinlichen Fehler nicht allzu öffentlich werden.

Eigentlich wollte ich ja nur wissen, ob Chiasmus sicher ist. Die sagenumwobene, geheimgehaltene, nicht veröffentlichte¹⁾ Chiffre, die das BSI damals, in den dunklen Zeiten der Kryptographie, entwickelt hat. Es war damals eine durchaus nachvollziehbare Entscheidung, eine eigene Chiffre zu entwickeln. Der damalige weltweite Standard, DES, war auf Wunsch der NSA vermurkst und unsicher, AES noch nicht standardisiert – womöglich waren zu Beginn der Entwicklung Rijndael (das heutige AES) und Twofish noch gar nicht publiziert.²⁾

Die Chiffre ist in einem gleichnamigen Programm eingebaut, was man aber nur bekommt, wenn man ein öffentliches Interesse nachweisen kann. Das BSI hat auch ein Hilfsmittel für den IT-Grundschutz, das sogenannte GSTOOL, herausgegeben. Das GSTOOL (in der betroffenen Version) wurde nicht vom BSI programmiert, sondern von Steria-Mummert. Mit dem GSTOOL werden sensible Informationen über die Sicherheit von IT-Netzen verwaltet – insbesondere bei Firmen, die besonders schutzbedürftig sind, sowie bei Behörden. Deswegen bietet das GSTOOL auch eine Verschlüsselungsfunktion, welche ebenfalls auf der Chiasmus-Chiffre basiert. Diese Verschlüsselungsfunktion soll die Daten vor Kriminellen und vor ausländischen Geheimdiensten schützen. Daten, die zum Beispiel für Industriespione ein gefundenes Fressen wären.

Die Entdeckung

Vor knapp zwei Jahren. Wir sitzen zu dritt vor einem Computerbildschirm. Facepalmend. Auf dem Bildschirm ein Debugger, der die Schlüsselerzeugungsfunktion von GSTOOL zeigt. Verschlüsselungsschlüssel müssen zufällig und nicht vorhersagbar sein, denn sonst kann ein Angreifer sie erraten und dadurch die Nachricht entschlüsseln. Deswegen erzeugt man sie mit speziellen, sicheren (Pseudo-)Zufallsgeneratoren. Wenn man kompetent ist. Wenn nicht, googelt man „c++ zufallszahlen“, klickt das erste Ergebnis an und verwendet was man da sieht. Dummerweise sieht man da vermutlich etwas wie das hier – das Standardverfahren zum Erzeugen von Zufallszahlen. Und dummerweise sind die Zufallszahlen, die so erzeugt werden, vielleicht gut genug für die Würfel in einer digitalen Version von Mensch-Ärgere-Dich-Nicht, aber nicht für kryptographische Schlüssel. Das weiß eigentlich jeder, der auch nur ansatzweise Ahnung von Kryptographie hat. Die Entwickler des GSTOOL wussten es offensichtlich nicht. Und das BSI hat es in all den Jahren offensichtlich nicht für nötig gehalten, die Verschlüsselungsfunktion zu überprüfen, denn dann wäre zumindest eines der Probleme aufgefallen. Denn die Schlüsselerzeugung war zwar das schlimmste, aber nicht das einzige Problem. (Die Details gibts im Advisory)

Einige Zeit und einige hundert Zeilen Code später haben wir eine Software, welche mit dem GSTOOL Chiasmus-verschlüsselte Dateien entschlüsseln kann – ohne Schlüssel, in der Regel innerhalb von Sekunden. In einer Mail an das BSI bitten wir um eine verschlüsselte Testdatei – und senden sie postwendend zurück. Entschlüsselt.

Bitte keine Ergebnisse

In einigen Tagen gelangweiltem Stochern haben wir die Verschlüsselung komplett zerlegt. Totalschaden. Weniger als 2^32 effektive Schlüssellänge – das ist ein Wert, bei dem man aufhört, den Angriff zu optimieren, weil es eh schon schnell genug geht. Und das war keine besonders anspruchsvolle Aufgabe, sondern eigentlich nur Fleißarbeit. Wir haben die Software fertig analysiert, dem BSI und Steria-Mummert Ratschläge zur Behebung des Problems gegeben, und schließlich auch ein Paper mit den Analyseergebnissen geschickt, in welchem auch die Chiffre selbst beschrieben war.

Als Antwort auf das Paper erhielten wir unmissverständliche und sehr deutliche juristische Drohungen, dass das Reverse Engineering einen Urheberrechtsverstoß darstelle und von den Juristen des BSI „sehr strikt verfolgt“ würde. Daher wurden wir „dringend gebeten“ das Paper nicht zu veröffentlichen. Um dem BSI Zeit zur Fehlerbehebung zu geben und unnötige Konfrontationen zu vermeiden, haben wir eine zeitnah geplante Veröffentlichung verschoben (was im Nachhinein gesehen angesichts der langen Dauer bis zum Patch IMHO ein Fehler war). Erst als deutlich wurde, dass wir uns nicht einschüchtern lassen und das Paper definitiv irgendwann veröffentlichen werden, wurden die Drohungen telefonisch entschärft.

„Lösung“

Am 25.11.2011, über eine Woche nachdem das BSI vom Problem erfahren hat, wurde eine öffentliche Sicherheitswarnung herausgegeben; ein Sicherheitsupdate sollte in Kürze folgen. Aus „in Kürze“ wurden eineinhalb Jahre. Eineinhalb Jahre, in der eine hochkritische Sicherheitslücke in einer Verschlüsselungssoftware offen blieb. Die Sicherheitswarnung ist inzwischen auf keiner offiziellen Seite mehr aufzufinden, und hat nicht alle Kunden erreicht – in einem persönlichen Gespräch Ende 2012 war ein Nutzer über die Information überrascht und hat gesagt, dass die GSTOOL-Verschlüsselung immer noch regelmäßig benutzt werde. Das Sicherheitsupdate wurde ebenfalls kaum angekündigt, auch wir erfuhren davon nur durch Zufall, als wir auf der BSI-Website nachgeschaut haben.

Klar ist so eine dämliche Sicherheitslücke peinlich. Aber ich werde den Verdacht nicht los, dass das BSI mehr darauf bedacht war, negative Öffentlichkeit zu vermeiden, als für Sicherheit zu sorgen. Das führt dann eben dazu, dass es auch Nutzer nicht mitbekommen und so der wertlosen Verschlüsselung weiter vertrauen.

Das „Sicherheitsupdate“ bestand am Ende übrigens daraus, die Verschlüsselungs-Schaltfläche zu deaktivieren. Ohne einen Hinweis im Programm, warum das der Fall ist. Nur wer in die Update-Notizen schaut oder eine Sicherheitswarnung des BSI erhalten hat, erfährt, dass die Verschlüsselung geknackt ist.

Spielzeug

Das offensichtliche Problem, dass die GSTOOL-Verschlüsselung den unsicheren Modus ECB benutzt, war bereits Christian Gresser vom Blog „Mitternachtshacking“ aufgefallen. Und zwar 2008. Durch Zufall erfuhren wir später, dass wir auch nicht die ersten waren, die die defekte Schlüsselerzeugung gefunden haben. 2009 fragte Felix Schuster beim BSI an, ob sie daran interessiert wären, wenn er das Tool analysiert, und bekam rechtliche Drohungen als Antwort.  Er fand trotzdem die gleichen Ergebnisse wie wir, teilte sie dem BSI aber aus offensichtlichen Gründen nicht mit.

Später verwendete er ein GSTOOL-Chiffrat als Aufgabe in einem CTF-Contest – einem Wettbewerb, wo Sicherheitsexperten/Hacker in einem simulierten Netzwerk versuchen, ihre Systeme zu schützen und in die der Mitspieler einzudringen, und nebenbei noch kleine Aufgaben lösen. Die „hochsichere“ Verschlüsselung dieses von offizieller Stelle herausgegebenen Tools war also so schlecht und leicht knackbar, dass sie als Spielzeug für Hacker, eine kleine Aufgabe für zwischendurch, verwendet wurde. Immerhin gab es für die „Borg-Bureaucrats“ stolze vierhundert Punkte. Die Aufgabe wurde erfolgreich gelöst und der glückliche Gewinner hat dem BSI wohl Bescheid gesagt – vermutlich in einem relativ engen zeitlichen Zusammenhang zu unserer Meldung. (Details dazu wissen wir leider nicht)

Das würde auch erklären, warum das BSI im Advisory unsere Namen nicht nennen wollte, wie es eigentlich üblich ist, wenn man einer Organisation schon kostenlos Sicherheitslücken meldet. Wer weiß, wie viele andere das Problem schon vorher entdeckt hatten. Felix hat über die Probleme vor Kurzem einen Vortrag gehalten und die Folien online gestellt. Diese enthalten auch eine Beschreibung des Algorithmus, falls sich jemand an einer Kryptoanalyse versuchen will.

We are not alone

Das Erschreckende an dieser ganzen Sache: Wenn wir auf die Idee gekommen sind, uns GSTOOL anzuschauen, und vor uns schon mehrere andere, dann haben ausländische Geheimdienste das sicher auch gemacht. Und die Probleme sind bei einer Analyse nicht zu übersehen. Normalerweise muss sich die NSA die Mühe machen, die Zufallsgeneratoren und andere Komponenten von Kryptosystemen mittels Hintertüren zu sabotieren, hier gabs ein von Haus aus kaputtes System gratis. Und um diese Lücke zu finden, braucht es keine NSA-Experten. Das hat der chinesische Geheimdienst und jeder andere Wirtschaftsspion sicher auch hinbekommen. Kein schöner Gedanke für deutsche Unternehmen, die sich auf die Sicherheit dieser von einer für die IT-Sicherheit zuständigen Behörde herausgegebenen Software verlassen haben.

Und statt zeitnah auf eine solche Lücke zu reagieren (oder von vorne herein dafür zu sorgen, dass so etwas gar nicht erst veröffentlicht wird), bedroht das BSI lieber Sicherheitsforscher, um zu verhindern, dass solche Probleme öffentlich werden. Ohne die Drohungen hätte das BSI wohl bereits 2009 von den Problemen erfahren.

Damit hat das BSI den letzten Funken Glaubwürdigkeit in der IT-Sicherheit verloren. Schade eigentlich, denn die Chiasmus-Chiffre an sich (die vom BSI selbst entwickelt wurde) sieht sicher aus, das BSI hat also durchaus kompetente Leute (oder hatte sie zumindest damals). Für die Sicherheitsprobleme sorgen erst die Implementierungsfehler von Steria-Mummert im GSTOOL (weswegen „Chiasmus für Windows“ auch nicht von der Lücke betroffen sein sollte).

Es war eine gute Idee, dass ich damals bei der AusweisApp direkt veröffentlicht habe, statt erst das BSI zu kontaktieren. Angesichts der Erfahrungen in diesem Fall werde ich jedenfalls in Zukunft nur noch „full disclosure“ fahren (d.h. gefundene Probleme sofort öffentlich machen), wenn ich irgendwelche Lücken in „offizieller“ Software finde. Alles andere sorgt nur für unnötig Stress, Verzögerungen und unter-den-Teppich-kehren.

Auch Kontakt mit dem BSI gehabt? Kunde/Nutzer von GSTOOL und Hinweise vom BSI bekommen (oder eben nicht)? Ich freue mich über Rückmeldungen über die Kommentarfunktion oder per E-Mail!

Fußnoten:

1) Eine Chiffre nicht zu veröffentlichen ist unüblich und gilt als verpönt – eine gute Chiffre ist auch dann sicher, wenn der Angreifer sie kennt, solange er den Schlüssel nicht hat. Vor den wirklich „Bösen“ kann man die Chiffre nicht langfristig geheimhalten, aber wenn die Chiffre nicht öffentlich ist, bleiben Schwächen oft lange für die Nutzer der Chiffre verborgen.

2) AES und Twofish wurden 1998 publiziert. Die erste Referenz zu Chiasmus, die wir finden konnten, erwähnt Chiasmus für Windows in Version 1.3 und ist aus dem Dezember 2001.

Advisory: Unsichere Verschlüsselung bei GSTOOL

=== Betroffene Produkte ===
Betroffen ist die Verschlüsselungsfunktion des GSTOOL in den Versionen 3.0 bis 4.7 (einschließlich) sowie die mit diesen Versionen erstellten Schlüssel und damit verschlüsselte Dateien. Die Version 4.8 (auch bekannt als GSTOOL 4.5, 4.6 oder 4.7 Service Pack 3) ist nicht betroffen, da in dieser Version die Verschlüsselungsfunktion entfernt wurde. Nicht betroffen ist die Kernfunktion des GSTOOL, das erstellen von Sicherheitskonzepten. Nur Anwender, die die Verschlüsselungsfunktion nutzen, sind betroffen.

Das GSTOOL unterstützt Anwender bei Erstellung, Verwaltung und Fortschreibung von Sicherheitskonzepten entsprechend dem IT-Grundschutz und wird vor allem von öffentlichen Stellen und Dienstleistern eingesetzt. Die Verschlüsselungsfunktion ist lediglich eine Zusatzfunktion, wird durch die entdeckten Sicherheitslücken aber weitgehend unwirksam: Angreifer können mit alten GSTOOL-Versionen verschlüsselte Dateien innerhalb weniger Minuten mit einem gewöhnlichen Computer ohne Kenntnis des Schlüssels entschlüsseln. Ursache ist die unsachgemäße Schlüsselerzeugung durch falsche Verwendung eines Zufallszahlengenerators. Diese Versionen 3.0-4.7 des GSTOOLs wurden von Steria Mummert Consulting im Auftrag und Namen des BSI entwickelt. <http://de.wikipedia.org/wiki/GSTOOL>

Nicht betroffen ist die Sicherheit der Blockchiffre „CHIASMUS“ an sich, da es sich um Implementierungsfehler in GSTOOL handelt. Das Produkt „CHIASMUS für Windows“ verwendet eine unabhängige Implementierung und wir vermuten, dass es nicht von dieser Schwachstelle betroffen ist

=== Problembeschreibung ===
Die kryptographischen Schlüssel werden mit einem ungeeigneten Verfahren erzeugt, wodurch die Stärke der Schlüssel auf maximal 31 Bit (in der Praxis meist deutlich weniger) beschränkt wird. Dadurch können die Schlüssel innerhalb von Minuten, meist aber in wenigen Sekunden, mittels eines angepassten Brute-Force-Angriffs bestimmt werden. Die mit den betroffenen Versionen von GSTOOL verschlüsselten Dateien können somit mit minimalem Aufwand auch ohne Kenntnis des Schlüssels entschlüsselt werden.

Weitere Probleme sind die Verwendung der Betriebsart ECB für die Blockchiffre sowie das Fehlen von Integritäts- und Plausibilitätsprüfungen für Dateien und Schlüssel.

=== Gegenmaßnamen ===
Die Verschlüsselungsfunktion enthält mehre Fehler, so dass das Problem nicht einfach zu beheben ist. Das BSI hat sich dafür entschlossen, die Funktion ganz aus GSTOOL zu entfernen. Wir halten das für eine sehr gute Entscheidung. Anwender sollten davon ausgehen, dass ihre Chiffrate kompromittiert sind, und sie so weit möglich dort löschen, wo Dritte potentiell Zugang zu den Chiffraten haben (Cloud-Anbieter, Dropbox, unverschlüsselte Laptop-Festplatten, Tablet und Smartphones).

Als Alternative bleibt für öffentliche Stellen der Einsatz von „CHIASMUS für Windows“. Die Software ist allerdings nicht öffentlich zugänglich und der Quellcode wurde nicht veröffentlicht, so dass wir die Sicherheit dieser Software nicht beurteilen können. Die Dateiformate sind ebenfalls nicht kompatibel.

Als beste Lösung sehen wir den Einsatz von Festplattenverschlüsselungssoftware (FDE) für Computer, auf denen mit GSTOOL gearbeitet wird, sowie den Einsatz von GnuPG/Gpg4win für das sichere Verschicken von GSTOOL-Datenbanken. Die Software ist kostenlos nutzbar, der Quelltext ist öffentlich einsehbar, und die Entwicklung wurde vom BSI gefördert. Das BSI selbst empfiehlt dieses Tool explizit: https://www.bsi.bund.de/DE/Themen/ProdukteTools/Gpg4win/gpg4win_node.html

=== Beteiligte ===
Jan Schejbal
Erik Tews
Julian Wälde

=== Ähnliche Forschung ===
Christian Gresser berichtete in seinem Blog „Mitternachtshacking“ bereits 2008 über die Verwendung der Betriebsart ECB: http://www.mitternachtshacking.de/blog/727-snake-oil-alarm-chiasmus-im-gstool

Wie uns nachträglich bekannt wurde, hat Felix Schuster (Ruhr-Uni­ver­si­tät Bo­chum) bereits im Jahr 2009 dieses Problem unabhängig von unserer Forschung entdeckt. Da das BSI nach einer anfängliche Kontaktaufnahme eine Analyse des GSTOOL durch ihn vehement ablehnte, wurde die Arbeit nicht veröffentlicht und das BSI nicht über die Ergebnisse informiert. Eine Präsentation seiner Ergebnisse kann seit Kurzem unter http://prezi.com/bzyvzzdsxtkm/ubicrypt-chm/ abgerufen werden.

GSTOOL-Chiasmus-Chiffrate wurden laut Felix Schuster beim Hack.lu CTF 2011 als eine der Aufgaben verwendet und von einem Teilnehmer erfolgreich geknackt, welcher vermutlich das BSI kontaktiert hat. Details sind uns leider nicht bekannt.

Sofern andere Forscher sich ebenfalls mit dem Thema beschäftigt und/oder das BSI kontaktiert haben, würden wir uns über eine Kontaktaufnahme freuen – Kontaktdaten siehe <http://www.janschejbal.de/impressum.shtml>.

=== Patch ===
Das BSI hat in einem Advisory am 25.11.2011 dazu geraten, die Verschlüsselungsfunktion nicht zu verwenden, alternative Verschlüsselungslösungen einzusetzen und evtl. öffentlich verfügbare verschlüsselte Dateien zurückzuziehen. Das Advisory ist inzwischen nur noch auf Drittseiten auffindbar, z. B. <http://goo.gl/lVoHL>, die Empfehlungen sind jedoch korrekt.

In der Version 4.8 (auch bekannt als „Servicepack 3 für GSTOOL 4.5“) wurde die Verschlüsselungsfunktion deaktiviert. <http://goo.gl/3Sjb5>

=== Timeline ===
Alle Ereignisse in chronologischer Reihenfolge (nicht der Reihenfolge in der sie uns bekannt wurden):

2008-09-24 Blog-Posting von Chrisitan Gresser, Hinweis darauf dass die Verschlüsselung von GSTOOL nicht vollständig sicher ist.
2009 Erste Arbeiten von Felix Schuster, Anfrage beim BSI ob eien Sicherheitsanalyse von GSTOOL erwünscht ist, Anfrage wurde abgelehnt.
2011-09-19 hack.lu CTF
2011 Erste Arbeiten von uns, Analyse. Dabei wurden die Schwachstellen der Implementierung entdeckt.
2011-11-14 Kontaktaufnahme mit dem BSI, Demonstration der Lücke
später exakte Fehlerbeschreibung (telefonisch)
2011-11-25 Advisory des Herstellers, Ankündigung Servicepack

Weitere Kommunikation und Ratschläge zur Fehlerbehebung

2011-12-06 Hinweis von Seiten des BSI, dass sie Reverse Engineering bei GSTOOL ihrer Meinung nach nicht erlaubt ist und Bitte, von der Veröffentlichung von Analyseergebnissen der Chiffre abzusehen.

2011-2013 Mehrfache Statusnachfragen unsererseits

2013-06-06 (ca.) Erscheinen des Servicepacks, keine Benachrichtigung.
2013-07-22 UbiCrypt Summerschool in Bochum mit Vortrag von Felix Schuster
2013-09-11 Veröffentlichung dieses Advisories

Bundestag kann SSL abhören

Der Bundestag kann SSL-gesicherte Verbindungen abhören. SSL ist vielen vielleicht nur als „https“ bekannt und sichert neben Onlinebanking auch z. B. Verbindungen zu E-Mail-Servern und ziemlich viele andere Sachen. (Kurzzusammenfassung für Leute die sich mit SSL auskennen: Der Bundestag hat ne CA. Der Artikel erklärt halbwegs laienfreundlich genau das, die Grundidee hinter SSL und warum SSL kaputt ist.)

SSL funktioniert so: Eine vertrauenswürdige Stelle stellt dem Server einen Ausweis aus, den er vorzeigt, und darüber wird die Verbindung verschlüsselt. Das nennt sich Zertifikat und die technischen Details habe ich schonmal erklärt, hier will ich es einfach halten. Ein Angreifer kann sich in die Verbindung nicht einklinken, weil er keinen passendes Zertifikat hat (nur der Besitzer oder jemand der das Original kopiert hat kann ein Zertifikat zeigen, weil beim Zeigen ein Teil geheim bleibt. Klingt komisch, ist aber Mathematik.)

In jedem Browser ist eine Liste der aus Sicht des Browsers vertrauenswürdigen Stellen enthalten. Das sind ungefähr 50 Stück und zwar auch solche, die man vielleicht nicht ganz so vertrauenswürdig findet, wie z. B. die chinesische Internetbehörde.

Die Sicherheit von SSL beruht darauf, dass ein Angreifer kein Zertifikat bekommt für die Seite, deren Datenverkehr er abhören will. Wenn jemand den Datenverkehr zur Postbank abhören will, muss er also jemanden finden, der ihm ein Zertifikat ausstellt, was bestätigt dass ihm Postbank.de gehört. Das kann aber jede der vertrauenswürdigen Zertifizierungsstellen.

Es wird noch „besser“: Die Zertifizierungsstellen können jedermann zu einer Zertifizierungsstelle machen. Derjenige hat dann die gleichen Möglichkeiten wie die im Browser eingetragenen Zertifizierunsstellen. Neben den 50 Stellen können also noch viele viele weitere ein falsches Zertifikat ausstellen – und mit einem solchen kann man eine eigentlich gesicherte Verbindung abhören. (Das funktioniert so, dass der Angreifer die Verbindung über sich umleitet und behauptet, er sei die Postbank – über das Zertifikat prüft der Browser ob das stimmt.)

Zertifizierungsstellen kürzt man übrigens mit CA ab.

SSL ist also unsicher, wenn

• Eine einzige dieser CAs einen Fehler macht und ein Zertifikat ausstellt ohne zu merken, dass der Angreifer nicht die Postbank ist
• Eine CA dem Angreifer bewusst oder z. B. über einen erpressten Mitarbeiter ein falsches Zertifikat ausstellt (man denke an Geheimdienste oder Industriespionage, viele CAs werden von Regierungen/regierungsnahen Organisationen und noch mehr von Firmen die eigentlich was ganz anderes machen betrieben)
• Der Angreifer eine eigene CA hat/ist/kauft
• eine Sicherheitslücke im Protokoll oder im benutzten Browser/Server auftaucht
• oder irgendwas was ich vergessen hab passiert

Fehler sind schon oft passiert. Ein paar Forscher haben mal das Internet nach SSL-Zertifikaten abgegrast und das zusammen mit ein paar anderen Sicherheitsproblemen auf der DefCon präsentiert. Sie sind auf über 500 Organisationen gekommen die direkt oder indirekt eine CA haben.

Weiterhin haben sie gemerkt, dass CAs ca. 500 noch gültige Zertifikate, die praktisch „geknackt“ sind (durch eine Sicherheitslücke bei Debian) nicht für ungültig erklärt haben, und gültige Zertifikate für private IPs. Das ist in etwa so wie ein Ausweis der bestätigt dass Büro Nummer 37 einer bestimmten Person gehört – ohne zu sagen, von welchem Haus in welcher Stadt man redet. Das scheint übrigens dann das Ausnutzen eine anderen Sicherheitslücke zu erlauben (vereinfacht: man sagt dem Nutzer, dass er die Postbank im gleichen Flur in Büro 37 suchen soll, geht in dieses fremde Büro und zeigt dann wenn der Nutzer kommt den Ausweis vor. Deswegen darf es so einen Ausweis eigentlich nicht geben).

Ach ja, und um zu prüfen, ob jemandem eine Domain gehört, wird eine Mail verschickt. Über oft unverschlüsseltes SMTP. Nachdem über bisher ungesichertes DNS nachgeschaut wurde, wohin die Mail gehen soll. Wenn also jemand es schafft, eine dieser Verbindungen zu manipulieren, bekommt er falsche Zertifikate.

Trotzdem sollte man SSL benutzen. Ohne SSL kann ein Angreifer einfach so mithören, was passiert. Mit SSL muss er selbst bei groben Sicherheitsproblemen (z. B. Zertifikate gar nicht prüfen) auch Kommunikation manipulieren statt einfach nur mitzuhören (geht recht leicht, ist aber eine Hürde). Selbst wenn eine CA falsche Zertifikate ausstellt, muss der Angreifer diese finden und sie muss auch ihm so ein Zertifikat geben. Wenn z. B. die Telekom dem BND ein Zertifikat geben würde (was ich jetzt nicht unterstellen möchte), würde sie es immer noch nicht mit einem gewöhnlichen Kriminellen tun. Auch hier wird also eine Hürde geschaffen.

Schützen kann man sich nur bedingt. Die Firefox-Extension CertPatrol zeigt an, wenn sich ein Zertifikat ändert, und auf Wunsch auch bei neuen Zertifikaten, wer es ausgestellt hat. Dabei machen sowohl die Extension als auch Firefox (beim Klick auf das blaue „gesicherte Verbindung“-Feld in der Adressleiste) einen groben Fehler, den ich hier allerdings noch nicht erklären werde. Erinnert mich in nem Monat dran wenn ich nicht dran denke. (Update: In CertPatrol inzwischen behoben – es wird/wurde nur die CA angezeigt, die das Zertifikat ausgestellt hat. Ein Angreifer, der eine falsche CA hat, kann aber erst eine andere falsche CA mit beliebigem Namen erstellen, und damit dann das Cert ausstellen.) Mit dieser Extension habe ich auch gemerkt, dass der E-Petitionsserver des Bundestags plötzlich ein von der mir bis dahin unbekannten Bundestags-CA ausgestelltes Zertifikat hat. Damit könnte der Bundestag theoretisch falsche Zertifikate ausstellen und so SSL-Verbindungen abhören.

Beim Ausstellen falscher Zertifikate geht die CA aber ein gewisses Risiko ein – normale Nutzer merken das nicht, aber wenn es mal einer mit z. B. CertPatrol merkt und das Zertifikat abspeichert, kann die CA sich nicht völlig herausreden, das Zertifikat verrät unabstreitbar wer es ausgestellt hat. Sie muss es auf einen Fehler schieben und hoffen dass nichts passiert. Wenn sich solche Fehler häufen, düfte die CA aus den Vertrauenslisten in den Browsern rausfliegen und andere CAs dürften sich hüten, diese Organisation wieder in den CA-Status zu heben. Um Zertifikate direkt abspeichern zu können, wenn sie auftauchen (und so das Risiko zu vermeiden, dass beim Abruf mit einem anderen Tool wieder das „saubere“ Zertifikat drin ist), kann man die Extension Cert Viewer Plus nutzen.

Die Bundestags-CA wurde vom DFN (Deutsches Forschungsnetz) bestätigt, welches wiederum seine CA von der Telekom bestätigt bekommen hat. Hier die Zertifikate:

Certification path for "epetitionen.bundestag.de"
Inhaber: C=DE,ST=Berlin,L=Berlin,O=Deutscher Bundestag,OU=PetA,CN=epetitionen.bundestag.de
Aussteller: C=DE,O=Deutscher Bundestag,OU=Deutscher Bundestag,CN=Deutscher Bundestag CA - G01,E=pki-ca@bundestag.de
Validität: from 2010-09-27 13:09:06 UTC to 2015-09-26 13:09:06 UTC
-----BEGIN CERTIFICATE-----
MIIFYDCCBEigAwIBAgIEEMAVAjANBgkqhkiG9w0BAQUFADCBlDELMAkGA1UEBhMC
REUxHDAaBgNVBAoTE0RldXRzY2hlciBCdW5kZXN0YWcxHDAaBgNVBAsTE0RldXRz
Y2hlciBCdW5kZXN0YWcxJTAjBgNVBAMTHERldXRzY2hlciBCdW5kZXN0YWcgQ0Eg
LSBHMDExIjAgBgkqhkiG9w0BCQEWE3BraS1jYUBidW5kZXN0YWcuZGUwHhcNMTAw
OTI3MTMwOTA2WhcNMTUwOTI2MTMwOTA2WjB/MQswCQYDVQQGEwJERTEPMA0GA1UE
CBMGQmVybGluMQ8wDQYDVQQHEwZCZXJsaW4xHDAaBgNVBAoTE0RldXRzY2hlciBC
dW5kZXN0YWcxDTALBgNVBAsTBFBldEExITAfBgNVBAMTGGVwZXRpdGlvbmVuLmJ1
bmRlc3RhZy5kZTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANxlR8dG
FjtzBE05l7RKRgQwy6DSzLE8qeoPuycX4VrYvgRdX0NyeoZ3h9MqT0DJHvXAWS+d
BHkNrnhRHFf4cxZsIbSjnrSr311QUmwityCoinESNqXAdY/i466/TEE+GcUOS4t2
Mfmba8Zi3qKGspgcGec14xuyNc8ENlKvTjKBC+mJrjlh/Gpb3VW/rNh65V8EXvbW
vlXbyDbZ/5n57TZqM2bblPWRnh/Zual54Y/khqlPdWuNxHMSr+OtvgXW/aJGWOzh
uusPIzxp1uYgd7PMCvP5aHf1w5mMy3Em1c6w8PiH7Fq1yDa1CbpFpq+SHQ0NF2lu
lQecru1cdFefpsUCAwEAAaOCAcwwggHIMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgXg
MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDATAdBgNVHQ4EFgQUJUpy4/No
XDOu0LAY+DNj7g+E51QwHwYDVR0jBBgwFoAUd42VgQQK41VYmdALyblb5SJ+LjYw
gZkGA1UdHwSBkTCBjjBFoEOgQYY/aHR0cDovL2NkcDEucGNhLmRmbi5kZS9kZXV0
c2NoZXItYnVuZGVzdGFnLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMEWgQ6BBhj9odHRw
Oi8vY2RwMi5wY2EuZGZuLmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2Ny
bC9jYWNybC5jcmwwgbIGCCsGAQUFBwEBBIGlMIGiME8GCCsGAQUFBzAChkNodHRw
Oi8vY2RwMS5wY2EuZGZuLmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2Nh
Y2VydC9jYWNlcnQuY3J0ME8GCCsGAQUFBzAChkNodHRwOi8vY2RwMi5wY2EuZGZu
LmRlL2RldXRzY2hlci1idW5kZXN0YWctY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0
MA0GCSqGSIb3DQEBBQUAA4IBAQB4XvDdQcukMgEEvgLklMuAjrU7GT4SgyiHZCkY
hcEqqOHA0WiP6i1H66MTui00TDVv9QRpjnMgy9jD0QXynWgHG0F07ZrpO+8YBQvL
NsuslkYr9SXMnOOw3AfwDTUbo+sLKWaRiBiVeP6WOrbtCddrbmMvWexf/1M8dx/E
ynIEIyhRgXD/1YyFLzi85I8UP4eCKa38HPxIgI5An5baOjA4rgOH/LyAKV+9659T
/vjTZZ4R2t/ratiLZEoZ1byUqdit3msDQoq5YXKF5DVgMGF+jL6V+wXg8Vu10ajg
KO6AxrzMS+WBgY4PXuwLMY3iO8GL8s0IlAtMu9Ew0svPAH2V
-----END CERTIFICATE-----
Inhaber: C=DE,O=Deutscher Bundestag,OU=Deutscher Bundestag,CN=Deutscher Bundestag CA - G01,E=pki-ca@bundestag.de
Aussteller: C=DE,O=DFN-Verein,OU=DFN-PKI,CN=DFN-Verein PCA Global - G01
Validität: from 2008-12-17 14:39:27 UTC to 2019-06-30 00:00:00 UTC
-----BEGIN CERTIFICATE-----
MIIFJDCCBAygAwIBAgIEDWiMrzANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJE
RTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZOLVBLSTEkMCIGA1UE
AxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA4MTIxNzE0MzkyN1oX
DTE5MDYzMDAwMDAwMFowgZQxCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0c2No
ZXIgQnVuZGVzdGFnMRwwGgYDVQQLExNEZXV0c2NoZXIgQnVuZGVzdGFnMSUwIwYD
VQQDExxEZXV0c2NoZXIgQnVuZGVzdGFnIENBIC0gRzAxMSIwIAYJKoZIhvcNAQkB
FhNwa2ktY2FAYnVuZGVzdGFnLmRlMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEAyV2H0tJjqK2L25XRrdkSyAmCm5AO71u+xAme6ppAunax/aW11Bhn2cet
N3nj0govnSVnOCre2inqvm49d/MVj0zyhhw7v5AG2Ab5WK/4TryLofCHJEEn+1oy
CWnNqBQIjFLawUbhfjOOspPxLujDTdaYDn7Z00nY85c7cRESdW3BbeL0a2OrSJyJ
yW93nR/+of9tsyTLsy9LiKZvRaGnXtYUDy/Sq3MSpgiWjsq95VFBT0lMBE1J+xv7
4ZrXikfZs+o3cfVxFQluLPwmxSqrd4BmH6rTxUb9iFLWwEFWJIYLlV8Z6GG9kxOd
KG9Q+T3QxUqi0Mw7/5hrl8Zs0wXbDQIDAQABo4IBtTCCAbEwEgYDVR0TAQH/BAgw
BgEB/wIBATALBgNVHQ8EBAMCAQYwHQYDVR0OBBYEFHeNlYEECuNVWJnQC8m5W+Ui
fi42MB8GA1UdIwQYMBaAFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB4GA1UdEQQXMBWB
E3BraS1jYUBidW5kZXN0YWcuZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8v
Y2RwMS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3Js
MD2gO6A5hjdodHRwOi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1
Yi9jcmwvY2FjcmwuY3JsMIGiBggrBgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7
aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwtcm9vdC1jYS9wdWIvY2FjZXJ0
L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBjYS5kZm4uZGUv
Z2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB
BQUAA4IBAQCTl0KbJX0XEEVgNkLeS/dmgJzwcSC6z8aFvhQPzbE08Q/qhWItV4iU
YYZ9nkfuoKzoz1V1CoqEFhE7QRKr0OLMHVs+yJnWXfWEuQ11ph6KMEAvK8b/9J0O
Hz83WRO7pqZp1VWZGZ0Prj3CWkqxUEmFiPcCC3N1pRcVvufimpchB3SA2NeUKE4C
G2fo3XT3q99ltN53wAPGXhqzSVXO8zYIW+bglion3IdeYna/Hzx94RpXNKl5q4pK
e0lSRUtj0k0yWS/YDptFsVPhr5wLm+uVXz/G43/7I5TYEZ56Yz6LqUhrY59XkSeG
6trUzc7DpXEZWvoqFQy/0jonReRX15x9
-----END CERTIFICATE-----
Inhaber: C=DE,O=DFN-Verein,OU=DFN-PKI,CN=DFN-Verein PCA Global - G01
Aussteller: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Validität: from 2006-12-19 10:29:00 UTC to 2019-06-30 23:59:00 UTC
-----BEGIN CERTIFICATE-----
MIIEITCCAwmgAwIBAgICAMcwDQYJKoZIhvcNAQEFBQAwcTELMAkGA1UEBhMCREUx
HDAaBgNVBAoTE0RldXRzY2hlIFRlbGVrb20gQUcxHzAdBgNVBAsTFlQtVGVsZVNl
YyBUcnVzdCBDZW50ZXIxIzAhBgNVBAMTGkRldXRzY2hlIFRlbGVrb20gUm9vdCBD
QSAyMB4XDTA2MTIxOTEwMjkwMFoXDTE5MDYzMDIzNTkwMFowWjELMAkGA1UEBhMC
REUxEzARBgNVBAoTCkRGTi1WZXJlaW4xEDAOBgNVBAsTB0RGTi1QS0kxJDAiBgNV
BAMTG0RGTi1WZXJlaW4gUENBIEdsb2JhbCAtIEcwMTCCASIwDQYJKoZIhvcNAQEB
BQADggEPADCCAQoCggEBAOmbw2eF+Q2u9Y1Uw5ZQNT1i6W5M7ZTXAFuVInTUIOs0
j9bswDEEC5mB4qYU0lKgKCOEi3SJBF5b4OJ4wXjLFssoNTl7LZBF0O2gAHp8v0oO
GwDDhulcKzERewzzgiRDjBw4i2poAJru3E94q9LGE5t2re7eJujvAa90D8EJovZr
zr3TzRQwT/Xl46TIYpuCGgMnMA0CZWBN7dEJIyqWNVgn03bGcbaQHcTt/zWGfW8z
s9sPxRHCioOhlF1Ba9jSEPVM/cpRrNm975KDu9rrixZWVkPP4dUTPaYfJzDNSVTb
yRM0mnF1xWzqpwuY+SGdJ68+ozk5SGqMrcmZ+8MS8r0CAwEAAaOB2TCB1jBwBgNV
HR8EaTBnMGWgY6Bhhl9odHRwOi8vcGtpLnRlbGVzZWMuZGUvY2dpLWJpbi9zZXJ2
aWNlL2FmX0Rvd25sb2FkQVJMLmNybD8tY3JsX2Zvcm1hdD1YXzUwOSYtaXNzdWVy
PURUX1JPT1RfQ0FfMjAdBgNVHQ4EFgQUSbfGz+g9H3/qRHsTKffxCnA+3mQwHwYD
VR0jBBgwFoAUMcN5G7r1U9cX4Il6LRdsCrMrnTMwDgYDVR0PAQH/BAQDAgEGMBIG
A1UdEwEB/wQIMAYBAf8CAQIwDQYJKoZIhvcNAQEFBQADggEBADvhWnfASBfcqRjs
ga9aifC9KJKmylkYEnDsKPLnrn+WLOfyXRkx9hMrdL29gLK592fJOaJ5O+EREe5r
eJEzfjtfJid1U2WOM2Puz3PDsJIjSSFQdSOhHxjilIU9PzPpdyCNor3moYUpQPY/
czJYDQlrptqFbMA/u41mZFYkTq4NPzI1AVvpjILZcllPsYaF8XSFVuXD+Fzzje5H
s1MFcOflTYppgyjhEwmGnl7I6lgeDB/5pNRaBGj9KD6LArZYtfahLDdXAGerI2iN
Y6XvmWtc/UtW9qtAhzTUEZJs7IfFCgsHM3K0bwwdVCzYUcfMvzDTQ3LxMr+Mzklj
qAD38hw=
-----END CERTIFICATE-----
Inhaber: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Aussteller: C=DE,O=Deutsche Telekom AG,OU=T-TeleSec Trust Center,CN=Deutsche Telekom Root CA 2
Validität: from 1999-07-09 12:11:00 UTC to 2019-07-09 23:59:00 UTC
-----BEGIN CERTIFICATE-----
MIIDnzCCAoegAwIBAgIBJjANBgkqhkiG9w0BAQUFADBxMQswCQYDVQQGEwJERTEc
MBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxlU2Vj
IFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290IENB
IDIwHhcNOTkwNzA5MTIxMTAwWhcNMTkwNzA5MjM1OTAwWjBxMQswCQYDVQQGEwJE
RTEcMBoGA1UEChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEfMB0GA1UECxMWVC1UZWxl
U2VjIFRydXN0IENlbnRlcjEjMCEGA1UEAxMaRGV1dHNjaGUgVGVsZWtvbSBSb290
IENBIDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCrC6M14IspFLEU
ha88EOQ5bzVdSq7d6mGNlUn0b2SjGmBmpKlAIoTZ1KXleJMOaAGtuU1cOs7TuKhC
QN/Po7qCWWqSG6wcmtoIKyUn+WkjR/Hg6yx6m/UTAtB+NHzCnjwAWav12gz1Mjwr
rFDa1sPeg5TKqAyZMg4ISFZbavva4VhYAUlfckE8FQYBjl2tqriTtM2e66foai1S
NNs671x1Udrb8zH57nGYMsRUFUQM+ZtV7a3fGAigo4aKSe5TBY8ZTNXeWHmb0moc
QqvF1afPaA+W5OFhmHZhyJF81j4A4pFQh+GdCuatl9Idxjp9y7zaAzTVjlsB9WoH
txa2bkp/AgMBAAGjQjBAMB0GA1UdDgQWBBQxw3kbuvVT1xfgiXotF2wKsyudMzAP
BgNVHRMECDAGAQH/AgEFMA4GA1UdDwEB/wQEAwIBBjANBgkqhkiG9w0BAQUFAAOC
AQEAlGRZrTlk5ynrE/5aw4sTV8gEJPB0d8Bg42f76Ymmg7+Wgnxu1MM9756Abrsp
tJh6sTtU6zkXR34ajgv8HzFZMQSyzhfzLMdiNlXiItiJVbSYSKpk+tYcNthEeFpa
IzpXl/V6ME+un2pMSyuOoAPjPuCp1NJ70rOo4nI8rZ7/gFnkm0W09juwzTkZmDLl
6iFhkOQxIY40sfcvNUqFENrnijchvllj4PKFiDFT1FQUhXB59C4Gdyd1Lx+4ivn+
xbrYNuSD7Odlt79jWvNGr4GUN9RBjNYj1h7P9WgbRGOiWrqnNVmh5XAFmw4jV5mU
Cm26OWMohpLzGITY+9HPBVZkVw==
-----END CERTIFICATE-----

Einzelne CAs im Browser rauswerfen bringt wenig, weil gerade die kleinen/neuen CAs oft (nicht öffentlich sichtbare!) Bestätigungen von anderen CAs haben. Wenn man eine CA rauswirft, die viele Zertifikate ausstellt, kann man deren Zertifikate nicht mehr von gefälschten unterscheiden. Da man nicht jedes Zertifikat manuell prüfen kann – ganz schlecht. Am Sinnvollsten dürfte CertPatrol sein und für kritische Sachen eben auf die Warnungen achten und beim ersten Mal das Zertifikat genau prüfen. Interessanterweise hat Microsoft dieses Problem scheinbar erkannt – bei WLAN-Verbindungen wo die Anmeldung über Zertifikate gesichert wird muss man ausdrücklich auswählen, welchen CAs man für diesen Zweck traut, und nur die werden akzeptiert. So kann eine Firma sicherstellen, dass ihre Rechner für die Anmeldung in ihrem WLAN nur ihrer eigenen CA und nicht der des Konkurrenten trauen. Und in der Fehlermeldung wird unterschieden zwischen „Zertifikat einer unbekannten CA“ und „Zertifikat einer bekannten aber nicht angekreuzten CA“ sodass man sich zumindest halbwegs sicher verbinden kann, wenn man die richtige CA nicht weiß.

Für Serverbetreiber gilt: Es spielt keine Rolle, wie sicher die CA ist, die man wählt – wichtig ist nur, welche CA in den Browsern akzeptiert wird. Selbst erstellte (nicht von einer CA bestätigte) Zertifikate sind eine relativ schlechte Lösung – eine CA bietet zusätzlich die Möglichkeit, halbwegs sicher zu sein, selbst wenn man das Zertifikat nicht selbst prüfen konnte. Kostenlose Zertifikate für Webserver gibts bei StartSSL, was bis auf Opera von allen Browsern akzeptiert wird. Das oft vorgeschlagene CAcert ist in den meisten Browsern standardmäßig nicht enthalten und daher IMHO nur zweite Wahl – bietet dafür aber auch andere Zertifikatstypen an.

Fefe hat das Thema auch schon kommentiert und ein weiteres Horrorgeschichtenkabinett findet sich in den „A mighty fortress is our PKI“-Mails von Peter Gutmann: Teil 1, Teil 2, Teil 3

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.

Infos frisch vom BKA

Ich hatte das große Glück, vor einer Woche einen Vortrag des Vizepräsidenten des Bundeskriminalamtes, Prof. Dr. Jürgen Stock, hören zu dürfen. Der Vortrag war sehr interessant und informativ, und ich möchte hier einen kurzen Überblick geben, da der Vortrag leider nur in einem kleinen Rahmen stattfand. Bei dem Vortrag ging es um die Kriminalitätsbekämpfung im Spannungsfeld von Sicherheit und Freiheit.

Zunächst hat Prof. Stock deutlich gesagt, dass Deutschland eines der sichersten Länder ist und die Kriminalität stetig zurückgeht. Der Rückgang von 6,75 Mio. Delikten im Jahr 1993 auf 6,3 Mio. im Jahr 2006 wurde leider anhand eines Diagrammes gezeigt, dessen Y-Achse von 6 bis 7 Mio. ging – auf den ersten Blick sah es also so aus, als wäre die Kriminalitätsrate um über 30% zurückgegangen. Die Jugendkriminalität soll übrigens entgegen dem Eindruck, den man aus den Medien erlangen könnte, eher abnehmen, dafür werden immer mehr Bagatellen auf dem Rechtsweg gelöst (ein Kind, welches einem anderen beim Spielen im Sandkasten die Schippe wegnimmt, begeht rein rechtlich gesehen unter Umständen einen Raub).

Der Terrorismus hingegen nimmt zu, so soll es weltweit 2005 zu ca. 2000 Terroranschlägen gekommen sein, während es im Jahr 2001 „nur“ ca. 700 waren. Der Großteil davon passiert aber in instabilen Ländern oder in Afghanistan oder im Irak. In der EU soll es entweder 2005 oder 2006 (bin mir nicht mehr sicher) zu 500 Terroranschlägen gekommen sein. Leider habe ich vergessen zu fragen, was dabei als Terroranschlag zählt – schließlich wurden lange Zeit auch die von der „militanten gruppe“ angezündeten leeren Autos dazu gezählt. Es soll derzeit übrigens ca. 230 terrorbezogene Ermittlungen in Deutschland geben.

Noch viel interessanter aber war die Erwähnung der Tatsache, dass fast jeder Mensch in seinem Leben irgendeine Straftat begeht. Wenn also alle Straftaten bekannt würden, wäre das nicht unbedingt im Sinne der Gesellschaft, da sowohl die Polizei überlastet würde als auch fast jeder betroffen wäre.

Weiterhin wurde erwähnt, dass bei einer repräsentativen Umfrage die deutsche Bevölkerung ein hohes Vertrauen gegenüber der Polizei hatte – mehr, als gegenüber dem Bundespräsidenten oder dem Bundesverfassungsgericht (wobei ich allerdings davon ausgehe, dass das auch am mandelnden Bekanntheitsgrad bzw. Mangel an Sichtbarkeit in der Öffentlichkeit liegen könnte – die Polizei kennt jeder und sieht jeder oft, den Bundespräsidenten hingegen weniger).

Als großes Problem wurde die zunehmende Internetkriminalität dargelegt. Dabei geht es aber nicht (nur) um ein paar eBay-Betrügereien, sondern eher um gezielte DDoS-Angriffe (bei denen Kriminelle fremde Server überlasten, meist wird dann Geld erpresst) und ähnliche Aktivitäten großen Ausmaßes.

Sehr begrüßenswert fand ich, dass Prof. Stock selbst bei den Personen, die im September mit einigen hundert kg Wasserstoffperoxid in Oberschledorn aufgegriffen wurden, (sinngemäß) von „mutmaßlichen Terroristen“ sprach, also die Unschuldsvermutung hochhielt – schließlich sind diese Personen noch nicht verurteilt. Insbesondere in diesem Fall hat es mich sehr positiv überrascht – bleibt zu hoffen, dass es beim BKA und in der Politik noch viele solcher Menschen gibt.

Die „homegrown terrorists“, also erst in Deutschland radikalisierte Menschen, sollen nicht nur aus eher fundamentalistischen, schlecht integrierten Kreisen stammen, sondern oft auch vorher gemäßigte, gut integrierte Bürger gewesen sein. Das bedeutet dann wohl, dass jeder ein potentieller Terrorist ist.

Auch das Thema Internet, auch bekannt als „Fernuniversität des Terrors“, wurde aufgegriffen. Diesen neuen „Fachbegriff“ für das Netz hat Prof. Stock auch angemessen gewürdigt, nämlich dargelegt, was es für eine Übertreibung sei. Das Internet wurde wiederholt als eine sehr gute Einrichtung bezeichnet, auch wenn Terroristen darüber Bomebenbaupläne bekommen können, wie es wohl im Kofferbomber-Fall passiert ist. (Dabei möchte ich nochmals daran erinnern, dass die Kofferbomben nicht funktionstüchtig waren – das kommt davon, wenn man jeden Scheiß, den man im Internet findet, gleich nachbauen muss, und das ist der Grund, warum ich nicht besonders viel Angst vor Terroristen habe, die sich ihre Bastelanleitungen aus dem Netz holen – eine nicht zu unterschätzende Gefahr dürfte aber darin liegen, dass sie sich bei der Herstellung versehentlich selbst in die Luft jagen und noch ein paar Nachbarn mitnehmen.)

Genauer erläutert wurde auch die Trennung zwischen den Geheimdiensten (BND, Verfassungsschutz, MAD) und den Polizeibehörden – obwohl eine strikte organisatorische Trennung herrscht, wird ein sehr reger Datenaustausch betrieben, z. B. auch über das „Gemeinsame Terrorabwehrzentrum“ und die Anti-Terror-Datei oder europaweit über das Schengener Informationssystem. Wie stark das jetzt in die – übrigens nicht im Grundgesetz verankerte – Trennung zwischen Polizei und Geheimdiensten verletzt, die aufgrund von schlechten Erfahrungen eingeführt wurde, muss jeder selbst entscheiden. Es werden sicher nicht Polizei und Geheimdienst zusammengelegt, allerdings entsteht schon eine gewisse Kooperation.

Sehr interessant fand ich die Aussage, dass die USA Fahndungsdaten nur bekommen, wenn sie versichern, die unter Zuhilfenahme solcher Daten gefassten Täter nicht zum Tode zu verurteilen. Allerdings empfand ich diese Betonung, dass Deutschland auf seinen Werten auch gegenüber den USA beharrt, nicht wirklich als zufriedenstellende Antwort auf die Frage, ob denn durch die Anti-Terror-Maßnahmen nicht die Gesellschaft, die damit geschützt werden soll, zerstört wird. (Stichwort „Freiheit zu Tode schützen“)

Einsehen musste allerdings auch ich, dass präventive Maßnahmen, so unschön sie sein mögen, gegen den Terror wohl leider unerlässlich sind. Einem Selbstmordattentäter ist es weitgehend egal, dass auf Mord eine lebenslange Haftstrafe steht.

Die Statistik des DNA-Abgleichs mit den Datenbanken aus Österreich fand ich auch sehr interessant: Von ca. 2000 Treffern (die teilweise Spuren einer anderen Person, teilweise aber auch nur anderen Spuren zuordneten) entfielen ca. 120 auf schwere Verbrechen wie Tötungsdelikte, gemeingefährliche Straftaten, Entführungen etc. – der Rest entfiel zu einem großen Teil auf Diebstähle und ähnliche Straftaten.

Zum Thema „Bundestrojaner“ gab es ebenfalls Informationen. Auf die Frage, warum das Teil weiterentwickelt wird, obwohl es offiziell noch nicht beschlossen sei, und ob es inoffiziell vielleicht nicht doch schon beschlossen ist, gab es leider wie erwartet nur die Antwort, die man auch in den Medien zu hören bekommt: Das BKA will für den Fall, dass die Erlaubnis eintrifft, schon vorbereitet sein. (Schade aber, dass so Steuergelder verpulvert werden, wenn die Erlaubnis nicht erteilt wird, und vor allem, dass so Tatsachen und Missbrauchsmöglichkeiten – z. B. illegale Benutzung – geschaffen werden.)

Für das Onlinedurchsuchungs-Gesetz aus NRW gab Prof Stock eine negative Prognose ab, da es schlecht gemacht sei. Dennoch zeigte er sich zuversichtlich, was den bundesweiten Bundestrojaner betrifft, allerdings nur unter strengen Auflagen (Richtervorbehalt, nur bei schweren Straftaten, etc.). Er betonte nochmals die Notwendigkeit von Online-Durchsuchungen, weil bereits im Oberschleedorn-Fall viele Beamte gebunden waren, oft die Gefahr herrschte, die Täter zu verlieren und diese die Beobachtung durch die Polizei sogar bemerkt und ignoriert haben sollen.

Schön fand ich das „Geständnis“, dass gegen moderne Verschlüsselungsmethoden das BKA kaum Chancen hat, und das es aussichtslos ist, das Internet zensieren zu wollen (eine Einsicht, die sich leider noch nicht weit genug herumgesprochen hat).

Als Prof. Stock erwähnte, dass die Bezeichnung „Bundestrojaner“ eigentlich falsch sei und der korrektere und bessere Begriff „Remote Forensic Software“ lauten würde, überraschte mich das größtenteils aus nicht sehr IT- und internetnahen Menschen bestehende Publikum positiv mit lautem Gelächter.

Äußerst bedenklich fand ich allerdings einige Äußerungen aus dem Publikum, welches durchaus aus nicht gerade dummen oder ungebildeten Leuten bestand – da wurden Forderungen nach Zensur laut, der Föderalismus solle aufgegeben werden, da er die Anti-Terror-Maßnahmen behindern könne, und um Leben zu retten wäre ja jedes Mittel recht, Unschuldige hätten ja nichts zu verbergen. Sehr begrüßenswert fand ich die Reaktion von Prof. Stock auf diese Äußerungen, der diese Forderungen zurückwies und dagegen argumentierte. Er kritisierte dabei die „Dammbruchgefahr“ sowohl durch die „Nichts zu verbergen“-Schreier als auch durch Projekte wie z. B. den Gesichtserkennungs-Versuch am Bahnhof in Mainz (der übrigens zum Glück gründlich misslang).

Ebenfalls positiv empfand ich, dass erwähnt wurde, dass immer auch Unschuldige mit überwacht und/oder ausgeforscht werden, wenn sie ohne es zu wissen mit einem Terrorverdächtigen Kontakt hatten und dessen Umfeld geprüft wird. Mindestens genauso gefiel mir die Aussage, dass das BKA kein Interesse daran hätte, die Vorratsdaten für minder schwere Fälle einzusetzen (es sei hier nochmal daran erinnert, dass die meisten Menschen sich irgendwann irgendwie strafbar machen) – die Entscheidung des Gesetzgebers, den Zugriff auf die Vorratsdaten zur Aufkärung aller mittels Telekommunikation begangener Straftaten (also auch z. B. Beleidigungen per E-Mail oder Urheberrechtsverletzungen) kommentierte Prof. Stock damit, dass dies möglicherweise ein korrekturbedürftiger Fehler sei, den er sich nur durch die vergleichsweise geringe Eingriffstiefe erklären konnte (da „nur“ die Verbindungsdaten und keine Inhalte erfasst werden). Ebenso begrüßenswert fand ich, dass klar wurde, dass er durchaus die Bürgerrechte berücksichtigte und ihm einige Einschränkungen selbiger sichtlich missfielen.

Weniger schön fand ich hingegen die Äußerung, dass die Online-Durchsuchung wünschenswert sei, weil sie verdeckt ist (und nicht nur, weil man so an verschlüsselte Daten kommt). So ein klares Bekenntnis zu geheimen Durchsuchungen hätte ich nicht erwartet, da das ein grundlegendes Prinzip unseres Rechtsstaats auf den Kopf stellt. Auf den Hinweis, dass die Forderung nach verdeckten physikalischen Durchsuchungen da naheliegend sei, gab es eine quasi-Bestätigung und die Aussage, dass es politisch ja ungeschickt wäre, zu viel auf einmal zu fordern. (Geheime Durchsuchungen sind in Deutschland aufgrund der Erfahrungen mit der Stasi 1.0 nicht erlaubt.) Offenbar ist diese Meinung beim BKA nicht sehr verbreitet, denn genau diese Forderungen wurden gestern bekannt. Das Ganze hinterlässt daher einen sehr fahlen Nachgeschmack, genauso wie die Aussage, der Bundestrojaner sei vorerst nur gegen den Terrorismus gerichtet. Mal schauen, wie lange sich Schäuble an seine Aussage, die Onlinedurchsuchung nicht für die Steuerfahnung zu nutzen, noch erinnern kann.

Zum Fall rund um Andrej Holm und die „militante gruppe“ erhielt ich leider keine Stellungnahme, da es sich um ein laufendes Verfahren handelt.
Der Vortrag und vor allem die (leider natürlich aufgrund der interessanten Themen nicht ausreichend lange) Möglichkeit, Fragen zu stellen, war sehr interessant, sehr überzeugend und erlaubte es mir, mich auch mal in die Position des BKA zu versetzen. Leider habe ich zu meinem großen Missfallen aber inzwischen gelernt, dass sich Worte und Taten oft unterscheiden.