Auf der Suche nach einer einfach zu handhabenden Lösung für den Austausch von verschlüsselten Mails innerhalb des Kollegiums fiel der Blick auf Horde. Dieses bietet nicht nur volle Groupwarefunktionalität, ist auch auf mobilen Endgeräten bedienbar und kann sich in andere Systeme (Kalender, Adressbuch etc. auf dem Smartphone oder einem lokalen Mailclient) integrieren – es kann GnuPG im Webmailer nutzbar machen. Den durchaus vorhandenen DAUs im Kollegium bliebe so die Installation von Thunderbird, Gnu4Win, Enigmail und die lokale Schlüsselerzeugung ohne Anleitung erspart. Das klang erst einmal nicht schlecht.

Was mir nicht so gefiel, war die Idee, dass dann die Private Keys der User auf einem Server rumliegen. Konkret: Horde speichert diese in der MySQL-DB ab. Schutz für den Key ist demnach nur durch den Schutz der MySQL-Installation selbst und durch das Passwort auf dem Key gegeben.

Klingt heikel. Ist auch heikel.

Andererseits muss man im Auge haben, dass im Kollegium Trojaner auf schlecht gewarteten Client-Systemen, Adressbücher bei MS, Apple, Google & Co sowie unverschlüsselte Mails mit Noten und pädagogischen Bemerkungen zu einzelnen (selbstverständlich mit vollem Namen genannten) Schülern insgesamt betrachtet die größere Gefahr für den Datenschutz darstellen, als ein zentraler Server im Intranet, der gut gewartet und gepflegt wird.

Das ist gleichzeitig aber wieder die Krux an der Sache: Die zentrale Bereitstellung eines solchen Verschlüsselung-Dienstes ist im Grunde anti-aufklärerisch. Die Kollegen werden an der Übernahme von Verantwortung gehindert, oder diese wird zumindest beschränkt auf Passwortsicherheit. Die Aufgabe, sich „seines eigenen Verstandes zu bedienen“ wird delegiert auf die Netzwerker.

An denen bleibt hierbei nicht wenig hängen: Wenn ich diesen Weg zu Ende gehe, darf ich ein dickes Päckchen administrativer Arbeit schultern: Benutzerverwaltung, Backups, Updates, Logfile-Analyse, Speicherplatzverwaltung … und vor allem Sicherheitsassessments. Gerade bei einem Mailserver darf man dies nicht unterschätzen, würde ein solcher doch weitaus mehr als schulische Moodles, WordPresse oder DokuWikis etc. zum Kernbereich der Netzinfrastruktur zählen. Ein “schon wieder tut alles gar nicht” ginge voll auf die Kappe der Netzer. Keine schöne Vorstellung, sich dies für Umme und ein paar warme Worte bei der Einführung des Systems an’s Bein zu binden.

Ausprobieren wollte ich es trotzdem – und so kam Horde auf eine meiner Maschinen. Ich orientierte mich bei der Installation weitgehend an dieser Anleitung:

http://www.linuxmuster.net/anwenderwiki:webapps:horde:installhorde5ubuntu

Einige Anmerkungen zu derselben:

1. Eine Anbindung an den LDAP des Schulservers wollte ich nicht haben. Zu schnell gibt ein Kollege für alle Schüler sichtbar sein Passwort am Beamer ein … und vergisst dann, dieses zügig zu ändern. Ich habe Horde deswegen für Benutzer eingerichtet, die im System selbst zu Hause sind, also ein lokales Benutzerkonto haben, das sie über SSH (abgesichert durch Keys) erreichen können. Passwortänderungen sind demnach ausdrücklich nicht über Horde selbst möglich. IMP erledigt damit innerhalb von Horde die Authentifizierung und kein LDAP.

Das bringt den Vorteil mit, dass ich die Passwortsicherheit besser kontrollieren kann – und den Nachteil, dass die wenigsten Kollegen ihre Passwörter selbst ändern können. Die Vorteile überwiegen bei meinem Kollegium hier ganz klar die Nachteile. Vor allem: Wer ändert schon seine Passwörter 🙁 Bei dieser Lösung mach ich das dann – und zwar zwangsweise für die Kollegen gleich mit. Der Rhythmus ist mir noch nicht klar, aber einmal im Jahr wäre cool.

2. Die Anbindung von Gollem, dem Filemanager von Horde, an Samba unterblieb bei meiner Installation auf einen dezidierten Server. Das ist einerseits klar, ist doch der Schulserver-Samba nicht über’s Netz zu erreichen – andererseits aber auch wieder problematisch, weil nun für die Kollegen drei Wege für die Dateiablage offen stehen: a) den Dateimanager im Mailserver-Horde benutzen b) den Dateimanager im Schulserver-Horde für den Zugriff auf’s Home benutzen c) die ownCloud Installation der Schule benutzen.

