Ich benutze ja sowieso HTTPS Everywhere (das solltet ihr auch tun), und gesern habe ich mir auch endlich mal wieder Certificate Patrol installiert, ein sehr nützliches Addon, das vor ausgetauschten Zertifikaten und Ähnlichem warnt.

Und dann flog mir plötzlich das hier um die Ohren:

Was ist hier passiert?

Das ist noch relativ einfach. Beim letzten Seitenaufruf hat der Server pixel.facebook.com ein Wildcard-Zertifikat, ausgestellt von DigiCert, vorgezeigt. Das ist eine laut Mozilla vertrauenswürdige CA, und offenbar ist da auch noch nichts gegenteiliges öffentlich geworden, ich habe sie nur gestern mit jemandem verwechselt.

Und dann ist da plötzlich ein anderes Zertifikat, nämlich ausgestellt von VeriSign. Da kommen ein paar Fragen auf:

• Wieso ersetzt Facebook sein Zertifikat plötzlich durch ein VeriSign-Zertifikat? Gut, können sie ja tun, aber …
• … wieso tun sie das JETZT, wo sie das doch (siehe Screenshot) schon seit fast einem halben Jahr rum liegen haben?

So weit so gut, kann ja mal sein, verplante Admins gibt’s immer, oder vielleicht hatten sie sogar einen guten Grund. Aber dann fliegt mir heute das hier entgegen:

Huch, wie jetzt? Facebook ersetzt das Zertifikat für pixel.facebook.com von VeriSign durch DigiCert? (In diesem Screenshot blöderweise das gleiche wie oben, zwischendurch hatte ich da noch ein anderes drin aber leider vergessen zu speichern).

Was ist da los? Nach kurzem Nachdenken ganz einfach:

pixel.facebook.com ist ein Alias für einen Haufen Webserver, die dann per DNS-Round-Robin ausgewürfelt werden:

nik@keks:~$ host pixel.facebook.com
pixel.facebook.com is an alias for star.facebook.com.
star.facebook.com has address 69.171.229.39

nik@keks:~$ host pixel.facebook.com
pixel.facebook.com is an alias for star.facebook.com.
star.facebook.com has address 69.63.190.29

Gut, kann man machen. Nur: ist es sinnvoll, die Server dann auf SSL-Ebene völlig asynchron zu halten? Ich kann mir vorstellen, dass man sich da eigentlich nur selber mit ins Knie schießt. Und bei einigermaßen gut informierten Benutzern löst es auch ein bisschen Verwirrung aus.

Aber pixel.facebook.com liefert ja auch nur Werbung aus, also, äh, die personalisierte Werbung, die das Bewegungsprofil der Benutzer in Form von personalisierten Anzeigen nach außen aggregiert. Ist kein digitales Vertrauen notwendig da!

Update: Ach, auf ihren Haupt-Servern können die das auch. Ich schreib jetzt mal an den Support …

Ich habe das Teil dann mal analysiert und folgendes gefunden:

• Das Programm enthält eine ganze Menge unnützen Code zur Tarnung.
• Es lädt dann von www.ukseikatsu.com eine Datei namens /images/ok.exe nach und legt sie im Benutzerprofil unter einer zufälligen Nummer ab.
• Dieser Code entpackt dann eine weitere Datei namens winsvc.exe, die den eigentlichen Kern darstellt.
• winsvc.exe verbinedt sich zu 141.105.66.235 auf Port 5500. Das ist eigentlich der VNC-Port, deshalb interessiert das die meisten Personal Firewalls nicht. In Wirklichkeit lauscht da aber ein IRC-Server.
• Der IRC-Server ist die Kontrollzentrale eines Botnets, zu dem der Client dann gehört.

Um so einen Mist in Zukunft zu verhindern: Klickt in drei Teufels Namen nicht immer jeden Scheiß an!

Linux-User sind übrigens sicher.

Update: Abuse complaint an Rusconnect, den Provider bei dem der IRC-Server läuft, ist raus.

Update 2: Dominic hat auf meinen Auftrag hin eine ausführbare Version (in Tcl) gebaut. Wir haben den Wurm Paul getauft und paul-removal.exe sollte jetzt auch unter Windows Vista und Windows 7 funktionieren. Hier ist alles gesammelt.

