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 …

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.

Seit ein paar Tagen bekam ich dann von logwatch keine Mails mehr, was ich dann heute mal gedebuggt habe. Nun hat sich wohl irgendwann mal ein User mit irgendwelchem Random-Kram versucht einzuloggen (“3836jai)xoh)”). Unser Samba-Server ist so eingerichtet, dass er eine Logdatei pro User anlegt. Äh, das hat so mal Sinn gemacht … wirklich. Und deshalb gab es jetzt also eine Datei namens “log.3836jai)xoh)”. Und das fand logwatch gar nicht so lustig, denn logwatch wirft eine Liste der Logdateien die es so findet einfach so ohne sanity checks oder Quoting oder sonst was in die sh. Das resultierte dann in ein bisschen Fehlerausgabe und einem unsauberen Ende:

sh: -c: line 0: syntax error near unexpected token `)'
sh: -c: line 0: `cat /var/log/samba/log. 4023 /var/log/sa .........

Ist natürlich alles in allem ärgerlich, und irgendwie sollte man dieses komische Log-Setup auch mal wieder abschaffen. Aber dennoch, ich finde ein logwatch sollte das nicht einfach so tun. Nehmen wir mal an, ein User hätte sich aus Versehen als “; rm -rf /” oder “; poweroff” angemeldet. Dann hätte der Fileserver am nächsten Morgen um 6:25 sauber die Platte gewiped oder sich zur Ruhe gebettet. Echt unschön sowas …

Habe das jetzt mal an die Entwickler gefaxt, aber die lesen ihren Bugtracker offenabr nie. Mal schauen ob sie auf Mails reagieren … und der logwatch darf vorerst in seiner Hütte bleiben .

Update 1.3.2011: Bereits nach wenigen Stunden hatte einer der logwatch-Entwickler auf meine Mail auf der Mailingliste reagiert und einen Patch veröffnetlicht. Heute kriegte ich dann dank Google Alerts mit, dass Ubuntu was dazu in den Security Notices hat.

Und hier ist sie – meine erste offiziell entdeckte Vulnerability – CVE-2011-1018 (CVE | NVD | USN | …). Irgendwie bin ich ja dann doch so’n bisschen stolz. Darf ich jetzt eigentlich noch in die USA einreisen ?

Übrigens war mir bis gerade eben gar nicht klar wieso man da so einen Aufstand drum macht (gut, den macht man um jede Sicherheitslücke, aber es wirkt irgendwie erschlagend). Ich dachte ja das wäre nur in meiner komischen Samba-Konfig. mit den Benutzernamen im Log-Dateinamen so dramatisch, aber dann fiel mir auf, dass das sogar auf den meisten Linux-Distributionen mit Standard-Konfig. exploitbar ist. Viele Default-Konfigs setzen nämlich den NetBIOS-Namen des Clients in den Logdateinamen ein (log file = log.%m). Den kann man sich als Client im Prinzip ja auch selber ausdenken. Samba wird dann zwar unter Umständen sagen “Ne du, das Ding sieht komisch aus” oder “Häh, wer bist denn du?” – aber das wird es nicht nur dem Client mitteilen sondern das auch loggen. Und zwar wohin? Genau …

Update 4.3.2011: Die Debianer haben es dann heute mit DSA-2182-1 auch schon zu einem Advisory gebracht. Boah, sind die flott!

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!

Nun wollen die anderen ja aber nicht immer ganz so, wie der Admin will, und deshalb muss ich auf dem neuen Ubuntu 10.10 maverick-Server natürlich Joomla (ebenfalls Krampf) supporten. Und in Ubuntu 10.10 ist PHP 5.3 an Bord.

Nun kursieren im Internet die kuriosesten Lösungen. Zum Beispiel könnte man PHP 5.2 selber kompilieren oder einfach aus den alten Repositories installieren, je nach gusto parallel zur neuen 5.3er-Version oder alleine. Beides möchte man so einfach eigentlich nicht. Ersteres könnte irgendwann die Selbstmordrate in der IT-Abteilung enorm steigern, letzteres rollt jedem sicherheitsbewussten BOFH die Fußnägel auf den Rücken.