Vielfalt und Freiheit führt in meinem Kollegium immer zu Problemen. Andererseits: Da kaum jemand überhaupt jemals die genannten Dienste verwendet hat, kann ich mit dem Nachteil leben. Und: Wenn ich hiermit Probleme im Alltag der nicht völlig hoffnungslosen Fälle erlebe, dann klemm ich Gollem im Mailserver-Horde schlicht ab.

3. Die oben verlinkte Installationsanleitung trägt schon arg dick auf und sollte sich auf ungefähr die folgenden Schritte – nach dem Anlegen einer Datenbank – verschlanken lassen. Ich muss das in einer zweiten Installation noch einmal verifizieren – aber für den Moment kann man sich ja, sollte etwas Entscheidendes fehlen, wieder an der Anleitung bei linuxmuster.net orientieren:

apt-get install php5-tidy php5-memcache memcached php5-auth-pam php5-intl php5-sasl

pear channel-discover pear.horde.org

pear install horde/horde_role

pear run-scripts horde/Horde_Role

mkdir /var/www/horde

pear install -a -B horde/webmail

webmail-install

chown root:www-data /var/www/horde/static

chmod 775 /var/www/horde/static

Die Apachekonfiguration ist noch anzupassen und der Apache im Anschluss neu zu starten:

Alias /horde /var/www/horde

<Directory /var/www/horde>

Options Indexes FollowSymLinks MultiViews

AllowOverride All

AcceptPathInfo On

Order allow,deny

allow from all

</Directory>

Nag fiel bei mir gleich auf die Nase und warf beim Anlegen von neuen Tasks Fehlermeldungen zu einer nicht gefundenen rampage.php aus. Die Rewrite Anweisungen in der .htaccess im Horde Stammverzeichnis wollten nicht recht wirken – also legte ich mir den folgenden Eintrag direkt in die Apache Konfiguration

<Location /horde>RewriteEngine on

RewriteBase /horde

RewriteCond %{REQUEST_FILENAME} !-d

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^(.*)$ rampage.php [QSA,L]

</Location>

Da löste sich der Knoten gründlich.

Das Ticketsystem Whups habe ich gleich wieder runter geworfen – es lief eh nicht rund und zog zu viele Betapakete aus PECL Repositories mit sich.

4. Der Mailserver ist eine VM. Das ist ja erst einmal ein Vorteil, weil sich so Backups leichter durchführen lassen und Updates mir nicht alles zerreißen können – aber virtuelle Maschinen bringen keine Entropy auf die Pfanne, um zügig 2048er-GnuPG-Keys zu erzeugen. Das dauerte halbe Ewigkeiten – aber man kann sich von haveged [1] helfen lassen.

5. Es ist nicht nur die Erzeugung der Keys, die mit den Kollegium durchexerziert werden muss, und deren Nutzung im Alltag. Kaum einer hat sich je mit Verschlüsselung beschäftigt, so dass schon grundlegende Konzepte nicht verstanden werden. Alice and Bob werden in der Schule geläufige Namen werden müssen.

Dazu kommt die Einrichtung von Horde selbst, auf dass später alles rund läuft (z.B. Pubkey als Anhang verschicken, keine HTML Mails etc. pp.).

Der Schulungsaufwand für die zentrale Mailserver-Lösung ist alles in allem nicht zu unterschätzen. Ich behaupte mal: Selbst für eine Gruppe eher erfahrener Kollegen, die nicht alle 5 Minuten aus Versehen den Browser zumachen und dann „ich war’s nicht“ heulen, dauert die Ersteinrichtung mindestens einen Nachmittag (3-4 Schulstunden).

Jetzt beginne ich die Arbeit mit zwei geeigneten Kandidaten, werte dann die Erfahrungen aus und erweitere die Gruppe langsam und Schritt für Schritt. Ich selbst kann dann meine Einführungen optimieren und gewinne – wenn dann ein Verfahren fest steht – Multiplikatoren im Lehrerzimmer. Bei den ersten Schritten finde ich so auch heraus, ob Horde überhaupt der richtige Weg für meine Kollegen ist. Wenn ich nämlich für die Einführung in Horde mit allem drum und dran ähnlich viel Zeit verbrate wie für eine Einführung in Thunderbird + Enigmail, dann kann ich mir den administrativen Overkill sparen und habe am Ende eindeutig sicherere Systeme, die jederzeit noch in Richtung S/MIME erweitert werden können.