Meine Erfahhrung mit dem Club beginnt im Dezember 2009 mit dem 26. Chaos Communication Congress. Felix und ich waren nach Berlin gefahren und verbrachten dort dann vier Nächte in einem Hostel, was kurz vor Silvester auch nicht ganz preiswert ist. Einen Kartenvorverkauf gab es nicht, und als wir 30 Minuten nach Einlass zur Kasse kamen, gab es keine Full-Time-Tickets mehr. Man sagte uns, wir könnten ein Tagesticket kaufen, aber ob das an den folgenden Tagen auch noch gehen würde, wisse man nicht. Als uns dann zu Ohren kam, dass auf irgendeiner Mailingliste unter der Hand Tickets für Freunde der höhrangingen Mitglieder gehandelt wurden, schlugen wir uns zum Chef der Veranstaltung, Christian C. durch. Der behandelte uns wie die letzten Arschlöcher. Er vvermittelte uns, dass er sich mit niederem Volk wie uns gar nicht abgeben würde. Nachdem ich mich veranlasst sah, diesen Ablauf zu Zwittern, tauchten urplötzlich noch mehrere hundert Full-Time-Tickets unter dem Tresen auf. Da wollte wohl ofenbar jemand die schnelle Mark mit den teureren Tagestickets machen!

Weiter ging es dann mit der SIGINT 2010 in Köln. Da war ich zwar nicht direkt betroffen, aber es gab doch einige, die sich zurecht aufgeregt haben. Hier wurden im Vorfeld Tickets verkauft – doch bei der Veranstaltung wurden die dann im Prinzip nicht benötigt. Nur vor einem der vier Vortragsräume und vor der Kaffeemaschine stand jemand, der das Bändchen sehen wollte. Informiert wurde darüber vorher niemand, sonst hätte man ja an denen, die nur zu den Ausstellern wollten, keinen Wucher betreiben können.

Beim 27c3 war das NOC dann nicht wirklich in der Lage, den Switch an unserem Stand zu supporten. Der wurde da einfach hingeknallt und auf irgendeinem Random Port der Uplink konfiguriert. Als uns nach Stunden immer noch niemand verriet, wie wir damit denn nun Netz bekommen, habe ich den Switch entfernt und unser Stand-Notebook direkt angeschlossen. Das Blinken im Nagios war dann endlich Grund genug dafür, dass sich jemand vom NOC zu uns bewegte. Dessen Fix sah so aus, dass er den Switch und mein Patchkabel einkassierte. Nach 20 Minuten brachte er beides wieder, und wir hatten immer noch kein Netz. Und ach ja, als Antwort auf die Frage im Vorfeld, ob wir nun einen Stand hätten oder nicht, bekamen wir als Antwort: “Kommt her und guckt nach ob einer da ist.” Ja, genau, sind ja nur 500km.

Für Max, Simay und mich standen dann im kommenden September die MetaRheinMainChaosDays an. Auf der Website stand bis letzte Woche noch, dass die stattfinden. Nur das Rehistrierungssystem warf ständig einen 404. Dass die gesamte Veranstaltung ausfällt, erfährt man dann auf Nachfrage, wenn man sich über den Fehler wundert. Und dann auch nicht vom CCC, sondern von Anderen, die sich auch schon gewundert hatten. Die Website wurde dann auch erst gehorstet, nachdem ich mich im IRC ordentlich abreagiert hatte. Irgendwo begegnete mir dann noch ein Tweet dazu, aber das ist für mich keine ausreichenden Information für zahlende Besucher.

Zu guter Letzt schmeißt der Vorstand dann auf dem diesjährigen Camp Daniel Domscheit-Berg in einer Nacht- und Nebel-Aktion raus. Völlig daneben, aber es bestätigt das, s sich für mich schon lange abzeichnet: der CCC hält sich für eine Eliteorganisation. Wer an der Spitze mithalten kann, wird bevorteilt; das gemeine Volk wird behandelt wie der letzte Dreck. Natürlich erst, nachdem man ihm das Geld aus der Tasche gezogen hat.

Ich will jetzt nicht Äpfel mit Birnen vergleichen, aber wieso muss der CCC im fünfstelligen Bereich Geld einnehmen, wo andere ihre Besucher für 5€ rein lassen? Aber das ist nicht mal das Problem, sondern: Wenn ich dem Verein die Veranstaltung bezahle, er sich das also ohne mich nicht leisten kann, wieso werde ich dann nicht auch so behandelt? Natürlich, was Domscheit-Berg angeht, auch über die Veranstaltungen hinaus.