Zum Glück hatte ich dank des Schneechaos bei der Bahn genügend Zeit, über die Problematik nachzudenken. Und kam auch tatsächlich zu einer Lösung,die ich persönlich für zwar nicht unbedingt resourcenschonend, aber sehr sauber halte: eine chroot-Umgebung mit Ubuntu karmic, darin ein Apache mit mod-php5 in der korrekten Uralt-Version. Und den dann nach außen geproxied.

Klingt kompliziert, ist aber eigentlich ganz einfach.

1. Zunächst installieren wir ein minimales Ubuntu karmic in /opt/karmic-chroot. Debian bzw. Ubuntu geben uns dafür alle nötigen Tools an die Hand. Gleichzeitig installieren wir die nötigen Webserver-Pakete mit:

   apt-get install debootstrap
   mkdir /opt/karmic-chroot<
   debootstrap --include=apache2,libapache2-mod-php5,php5-mysql karmic /opt/karmic-chroot

2. Eine kleine Stoplerfalle: Nun muss der DNS-Resolver so konfiguriert werden, dass auch Prozesse innerhalb der chroot-Umgebung Hostnamen auflösen können.

   cp /etc/resolv.conf /opt/karmic-chroot/etc

3. Nun muss der eingesperrte Apache an einen anderen Port gebunden werden als der öffentliche Server, außerdem lassen wir ihn (aus Sicherheits- und Übersichtlichkeitsgründen) nur auf dem lokalen Interface lauschen. Dazu msus die Datei /opt/karmic-chroot/etc/apache2/ports.conf editiert werden und ihr Inhalt durch diese Zeilen ersetzt werden:

   NameVirtualHost 127.0.0.1:8081
   Listen 127.0.0.1:8081

4. Als nächstes wird die VirtualHost-Konfiguration aus dem öffentlichen Webserver kopiert oder neu angelegt. Evtl. reicht auch die Standardkonfiguration, das hängt vom Geschmack und der schon vorhandenen Umgebung ab. Bei mir ist bereits ein VHost für Joomla! vorhanden, der die Seiten aus /srv/www/VHOST ausliefert. AUßerdem wird hier das mod_rewrite-Modul im chroot aktiviert:

   cp /etc/apache2/sites-available/VHOST /opt/karmic-chroot/etc/apache2/sites-available/default
   ln -s /etc/apache2/mods-available/rewrite.load /opt/karmic-chroot/etc/apache2/mods-enabled

5. Die Datei /opt/karmic-chroot/etc/apache2/sites-available/default wird nun so editiert, dass sie zum neuen Webserver-Setup passt. Das hängt wieder vom eigenen Setup ab, wichtig ist, dass die VirtualHost-Definition selber wie folgt lautet:

   <VirtualHost *:8081>

6. Das Web-Root wird in das chroot kopiert. Bei mir liegt es in /srv/www/VHOST:

   mkdir -p /opt/karmic-chroot/srv/www
   mv /srv/www/VHOST /opt/karmic-chroot/srv/www
   ln -s /opt/karmic-chroot/srv/www/VHOSTe /srv/www

   Die letzte Zeile erstellt einen symbolischen Link im alten Pfad, damit die Kollegen aus der Web-Abteilung nicht ganz so verwirrt sind …

7. Nun geht es an den öffentlichen Webserver. Die Proxy-Module werden mit

   a2enmod proxy proxy_http

   aktiviert und dann die Konfiguration des alten VirtualHosts durch die Proxy-Konfiguration ersetzt. Der Host bekommt keine Pfad-Konfiguration mehr, die Kern-Direktiven sehen dann so aus:

   ProxyRequests Off
   
   <Proxy *>
    Order deny,allow
    Allow from all
   </Proxy>
   
   ProxyPass / http://127.0.0.1:8081/
   ProxyPassReverse / http://127.0.0.1:8081/
   ProxyPreserveHost On

   Diese Direktiven leiten alle Anfragen an den eingesperrten Apache weiter. Besonders wichtig ist die letzte Zeile: Joomla wird die Basis aller internen Links durch die Adresse des lokalen Webservers ersetzen, wenn diese Zeile fehlt. Das funktioniert natürlich nicht, da der interne Server ja an localhost gebunden ist. Mit der Direktive ProxyPreserveHost setzt der Apache den Host-Header korrekt ein, so dass Joomla auch korrekte Links baut.

8. Nun sollten wir so weit sein, den Webserver im chroot starten und den öffentlichen neu starten zu können:

   chroot /opt/karmic-chroot /usr/sbin/apache2ctl start
   apache2ctl restart

