Schlagwort-Archive: horde

Horde GnuPG auf Ubuntu 18.04

Horde ist hier auf einem Ubuntu 18.04 Server installiert – mit Hilfe von PEAR.  Leider funktionierte eine ganze Zeit lang die PGP / GnuPG Schlüsselerstellung damit nicht mehr. Ich vermute inzwischen, weil der Commit hier

https://github.com/horde/Crypt/pull/2/commits/5f0c7e7b7a3dc7b6a8a3e9ba1e085be7a94d3477

nie Eingang in das Horde fand, das hier mittels PEAR aktuell gehalten wird.

Was nämlich funktioniert, ist, der Austausch von

/usr/share/php/Horde/Crypt/Pgp/Backend/Binary.php

mit der Binary.php von oben! Also

wget https://raw.githubusercontent.com/horde/Crypt/5f0c7e7b7a3dc7b6a8a3e9ba1e085be7a94d3477/lib/Horde/Crypt/Pgp/Backend/Binary.php
mv /usr/share/php/Horde/Crypt/Pgp/Backend/Binary.php /usr/share/php/Horde/Crypt/Pgp/Backend/Binary.php.bak
mv Binary.php /usr/share/php/Horde/Crypt/Pgp/Backend/Binary.php

und die Schlüsselerstellung funktioniert wieder.

Danke auch an kruedewagen und die weiterführenden Links dort, der mich auf die richtigen Gleise setzte, auch wenn dessen Lösung hier nicht funktionierte.

Wiedergänger

Direkt nach dem Umstieg von Ubuntu 12.04 auf 14.04 wollte sich die Horde-Installation meiner Schule nicht auf den neuesten Stand bringen lassen. Das übliche und sonst erfolgreiche

pear upgrade -a -B -c horde

brachte Fehlermeldungen nach dem folgenden Schema

downloading Horde_ActiveSync-2.25.0.tgz ...
Starting to download Horde_ActiveSync-2.25.0.tgz (345,324 bytes)
......................................................................done: 345,324 bytes
could not extract the package.xml file from "/build/buildd/php5-5.5.9+dfsg/pear-build-download/Horde_ActiveSync-2.25.0.tgz"
Download of "horde/horde_activesync" succeeded, but it is not a valid package archive
Error: cannot download "horde/Horde_ActiveSync"
downloading Horde_Compress-2.1.0.tgz ...
Starting to download Horde_Compress-2.1.0.tgz (2,187,446 bytes)
...done: 2,187,446 bytes
could not extract the package.xml file from "/build/buildd/php5-5.5.9+dfsg/pear-build-download/Horde_Compress-2.1.0.tgz"
Download of "horde/horde_compress" succeeded, but it is not a valid package archive
Error: cannot download "horde/Horde_Compress"
Download failed
upgrade failed

Damals half mir der folgende Bugreport bei launchpad weiter, der mich im Beitrag #9 auf die richtige Spur brachte. Der Fehler sitzt in der Datei

/usr/share/php/Archive/Tar.php

Hier muss gzopen durch gzopen64 ersetzt werden und gztell durch gztell64 und gzseek durch gzseek64.

Irgendwann im Laufe der letzten Woche muss ein Update gekommen sein, das die Tar.php ersetzte. Aktuell befinden sich die zu ändernden Zeilen samt angepasstem Inhalt in der Tar.php hier:

679:  if ($this->_compress_type == 'gz' && function_exists('gzopen64'))
680:  $this->_file = @gzopen64($this->_tarname, "wb9");
734:  if ($this->_compress_type == 'gz' && function_exists('gzopen64'))
735:  $this->_file = @gzopen64($v_filename, "rb");
759:  $this->_file = @gzopen64($this->_tarname, "r+b");
1782: $v_temp_tar = @gzopen64($this->_tarname.".tmp", "rb");
889:  @gzseek64($this->_file, gztell64($this->_file)+($p_len*512));

Dann läuft das Upgrade von Horde brav durch:

downloading Horde_ActiveSync-2.25.0.tgz ...
Starting to download Horde_ActiveSync-2.25.0.tgz (345,324 bytes)
......................................................................done: 345,324 bytes
downloading Horde_Compress-2.1.0.tgz ...
Starting to download Horde_Compress-2.1.0.tgz (2,187,446 bytes)
...done: 2,187,446 bytes
upgrade ok: channel://pear.horde.org/Horde_Compress-2.1.0
upgrade ok: channel://pear.horde.org/Horde_ActiveSync-2.25.0

Bis zum nächsten Mal.

Horde PGP und Thunderbird

Der PGP-verschlüsselnde Mailserver für die Schule läuft, die ersten Nutzer/innen haben ihre Einführungen erhalten und es sieht so aus, als würden sie den Verschlüsselungsdienst sogar nutzen. Es scheint ihnen Spaß zu machen. Gut.

Was mir dabei aufgefallen ist: Horde verschickt verschlüsselte Nachrichten mit einem multipart/encrypted Eintrag für den Content-Type im Mailheader. Thunderbird mit Enigmail tun dies aber nicht. Thunderbird schickt verschlüsselte Mails als multipart/mixed raus … und das kann Horde dann nicht als verschlüsselte E-Mail erkennen. Horde bietet dann im Webfrontend auch keine Funktionen zum Entschlüsseln an, sondern zeigt den Plaintext an.