Der CCC ist ein wichtiger Verein für unsere Gesellschaft. Seine Veranstaltungen besuche ich noch immer gerne; ich habe mich sogar als Mitglied des CERT beworben. Doch sofern ich nicht der einzige bin, dem die oben geschilderten Eindrücke vermittelt werden, sollte der Club ernsthaft an diesen Problemen arbeiten!

Da wir generell auf allen usneren Servern Fail2Ban betreiben, einen Log-Monitoring-Daemon, der auf Auffälligkeiten wie wiederholte fehlgeschlagene Logins und Ähnliches prüft und entsprechend reagiert. Eine Reaktion ist das bannen der angreifenden Adresse mittels iptables, eine weitere Aktion ist das Versenden eines detaillierten Reports per E-Mail.

Unsere erste Idee war nun, diese Reports zu aggregieren udn an ein zentrales Postfach zuzustellen. Erst einmal nur, um da zwischendurch mal einen kleinen Überblick zu bekommen, wie sich die Angriffe so verteilen. Portscans, SSH-Brute-Force-Angriffe und Ähnliches gehören ja zum “normalen” Grundrauschen im Internet, und da kommt täglich schon so einiges zusammen.

Als wir die Reports dann aggregiert hatten, kam die Idee auf, daraus doch gleich automatisch Abuse Complaints zu generieren und an die Provider der Angreifer zu senden. Da Fail2Ban zwar standardisiert, aber nciht wirklich maschinenlesbar mailt, ist dafür einiges an ekliger Parserei notwendig. Aber es funktioniert.

Und was soll ich sagen? Ich zitiere einfach mal Felix …

aber eins muss ich dir lassen das ist extrem geil was du da gebaut hast

Jo, danke . Was daraus geworden ist, findet ihr jetzt unter dem Namen Bashinators Abuse Central.

Ach ja, übrigens … die Skripts sind eklig. Die Website ist … also, hat ihren eigenen Charm. Und das ist ein Spaßprojekt . Ach ja, und SSI rockt.

Sehr zu Felix Belustigung (und anfänglich meinem Leidwesen) bin ich dazu übergegangen, wirklich für jeden Dienst ein eigenes Passwort zu verwenden. Dabei gibt es zwei Klassen:

• Selfmade-Passwörter für Dienste, die ich oft brauche oder wo ein Passwortmanager irgendwie doof wäre (Systemanmeldung …)
• Random-Passwörter für Dienste und Websites, die ich nur so am Rande benutze

So habe ich nun also für mein (etwas advancederes) Heimnetz mein altes, sicheres Standardpasswort und für das Leibniz-Netz ein neues, selber zusammengesetztes Passwort (26 Zeichen, alpha-numerisch + Sonderzeichen …. ne, damit hab ich so gar keien Probleme …). Für Facebook & Co. gibt es Zufallspasswörter von einer Qualität, die ich dem entsprechenden Backend zutraue (es gibt noch immer so viele Entwickler die es für eine ganz hervorragende Idee halten, Passwörter zu normalisieren und dann nach 8 Zeichen abzuschneiden …).

Als wichtigste Komponente kommt dann der Passwort-Manager ins Spiel. Meine Wahl fiel dabei, anfangs vor allem deswegen, weil mir keine Alternativen bekannt waren, auf KeePass bzw. seine Variationen. Und diese Software hat sich mittlerweile bei mir mehr als bewährt: Ich benutze die Datenbank des Programms an allen möglichen Orten. Unter Ubuntu (KeePassX), Windows (KeePass, nach Belieben auch in einer portablen Version) und sogar auf meinem Android-Handy (KeePassDroid). Und das hat bisher trotz unterschiedlicher Versionen noch nicht ein einziges Mal geknallt. Daran sollten sich so ziemlich die meisten anderen Entwickler mal eine dicke Scheibe abschneiden.

Jetzt kommt natürlich völlig zurecht die Frage: Wie bekommt man diese Datenbank den nun sinnvoll auf so viele Systeme? Ganz einfach: Mit meinem Lieblings-Webdienst Dropbox.

Dropbox synchronisiert ganze Ordner zwischen mehreren Computern und wenn man das denn möchte sogar mehreren Benutzern. Udn in meiner Dropbox liegt nun also meien KeePass-Datenbank. Das klingt jetzt erstmal total witzlos, dass ich meine ach so hochsicheren Passwörter einem Drittanbieter vor die Füße werfe. Aber in dieser Dropbox liegen sogar meine SSL- und GnuPG Private-Keys. Man muss sich halt sicher sein, dass niemand, der die Daten bekommt, dann auch tatsächlich etwas damit anfangen kann. Dank sicherer Krypto-Container sollte das nicht so das große Problem sein.