9. Hat man sich von der Funktionsfähigkeit überzeugt, muss noch dafür gesorgt werden, dass der interne Apache auch beim Booten des Systems gestartet wird. Der Einfachheit halber bedienen wir uns hier des crons und fügen in /etc/crontab die Zeile

   @reboot root /usr/sbin/chroot /opt/karmic-chroot /usr/sbin/apache2ctl start

   ein.

Das war’s! Selbst die oft gefundenen Lösungen für das Link-Problem, bei denen meistens kuriose Patches oder Plugins eine Rolle spielen, ist durch die ProxyPreserverHost-Direktive gelöst.

Bleibt also nur noch zu sagen: Viel Erfolg!

Nachtrag

Einige Joomla-Module machten dann gerade noch Stress wegen des MySQL-Sockets. Klar, Joomla selber benutzt den TCP-Socket, aber einzelne Module müssen ihr eigenes Ding drehen. Ich möchte jetzt hier keine Namen nennen, aber dieses SchoolJoomla hat eindeutig den Platz 1 der Krampf-Rangliste erreicht …

Um das Problem nun zu lösen, müssen wir mysqld seinen Socket im chroot anlegen lassen. Dafür ersetzen wir in der Datei /etc/mysql/my.cnf alle Vorkommen des Pfades /var/run/mysqld/mysqld.sock durch /opt/karmic-chroot/var/run/mysqld/mysqld.sock. mysqld wird das Verzeichnis beim Starten anlegen.

Allerdings macht es uns Ubuntu dank Novell’s AppArmor nicht ganz so eifnach, so dass wir das Erstellen des Sockets an dieser Stelle noch erlauben müssen. In /etc/apparmor.d/local/usr.sbin.mysqld werden folgende Zeilen eingefügt:

/opt/karmic-chroot/var/run/mysqld/mysqld.pid w,
/opt/karmic-chroot/var/run/mysqld/mysqld.sock w,

und dann das Kommentar-Zeichen vor folgender Zeile in /etc/apparmor.d/usr.sbin.mysqld entfernt:

#include <local/usr.sbin.mysqld>

Zuletzt wird der AppArmor-Dienst und MySQL neu gestartet:

/etc/init.d/apparmor restart
/etc/init.d/mysql restart

Damit auch Prozesse in der Host-Umgebung, die sich nicht für die Konfiguration in der my.cnf interessieren, den Socket verwenden können, müssen wir noch dafür sorgen, dass wir den Socket in seiner Original-Location finden können. Weil /var/run jedoch bei jedem Booten geleert wird bzw. in einem tmpfs liegt, müssen wir /etc/rc.local wie folgt erweitern:

rm -rf /var/run/mysqld
ln -s /opt/karmic-chroot/var/run/mysqld /var/run/mysqld

und die Datei ausführbar machen:

chmod u+x /etc/rc.local

Damit sollten nun alle MySQL-Clients glücklich sein …

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.

Offensichtlich handelte es sich um fehlgeleitete Abbuchungen, die vom Anbieter aber bemerkt und zurückgezahlt wurden. Zumindest Direct2Drive kann man also vermutlich nicht den Vorwurf der Mutwilligkeit machen.

Die Rückzahlungen jedoch wurden von PayPal zunächst zwecks Prüfung einbehalten und erst nach mehreren Wochen zurückgebucht. Auch blieben meien Aufforderungen zur internen Nachforschung sowohl von PayPal als auch von Direct2Drive unbeantwortet.

Dann wunderte ich mich heute, wieso denn zwei Lastschriften auf mein Girokonto ins Leere liefen. Und stellte fest, dass PayPal sehr wohl die Beträge, die an Direct2Drive gezahlt wurden, von meinem Girokonto abgebucht hat, und nach der Rückzahlung nur meinem PayPal-Konto statt gleich meinem Bankkonto gutgeschrieben hat.

Nun muss ich also mindestens drei Werktage darauf warten, den Gesamtbetrag von ca. 85 €wieder auf meinem Konto zur Verfügung zu haben.

Urteilen dürft ihr selber! Etwaige Mahngebühren meiner Provider werde ich PayPal selbstverständlich in Rechnung stellen.

Hallo Herr George,