Was im Ergebnis gut funktioniert ist damit Horde2Horde und Thunderbird2Thunderbird und Horde2Thunderbird. Was überhaupt nicht funktioniert ist Thunderbird2Horde.

Zwei Stellschrauben scheint es zu geben:

tb_enm_pgpmime

Die erste ist in Thunderbird / Enigmail zu finden. Stellt man dort PGP/MIME als Standardverfahren ein, dann schreibt Thunderbird brav Content-Type: multipart/encrypted in den Mailheader und Horde kann die Mail als verschlüsselt erkennen und somit auch die Entschlüsselungs-Funktionen im Webmailer anbieten. Thunderbird selbst kommt auf Empfängerseite damit auch zurecht.

Die zweite Stellschraube ist theoretisch in Hordes IMP zu finden. In /var/www/horde/imp/config/mime_drivers.local.php muss man hierzu PGP Inline aktivieren bzw. die Datei erst erstellen und sich den Inhalt aus der vorhandenen mime_drivers hineinkopieren. Eine Garantie, dass das dann reibungslos und immer funktioniert, scheint es aber nicht geben, haben meine Tests gezeigt. Außerdem frisst es Ressourcen, weil Horde/IMP dann die gesamte E-Mail auf PGP Blöcke durchsehen müssen.

ZwangsGnuPG

Hier überlegte ich noch, ob wir nicht an der Schule ein Horde mit Verschlüsselungsfunktion für die Kollegen einrichten sollten und wollte dies zuerst ausführlich mit ein paar Unerschrockenen testen. Soweit ist es noch nicht – aber die nächsten Schritte stehen an … und da fiel der Blick auch wieder zurück auf mögliche Alternativen und Erweiterungen.

Daniel und ich diskutierten die Möglichkeit einer Autoverschlüsselung von E-Mails, wenn diese an Kollegen gerichtet sind. Technisch ginge das z.B. mit:

  • GNU Anubis (ein message submission daemon). Der wird aber seit ein paar Jahren wohl nicht mehr weiter entwickelt;
  • DJIGZO (ein Gateway), das im Prinzip recht interessant aussieht, aber leider nur S/MIME und encrypted PDF kann;
  • gpg-mailgate (ein Postscript Filter) und dessen Forks, der das leisten würde, was wir diskutierten, aber noch ziemlich frisch ist;

Für uns schien zuerst gpg-mailgate der vielversprechendste Kandidat zu sein – aber noch kann gpg-mailgate kein Multipart. Die Anhänge würden demnach unverschlüsselt durchrutschen und genau da stecken bei uns die relevanten Informationen drin.

Dazu kommen noch weitere Kritikpunkte an der Idee an sich:

  1. jede Nachricht zu verschlüsseln ist eigentlich overkill, weil wir bei Mails von Kollege1 an Kollege2 lediglich lokal einen copy machen;
  2. Es nervt, jedes mal ein extra Passwort für den Key einzugeben, nur um eine harmlose Mail zu lesen. Das führt zur Ablehnung des Gesamtsystems und zu verdammt kurzen Passwörtern. Diesen Weg könnten wir nur beschreiten, wenn wir auch automatisch entschlüsseln (also der Kontologin den Private Key gleich mit auspackt);
  3. Es entlastet zwar – aber damit verhindert es auch, dass man sich mit dem Thema Datenschutz überhaupt auseinander setzt. Es ist demnach anti-aufklärerisch … und wenn dann alle Kollegen gar nicht mehr denken, weil ja alles automatisch passiert, dann denken sie auch nicht mehr an das Thema, wenn sie eine Mail an Eltern verfassen. Datenschutz ist eben auch und vor allem eine Kopffrage.

Im Moment will ich lieber keinen ganz so radikalen Schritt. Wir sollten auf den Kopf unserer akademisch gebildeten Kollegen setzen, das Thema damit warm halten und lieber riskieren, dass mal die eine oder andere Mail unverschlüsselt durchläuft – also auf unserem Mailserver von /home/mailuser/1 nach /home/mailuser/2 kopiert wird.

Ein fester Slot „Datenschutz“ in jeder (zweiten?) GLK, evtl. noch nett verpackt als Rätselaufgabe zu einem aktuellen Fall, halte ich im Moment für zielführender und wirksamer.

Wenn wir dann eines Tages doch noch auf die Default-Verschlüsselung umsteigen wollen, dann könnte Horde selbst schon genug können, sofern den Kollegen klar ist, warum sie dies tun sollen.

hordeeinstellunggpg

In den Einstellungen von Webmail kann bei Horde im Bereich „Erstellen“ hinterlegt werden, dass jede neue Nachricht standardmäßig unterschrieben und verschlüsselt werden soll. Das kann ein Nutzer dann zwar wieder abknipsen … aber dann haftet er auch. Oder man nagelt diese Einstellung in der Datenbank über die Konfiguration von Horde selbst fest, statt sich mit mail-gateway und Freunden gleich die nächste zu betreuende Technik an Bord zu holen.

Horde5 mit GnuPG für die Schule?

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.