Was aber klasse ist: Genau so wie KeePass gibt es den Dropbox-Client wieder für alle wichtigen Plattformen, das heißt Windows, Linux und Android. So habe ich meine Passwortdatenbank immer und überall parat.

Ob das irgendwann mal noch ganz kräftig in die Hose geht (mein lieber Felix prophezeit mir das ja schon von Anfang an, aber da setze ich mal darauf dass er eh dann irgendwo ein Backup findet …) wird sich zeigen, aber bis dahin kann ich erstmal nur sagen: Wow, genial!

Wie jedes Jahr fand auch 2010 zwischen Weihnachten und Silvester der vom CCC organisierte Chaos Communication Congress statt. Für alle, die es noch nicht wissen: Dieser “Kongress” ist eine internationale Konferenz von Hackern für Hacker mit vielen Vorträgen, Workshops und Projekten aus technischen, politischen und sozialen Bereichen. Felix und ich waren natürlich dabei, und wie immer gibt es einiges zu berichten …

Anreise

Bereits die Fahrt nach Berlin war ein echtes Abenteuer für sich. Schon lange vor Weihnachten hatte die Bahn ja angefangen, ihre Unfähigkeit pünktlich zum Reiseantritt der ganzen Weihanchts-Heim- oder Wegfahrenden zu maximieren, so dass teilweise drei bis fünf Züge (bzw. deren Inhalt) in einen einzigen ICE gequetscht wurden. Eigentlich hatte ich erwartet, dass sich dieses Problem am zweiten Weihnachtsfeiertag in Grenzen halten dürfte, weil ich keinen wirklichen Grund sah, das an diesem Tag zwei Millionen Menschen nach Berlin fahren sollten.

Felix, der die Reise nach Berlin von Kassel aus antrat, sah das ähnlich, und so wollten wir uns pünktlich um 13:30h in Hannover treffen. Ich möchte jetzt hier nicht im Einzelnen darlegen, wieso und weshalb sich dieser Termin letztendlich auf 15:25h verzögerte, aber die folgende Logik möchte man sich doch mal auf der Zunge zergehen lassen:

Hamm (Westfalen)

“Verehrte Fahrgäste, bitte gehen Sie noch weiter durch, so dass die restlichen Fahrgäste noch einsteigen können!”

Gütersloh

“Verehrte Fahrgäste, bitte rücken Sie weiter auf, da draußen stehen noch Fahrgäste. Sonst werden wir zu voll und können usnere Fahrt nicht fortsetzen.”

Bielefeld

“Verehrte Fahrgäste, leider können wir unsere Fahrt nicht fortsetzen, da wir zu voll sind. Wer freiwillig aussteigt, bekommt im Reisezentrum einen 25€-Gutschein.”

Gut, praktischerweise war de Hass auf das Verkehrsunternehmen unter den Fahrgästen dann so groß, dass ich auch noch Gutscheine von anderen Personen zum Sonderpreis von 15 €erstehen konnte, da diese sich schworen, nie wieder einen Zug zu betreten …

Nachdem wir in Hannover dann tatsächlich auch noch zwei Sitzplätze ergatterten (die Strecke von Bielefeld bis Hannover hatte ich halb sitzend, halb liegend romantisch unter einem Bahn-Mülleimer verbracht), erreichten wir dann gegen 18 Uhr völlig entspannt unser Hostel am Berliner Alexanderplatz.

Congress

Natürlich war meine Hauptbeschäftigung dieses Jahr die Organisation eines CAcert-Standes. Das ist bei einer CCC-Veranstaltung gar nicht so einfach, denn man bekommt als Aussteller überhaupt keine Unterstützung von den Veranstaltern. So wurde meine Nachfrage, ob denn nun Standfläche für CAcert verfügabr sei, am 25.12. pünktlich zwei Tage vor dem Event von einem Helfer beantwortet. Gut, in der Antwort hieß es, ich solel doch beim Aufbau helfen, dann würde ich schon sehen ob ein Stand da wäre. Äußerst hilfreich, denn im Zweifelsfall würde ich natürlich auch gerne dreistellig in die Bahnfahrt investieren, um dann festzustellen, dass ich mir das auch hätte sparen können, weil kein Stand da ist.