soeben ging eine Beschwerde bei uns ein, dass von Ihrem 213.160.76.xxx Spam versendet wird.
Bitte überprüfen Sie dies und ändern ggfs. Ihre Zugangsdaten.

Oha, denke ich mir, da will ich doch mal nachsehen. Welcher Server ist denn das …

Und da bleibt mir doch die Schnitzeleinschuböffnung offen stehen – die Kiste wurde gestern Abend vom Provider eingerichtet; ich selber hatte noch nicht einmal die E-Mail mit den Zugangsdaten geöffnet.

Ein Log-Audit zeigte dann auch keine Aktivitäten auf dem System, auch ein MTA war nicht vorinstalliert (hatte ich auch nicht bestellt …). Bleiben also vier Möglichkeiten:

• Die Adresse wurde doppelt vergeben
• Da hat intern jemand Schindluder getrieben
• Da hat jemand was falsch gemacht …
• Da stimmt was nicht.

Ich habe den Provider nun mal unter Berücksichtigung dieser Punkte auf eine interne Nachforschung angesetzt …

Der Schlüsselwechsel ist natürlich nicht ganz einfach, besonders, da mein alter Schlüssel sehr viele Signaturen hat. Daher habe ich die Transition nach einem geplanten Ablauf durchgeführt.

1. Erstellung eines neuen Schlüsselpaars mit allen wichtigen UIDs
   

   $ gpg --gen-key
$ gpg --edit xxxxxxxx
adduid
adduid
...
save

2. Signieren des neuen Schlüssels mit dem alten Schlüssel, um eine authentifizierte Verbindung herzustellen
   

   $ gpg -u yyyyyyyy --sign-key xxxxxxxx

3. Erstellen einer Transition Note, d.h. einer kurzen Textdatei, die eine Information über den Schlüsselwechsel enthält. Signieren der Notiz mit dem alten und dem neuen Schlüssel, um den Text zu authentifizieren
   

   $ gpg -a -u xxxxxxxx -u yyyyyyyy --clearsign transition-note.txt

4. Update der Signaturrichtlinie und Signatur mit altem und neuem Schlüssel, so dass alte Signaturen gültig bleiben
5. Versand von Benachrichtigungen an alle Benutzer, die den alten Schlüssel signiert haben, mit der Bitte, auch den neuen zu signieren. Signatur der Mail mit neuem und altem Schlüssel. (Tipp: geht komplett durch mit einem Bash-Oneliner …)
   

   
# (Hier jetzt etwas ausführlicher, damit es lesbar wird ...)

   # Public Keyring sichern
   $ cd
   $ mv .gnupg/pubring.gpg .gnupg/pubring.bak

   # Alten Schlüssel neu laden
   $ gpg --recv-keys yyyyyyyy

   # Signaturen des alten Schlüssels auflisten
   $ gpg --list-sigs | grep ^sig | grep -o '[A-F0-9]\{8\}' | sort | uniq > sigs.txt

   # Alle Signaturschlüssel laden
   $ gpg --recv-keys `cat sigs.txt`

   # Adressliste erstellen
   $ gpg --list-sigs yyyyyyyy | grep -o '<.*>' | sed -e 's/<//g' | sed -e 's/>//g' >mails.txt

   # Nachricht signieren
   $ gpg -a -u xxxxxxxx -u yyyyyyyy --clearsign transition-mail.txt

   # Nachrichten versenden
   $ for i in `cat mails.txt`; do mail -s "New GPG key - please sign" $i <transition-mail.txt.asc; done

   # Wiederherstellen des Schlüsselringes
$ mv .gnupg/pubring.bak .gnupg/pubring.gpg


6. Widerruf des alten Schlüssels und Publizieren des alten und des neuen Schlüssels
   

   $ gpg --edit yyyyyyyy
revkey
save
$ gpg --send-keys xxxxxxxx yyyyyyyy

Anmerkung: In der Konfigurationsdatei (~/.gnupg/gpg.conf) sollten die Optionen expert und ask-cert-level eingetragen sein. In den Aufrufen steht xxxxxxxx für die ID des neuen und yyyyyyyy für die ID des alten Schlüssels. Das System muss Mails nach außen verschicken können, außerdem muss ein Keyserver konfiguriert sein.

Morgen muss ich noch die Informationen auf der Website aktualisieren und auf die Signaturen warten, dann ist der Übergang abgeschlossen.