Ein aufmerksamer anderer Helfer fand den Stand dann jedoch, und so wusste ich am ersten Tag dann auch gleich, wo ich zu suchen hatte. Da die Kollegen sich leider um nichts gekümmert hatten, wurde in mühevoller Kleinarbeit ein Notfall-Stand zusammenimprovisiert. Ganz besonderer Dank gilt an dieser Stelle natürlich dem großartigen Jochim Selzer, ohne den die ganze Sache nicht halb so gut gelaufen wäre.

Und wo wir gerade bei Jochim sind: Der Junge brachte dann am ersten Tag auch noch einen genialen Vortrag zum Thema Datenschutz am Beispiel der evangelischen Kirche. Ich hätte gar nicht gedacht, wie komplex so eine Organisation sein kann; dass man da als “kleiner Datenschützer” nicht täglich drei Mal in die Tischkante beißt, ist ein Wunder.

Neben der Standarbeit gab es natürlich jede Menge Mate. Fasziniert übrigens war ich von der ganzen Funkerei, die PoC, NoC und andere Teams dieses Jahr aufgefahren hatten: Neben dem üblichen DECT-Telefonnetz gab es dieses Jahr auch ein GSM-Netz mit 6 Basisstationen sowie alle Streams per DVB-T. Als Mitarbeiter der Bundesnetzagentur hätte ich mich bei den ganzen Anträgen des CCC irgendwie dann auch gewundert …

Nachdem ich an den ersten beiden Tagen überhaupt nicht begeistert war (wegen des ganzen Stresses am Stand und der fehlenden Unterstützung der eigentlich eingeplanten Kollegen), wendete sich das dann gegen Ende des zweiten Tages danke Dirk und Felix, und der dritte Tag war letztendlich ein voller Erfolg. Irgendwie wurden die CCC-Leute dann auch deutlich hilfreicher, so dass sich sogar meine Einstellung gegenüber diesem Verein noch nachhaltig änderte.

Highlight des Congress war natürlich für mich wie immer das Hacker Jeopardy. Dieses Jahr möchte ich die Gameshow sogar als noch extrem witziger als im letzten Jahr bezeichnen. Die witzigsten Zitate kann ich hier leider nicht wiedergeben, da sich die Landesregierung NRW ansonsten vielleicht doch noch von der Notwendigkeit des JMStV überzeugen lassen würde, aber im offiziellen Video kann das ja jeder selber herausfinden …

Am Morgen des vierten Tages verließen Felix und ich Berlin dann jedoch, da Felix etwas kränkelte und ich keinem von uns die Bahnfahrt alleine antun wollte.

Im krassen Gegensatz zu meiner Haltung vor dem Event, dort eigentlich nur für CAcert und zur Begleitung meines Kumpels hin zu fahren, kann ich jetzt sogar sagen: Ja, nächstes Jahr werde ich wieder dort sein, vielleicht sogar als Engel!

Zunächst einmal: simfy ist eine Onlineplattform, die das Hören von Musik per Stream und die Verwaltung von Playlisten usw. ermöglicht. Nachdem Last.fm ja den größten Teil seiner nützlichen Dienste mit und mit einstellt, ist das eigentlich ein interessanter Dienst, so dass ich mich dann probehalber auch mal für ein Premium-Abonnement entschieden habe.

Am 10.11. war dann die monatliche Zahlung fällig, die auch wunschgemäß per Lastschrift eingezogen wurde. Doch halt: Wieso eigentlich zwei Mal? Das geht natürlich nicht, und spontan wie ich bin ging die zweite Lastschrift am nächstbesten SB-Automaten der Stadtsparkasse Wuppertal zurück.

Nun ist man in den meisten Buchhaltungsabteilungen ja nie um einen Scherz verlegen, und so kam gestern prompt die erste AUfforderung zur Zahlung der Rücklastschriftgebühren in Höhe von 8,95 € per E-Mail. Ich nehme also heute Morgen das Telefon in die Hand und rufe den Kundenservice des Anbeiters mal an, um nachzuhören, welceh Gedankengänge da eigentlich gerade durchgearbeitet werden und was man medizinisch dagegen tun kann.

Ich muss zugeben, die Mitarbeiterin im Kundencenter war sehr freundlich und gab den Fehler sofort zu. Die Forderung der Rücklastschriftgebühren sollte zurückgezogen werden, so dass ich keinen Nachteil aus den Fehlern von simfy.de haben würde.

Doch einen Schönheitsfehler hat die ganze Sache immer noch, weswegen ich dann noch einmal, dieses Mal etwas weniger freundlich, zum Hörer griff:

So viel dann dazu – erwarten die, dass ich das jetzt gut finde?

P.S.: Das “Pling” aus Richtung meines Handys gerade eben war bestimmt die nächste Mail …
P.P.S.:  Gegen 13 Uhr hat simfy kapituliert und mir eine Woche gratis Premium-Status gutgeschrieben. Vielen Dank!

x.509 vs. OpenPGP

Zunächst einmal möchte ich mit der offenbar weit verbreiteten Ansicht aufräumen, PGP-basierte Vertrauensmodelle und CA-basierte Vertrauensmodelle vergleichen zu können. Dabei geht es hier um zwei vollkommen unterschiedliche Ansätze, die nicht nur technisch unterschiedlich implementiert sind, sondern auch ganz anderen Ansprüchen gerecht werden. Oder eben auch nicht gerecht werden, das kommt auf den Standpunkt an. Zum besseren Verständnis hier einmal eine kurze Beschreibung der beiden Modelle:

Das PGP-Vertrauensmodell basiert grundlegend auf einem Vertrauensnetzwerk, einem so genannten Web of Trust. Innerhalb dieses Netzwerks stellen die Teilnehmer untereinander Signaturen für ihre gegenseitigen Schlüssel aus, mit denen sie bestätigen, dass die vom Teilnehmer beanspruchte Identität korrekt ist und dem Schlüssel insoweit vertraut werden kann, als dass er der erwarteten Person gehört. Der Besitz eines Schlüssels bedeutet hier die alleinige Verfügung über den geheimen Teil des Schlüsselpaares. Hat man einen Schlüssel selber signiert, kann man im Idealfall mit 100%-iger Sicherheit davon ausgehen, dass an diesen Empfänger verschlüsselte Daten nicht kompromitiert werden und dass von diesem Absender signierte Daten nicht kompromitiert wurden.

Im Normalfall möchte man nun aber mit deutlich mehr Benutzern Nachrichten austauschen als denen, die man persönlich treffen konnte. Wo es im oben genannten Fall noch ein 1:1-Vertrauen zwischen gegenseitig geprüften und signierten Schlüsseln hab, greift jetzt die Vernetzung der Teilnehmer im Web of Trust. Neben dem reinen Vertrauen in die Identität des Schlüsselbesitzers ist zusätzlich ein Vertrauen in dessen Fähigkeit, “gute” Signaturen zu vergeben, definiert. Einer Person, der ich zutraue, für mich verlässliche Aussagen über die Identität Dritter zu machen, kann ich also auf verschieden Arten mein Vertrauen in disem Punkt zusprechen. Diese Vertrauensstufe wird dann von der PGP-Software zum Aufbau einer Vertrauenskette und damit zur Ermittlung des tatsächlien Vertrauens in einen fremden Schlüssel herangezogen.

Das PGP-Vertrauensmodell beruht also auf dem persönlichen Vertrauen gegenüber Anderen.

Im Gegensatz dazu steht das bei x.509 eingesetzte Vertrauensmodell, das sich um die so genannten Zertifikatsautoritäten, kurz CAs, dreht. Die öffentlichen Schlüssel der Benutzer werden von einer zentralen Stelle, die im Idealfall eine verlässliche Aussage über die Identität des Besitzers machen kann, signiert. Alle anderen Benutzern vertrauen jetzt dieser zentralen Autorität und ihrer Fähigkeit, verlässliche Aussagen zu machen.

Zunächst einmal sieht das ganz ähnlich aus wie die Vertrauenssignaturen im PGP-Modell. Jedoch hat die Sache einen entscheidenden Haken: Durch die standardmäßige Auslieferung diverser Stammzertifikate, also der vermeintlich vertrauenswürdigen Zertifikate der CAs, mit Webbrowsern, E-Mail-Clients, etc. und die hohe Verbreitung der auf x.509 basierenden SSL/TLS-Protokollfamilie wird den Benutzern die Kontrolle über ihre Vertrauensketten mehr oder weniger genommen.

Zur Arbeitsweise der CAs