Zusätzlich habe ich auch im neuen Schlüssel Felix als Revoker hinzugefügt. Damit hat er die Möglichkeit, meinen öffentlichen Schlüssel durch eine spezielle Signatur seines privaten Schlüssels zurückzuziehen. Sollte ich also meinen privaten Schlüssel und alle Backups verlieren oder im kritischen Fall keinen Zugang haben, kann Felix die nötigen Schritte einleiten, um Signaturen meines Schlüssels zu devalidieren. Bitte gebt dieses Recht aber nur Personen, denen ihr am besten noch mehr als 100% vertraut, sonst wird es im Zweifelsfall nämlich etwas haarig …

Zunächst als Zusammenfassung: Felix und ich hatten ein paar sehr lustige Tage in Berlin mit interessanten Vorträgen, spaßigen Aktionen und einigem mehr. Dafür vielen Dank an die Organisatoren, das EastSeven Hostel und natürlich Felix!

Tag 1

Nach unserer Anreise mit der Deutschen Bahn (Felix hatte eine geniale, zunächst merkwürdig erscheinende aber letztendlich finanziell bessere Zugverbindung aufgetrieben …) und dem Checkin im EastSeven-Hostel kamen wir gegen 14 Uhr beim bcc an. Leider begann der Kongresstag dort erst einmal mit Ärger, da offensichtlich schon alle Vollzeit-Tickets verkauft waren. Die Veranstalter konnten uns nur noch Tagestickets verkaufen, allerdings ohne die Garantie, an den folgenden Tagen auch Tickets zu bekommen und für einen deutlich höheren Gesamtpreis. Außerdem gab es entgegen der Information auf der Website doch eine Vorreservierung, nämlich für jeden, der jemanden kennt, der eine bestimmte interne Mailingliste liest. Christian C., einer der Projektleiter, zeigte sich wenig hilfreich (“Ich bin nicht engagiert, Besucher zufriedenzustellen.”), und so mussten wir uns letztendlich zufriedengeben. Etwa 20 Minuten später konnten wir jedoch wieder zufällig gefundene Vollzeittickets erwerben.

Unser erster Vortrag war Why Net Neutrality Matters von Jérémie Zimmermann. Die Verrenkungen der Provider, besonders im mobilen Bereich, mit denen der Durchschnittsverbraucher vom Konsum zu großer Datenmengen und Ähnlichem abgehalten werden soll, sind zwar bekannt, doch der Vortrag kann allemal als Aufruf angesehen werden, diesem kapitalgierigen Verhalten ein Ende zu bereiten. An dieser Stelle muss ich übrigens erwähnen, dass o2 in Deutschland als Vorreiter der Net Neutrality betrachtet werden kann: Die einzige Einschränkung, die der Mobilfunkanbieter auf seine Internet Packs anwendet, ist eine Bandbreitenbegrenzung ab 200 MB im mittleren Paket für 6,80 €. Das 25€ teure Internet Pack L kommt hingegen vollkommen ohne Einschränkung, selbst VoIP, Nutzung mit Notebook & Co. sind offiziell erlaubt.

Philippe Oechslin begeisterte danach mit seiner Präsentation Exposing Crypto bugs through reverse engineering und zeigte mehrere Systeme, die ihre Nutzdaten nur unzuverlässig oder teilweise eher “fahrlässig” verschlüsseln. Das Argument “But you did reverse engineering, which is a bad thing!” der Entwickler eines der Systeme zeigt dabei, wie sehr den proprietären Anbietern von Kryptografie-Hard- und Software die Sicherheit der Kundendaten am Herzen liegt. Philippe weist daher zurecht und begründet auf die Vorzüge freier Software auch oder gerade im sicherheitskritischen Bereich hin.

GSM: SRSLY? von Chris Pagel und Karsten Nohl zeigte ebenfalls interessante Designfehler und andere Angriffspunkte im weltweit eingesetzten Mobilfunkprotokoll GSM. Bereits seit Jahren sind die Standards für Transport und verschlüsselung der Daten als unsicher bekannt, doch die Angriffstechniken werden auch hier weiterentwickelt.