Das Problem liegt nun also darin, dass unbedarfte Anwender durch die Propaganda der Distributoren ein vorgefertigtes Vertrauensnetzwerk aufgezwungen bekommen, von dessen Existenz sie im schlimmsten Fall nicht die geringste Ahnung haben. Will sagen: Das Wissen der Benutzer beschränkt sich meistens (aber selbst das viel zu selten) darauf, dass in der Adressleiste ihres Browsers etwas grün leuchten muss, wenn sie Online-Banking machen. Doch wie diese Bestätigung einer Identität zustande kommt, und welchem komplexen Apparat aus Vorgehsnweisen, Richtlinien und Angriffsszenarien sie sich unbewusst unterwerfen, bleibt fast immer verborgen.

Im kommerziellen Umfeld wird meistens auch auf kommerzielle CAs gesetzt. Als bekanntester Vertreter sei hier Verisign genannt, in Deutschland ist besonders im Universitäts-Umfeld auch die Telekom eine beliebte CA. Diese Unternehmen verdienen, hauptsächlich oder unter Anderem, mit der Vergabe von SSL- – also x.509- – Zertifikaten Geld. Es fidnet zwar eine meist ausreichende Überprüfung der Identität des Kunden statt, doch besonders bei persönlichen Zertifikaten, die z.B. für die Signatur von E-Mails eingesetzt werden, wird meistens nur mit Kopien von Ausweisdokumenten gearbeitet. Alles andere regelt – hart ausgedrückt – ausschließlich das Geld.

Gemeinschaftsprojekte wie CAcert oder StartSSL bedienen sich stattdessen eines Kompromisses. Sie bauen intern ein dem PGP-Modell ganz ähnliches Web of Trust auf, dessen Aussagen sie als Grundlage für ihre Signaturen verwenden. Dieses Web of Trust hat nach außen hin keinerlei Relevanz, die Benutzer selber bekommen nur das althergebrachte zentralistische CA-Vertrauensmodell mit. Die CA jedoch trifft ihre Entscheidung über die Vergabe einer Signatur anhand des Vertrauens, das der Antragsteller im internen Web of Trust erlangt hat.

Dieses “Backend”, das die Zuführung der Benutzer zur Zertifikatsvergabe verwaltet, nennt man Registration Authority (RA).

Einzug in die Browser

Ein weiterer wichtiger Punkt ist natürlich die Frage, wie die Stammzertifikate in die Browser, Mailprogramme etc. der Endanwender kommen. Das heißt, anders formuliert, welche Möglichkeiten eine CA hat, der Welt volles Vertrauen in ihre Arbeit aufzuzwingen.

Hier ist die erste und am weitesten verbreitete Möglichkeit wieder das liebe Geld. Wenn eine CA genügend Mittel aufbringen kann, um die größten Softwarehersteller ihren Vorstellungen entsprechend für die Einbindung der Zertifikate zu bezahlen, ist der Drops gelutscht und ab sofort vertrauen alle Benutzer des Softwareprodukts, die es nciht besser wissen, den Aussagen dieser CA. Das ist natürlich ein bequemer Weg, seine Dienste unter’s Volk zu bringen, denn die Kunden und Endverbraucher haben genau das, was sie haben möchten: Einen dekorativen grünen Balken neben ihrer Adresszeile.

Schwerer haben es dagegen Gemeinschaftsprojekte ohne umfangreiche finanzielle Mittel. Sofern ein Hersteller überhaupt die kostenfreie Aufnahme der Stammzertifikate erlaubt, ist hierfür eine sehr eingehend Prüfung der Abläufe, Dokumente und Systeme der bewerbenden CA nötig. Den Prozess nennt man Audit, und es sollen schon Leute daran verzweifelt sein. Dieses Audit wird von einem unabhängigen Prüfer, dem Auditor durchgeführt, der sowohl von der CA als auch vom Softwarehersteller akzeptiert wird. Kommt es zu einer Empfehlung zur Aufnahme der Stammzertifikate durch den Auditor, entscheidet der Hersteller evtl., dem Wunsch nachzukommen. Und der Endanwender steht wieder vor dem selben Problem wie vorher.

Angriffspunkte

Während das PGP-Vertrauensmodell als solches nur schwer angreifbar ist, weil es keine zentrale Autorität gibt, stellt die RA im CA-Vertrauensmodell ein realistisches Angriffsziel dar, dessen Kompromitierung im schlimmsten Fall zu einer Kompromitierung aller ausgestellten Zertifikate führt. Das ist angesichts des eben angesprochenen aufgezwungenen Vertrauens besonders dramatisch, da der Endanwender ja keine Möglichkeit hat, das veränderte Vertrauensverhältnis mitzubekommen. Die Komplexität eines solchen Angriffs hängt stark von der Umsetzung der RA ab. In einer WoT-basierten RA sieht ein Angriff auf sozialer Ebene ähnlich aus wie beispielsweise im PGP-Vertrauensmodell, wobei reguläre Mitglieder des WoT hier normalerweise an viel striktere Regeln gebunden sind als die Mitglieder in einem Web of Trust ohne angeschlossene CA. Dafür sind die Auswirkungen eines erfolgreichen Angriffs ungleich größer.

Hoffnungsschimmer StartSSL?

Es liegt mir wirklich nicht, einzelne Vertreter an dieser Stelle zu vergleichen, doch als potentielle Lösung für alle geschilderten Probleme wird häufig gerne StartSSL herangezogen. Zugegebenermaßen bietet der Dienst für Endanwender einige Vorteile: Die Registration Authority ist als Web of Trust implementiert und die angeschlossene Firma verfügt über genügend finanzielle Mittel, um die Softwarehersteller auszahlen zu können. Neben einigen sehr interessanten Eskapaden in den Anfängen des Dienstes ist es nunmehr hauptsächlich eine Glaubensfrage, ob man die Entscheidung über Die Vertrauenswürdigkeit seiner Kommunikationspartner angesichts der aktuellen politischen Verhältnisse tatsächlich einem israelischen Dienstleister überlassen möchte. Mit den Qualitäten, Vorgehensweisen und sonstigen Rahmenbedingungen wird sich allerdings zunächst jeder selber beschäftigen müssen.

Aber CAcert ist nicht in den Browsern!

Richtig, und es wird ständig daran gearbeitet. Die CAcert-Community bemüht sich, alle Audit-Kriterien möglichst gut zu erfüllen. Leider sit das keien einfache Aufgabe und das Projekt ist ständig auf Helfer angewiesen.

Lösungsansatz

Die Frage ist aber viel mehr: Was bringt es uns, wenn die Stammzertifikate im Browser integriert sind? Nur einen: Dem Endanwender wurde erfolgreich das Vertrauen in unsere Arbeit aufgezwungen.

Radikal ausgedrückt heißt das: Der ganze Kram ist effektiv per Design Blödsinn.

Um dieses Problem des aufgezwungen Vertrauens zu umgehen, hilft nur die Reduzierung auf ein 1:1-Vertrauensverhältnis, bei dem die Kommunikationspartner untereinander die Fingerabdrücke ihrer öffentlichen Schlüssel verifizieren. Natürlich ist dieses Vorgehn im Alltag kaum haltbar, ma nstelle sich nur vor, dass Tausende sicherheitsbewuste Bankkunden bei ihrem Kundendienst anrufen und Geschichten von Fingerprints, Signaturen und Zertifikaten erzählen.

Wichtig ist nur, dass nicht immer nur über die Möglichkeit des blinden Vertrauens in Form eines grünen Balkens, sondern auch über die tieferen Hintergründe und möglichen Probleme nachgedacht wird.

Aus meiner Sicht ist das doch alles vollkommener Quark. Zunächst einmal ist Limewire kein “Filesharing-Dienst”, sonden ein Client für das Gnutella- und das BitTorrent-Protokoll. Und zwar einer von vielen Clients, zugegebenermaßen bestimmt einer der beliebteren seiner Art.

Für die Musikindustrie und ihre Vertreter mag ein Softwarehersteller wie Limewire zunächst einmal wie der Gegner in Person aussehen, schließlich sind es gerade diese Hersteller, die es den Benutzern ermöglichen, in einem größeren Umfang auf die in den Filesharing-Netzwerken zur Verfügung stehenden Daten zuzugreifen.

Doch betrachtet man den als so groß dargestellten Sieg einmal genauer, wird doch eine Sache deutlich: Hier wurde mal wieder nur ein zwar werbewirksamer, aber ansonsten wirklich vollkommen vermessener Schlag getan. An den in den Netzwerken angebotenen Datenbeständen ändert sich nichts, die Teilnehmer wechseln einfach zum nächsten Client.

Was wurde also erreicht? Nur eine einzige Sache, nämlich dass einem Unternehmen, das alleine keinen Einfluss auf den Schaden für die Musikindustrie hat, die Existenzgrundlage genommen wurde.

Es müsste doch langsam wirklich mal darüber nachgedacht werden, ob man eigentlich vor hat, den eigenen Hintern zu retten oder doch nur möglichst öffentlichkeitswirksam auf möglichst viele Kleine einzuschlagen …