Nach einer eher unspektakulären und faden Präsentation zu Wireless Power Transfer ging es weiter zu Fabian Yamaguchis fantastischem Vortrag mit dem Titel cat /proc/sys/net/ipv4/fuckups. “Fabs” und seine Phenoelit-Crew präsentierten einen vollständigen und gut durchdachten Angriff gegen ein mittelständisches Firmennetzwerk auf allen Ebenen. Vom Angriff gegen Userland-Software bis zur Kompromittierung des Speichers von Netzwerkinterfacetreibern wurde hier alles gezeigt. Spektakulärerweise veröffentlichte Fabian während des Vortrags mehrere 0-Day-Exploits gegen die MSN-Implementation in Pidgin bzw. libpurple, die den Upload und Download beliebiger Dateien erlauben. Außerdem zog er erfolgreich und berechtigt über offenbar gängige Bugfix-Taktiken bei Intel & Co. her.

Nach diesem unterhaltsamen Programm machten wir uns auf den Weg zum Hostel, um den Schlaf der letzten Nacht nachzuholen.

Tag 2

Den zweiten Kongress-Tag begannen wir zunächst mit dem Versuch, den am Vortag bekannt gewordenen Pidgin-Bug zu implementieren. Allerdings gaben wir dies zunächst auf, ich denke aber, dass wir demnächst noch einmal darauf zurückkommen werden .

Der erste Vortrag war Milkymist, eine Präsentation über Videosynthese. Danach überzeugten Erdgeist und Fefe mit ihrer Zusammenstellung über besonders merkwürdige APIs. Oft wurden Windows-APIs unter Beschuss genommen, die stellenweise wirklich durch offensichtliche Durchdachtheit, Skalierbarkeit und Effizienz begeistern. Doch auch BSD und Linux haben echte Prachtexemplare an Bord.

Fuzzing the Phone in your Phone konnten wir leider nur per Live-Stream erleben, da der Saal unter hoffnungsloser Überfüllung litt. Was für Bugs die verschiedenen Herstelelr von Hard- und Software (z.B. HTC, Apple, Google und Microsoft) in ihren Produkten hinterlassen, ist angesichts ihrer Offensichtlichkeit schon interessant. Auch die Fallback-Lösungen, auf die Softwareentwickler kommen, um Bugfixes zu ersparen, zeugen von ungeahnter Genialität und Kreativität.

Beim SS7-Hacking ging es an den Protokoll-Stack der Telekommunikationsnetzwerke. Auch hier wurden Designfehler, Angriffsmöglichkeiten und Schutzmechanismen gezeigt. Hauptproblem ist die Auflösung des exklusiven Zugriffs auf das Netzwerk.

Und natürlich darf die Erwähnung des Hacker Jeopardy nicht fehlen: Diese Game-Show war so ziemlich das Highlight des zweiten Tages. In drei Runden traten jeweils drei Spieler gegeneinander an und versuchten, die “Fragen zu den Antworten” zu finden. Die Kreativität der Einsendungen ist dabei wohl unumstritten – auch wenn mir das Bashing gegen Perl so gar nicht gefällt .

An dieser Stelle übrigens zufällig die besten Grüße an “Hans”, “slarti” und “Peter”, ohne die das Ganze bestimmt nicht halb so lustig gewesen wäre .

Tag 3

Am dritten Tag war ich irgendwie nicht mehr aufnahmefähig, deshalb verbrachte ich einen Großteil der Zeit nach den Vorträgen über DECT und Hosting online communities als Assurer am CAcert-Stand.

Deshalb erwähne ich hier nur noch den Dunkin’ Donuts DDoS-Flashmob, der um 19:30h stattfand. Innerhalb von weniger als 2 Stunden wurden mit 300 Leuten die Fillialen der Donut-Kette rund um den Alexanderplatz leer gekauft. Bisher der spaßigste Flashmob, den ich erleben durfte!

Tag 4

Auch den letzten Tag habe ich, diesmal zusammen mit Felix, am CAcert-Stand verbracht, bis wir dann gegen 16 Uhr die Heimreise antraten.

Assorted

Und da ich ja ein Freund von Zahlen bin, hier noch ein paar davon:

• Durchgeführte Assurances: 51
• Davon bereits registriert: 40
• Davon abgelehnt: 2
• Kosten: 320 €
• Getrunkene Mate: Irgendwo zwischen zu wenig und zu viel

Ich hoffe, im nächsten Jahr wieder dabei zu sein, dann aber bitte mit verbesserter Ticket-Situation!