Schlagwort-Archive: gnupg

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.

gnupg 8192

Janis entdeckt (endlich wieder) Verschlüsselung. Enigmail will aber nicht funktionieren – deswegen muss gnupg direkt an die Arbeit.

Erstens eine Textdatei erstellen mit dem folgenden Inhalt:

Key-Type: RSA
Key-Length: 8192
Name-Real: Vorname Nachname
Name-Email: emailadresse@domain.tld
Expire-Date: 2y
Preferences: SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES TWOFISH CAST5 BZIP2 ZLIB ZIP Uncompressed

und dann den Key erzeugen lassen mit

gpg --gen-key --batch --enable-large-rsa <dateinamevonoben>

Das dauert ne kleine Ewigkeit (je nach Rechner und vorhandenem Zufall).

Da fehlt nun das Passwort. Also zuerst die Schlüssel-ID herausfinden:

gpg --list-keys

und dann den Schlüssel editieren:

gpg --edit-key <Schluessel-ID>
gpg> passwd
gpg> save

Der Schlüssel lässt sich dann in Enigmail importieren. Das Widerrufszertifikat kann dann dort erstellt werden, oder eben auch mit gnupg:

gpg --output widerrufszertifikat.asc --gen-revoke <Schluessel-ID>

gnupg stellt dann einige simple Fragen und alles wird gut. Das Widerrufszertifikat dann am einfachsten als Anhang in keepassx speichern.

Das Einzige, was mich stört, ist, dass Janis nun längere Schlüssel hat als ich 🙂

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.

GnuPG, S/MIME, Thunderbird und Firewalls

Ich selbst bevorzuge für die Verschlüsselung von E-Mails GnuPG. Ich brauch da keine Infrastruktur Dritter und das gefällt mir. Einmal eingerichtet läuft das über Jahre. Einfach so. Ohne Kosten.

Für S/MIME spricht jedoch, dass der Standard von viel mehr MUAs unterstützt wird und dass die Handhabung oft einfacher ist. Kein zu unterschätzendes Argument, wenn man eine ganze Redaktion zu versorgen hat, die Frickeln „doof“ findet und von Windows über Apple bis Linux alles (un-)mögliche als Betriebssystem nutzt.

Ein Prüfstein war für mich diese Woche die Handhabung von GnuPG und S/MIME, wenn man mit seinem Laptop hinter der schulischen Firewall hockt, bei der nur Port 80 und Port 443 offen sind und man deswegen auf Webmail angewiesen ist. Thunderbird kommt hier schlicht nicht ins Netz.

Was dann?

S/MIME

Im Webmailfenster (wir nutzen EGroupware) auf speichern klicken.

Auf die EML Datei doppelt klicken – der lokale Thunderbird macht die Datei auf, entschlüsselt diese und fertig.

Versenden von verschlüsselten Nachrichten ist dann kein so ein großer Spaß mehr.

Man verfasst die Nachricht im Thunderbird und speichert diese im Ordner „Entwürfe“ ab. Dann klickt man diese rechts an und speichert diese über den entsprechenden Eintrag im Kontextmenü auf dem Desktop als EML.

Diese EML kann man dann als Anhang an eine Mail dran hängen, die man über den Webmailer verschickt. Beim Empfänger wird der Anhang entschlüsselt angezeigt – die Mail mit dem Anhang oben, der einst verschlüsselte Anhang unten (ähnlich wie bei einer Weiterleitung).

GnuPG

Die Nachricht – und hier nur den Nachrichteninhalt – per Copy and Paste in einen lokalen Texteditor werfen und als irgendwas.asc speichern.

Dann über das Kontextmenü (oder per Doppelklick – je nach Konfiguration) der Datei z.B. mit KGpg (je nach Desktop) öffnen und die Passphrase eingeben. Die neu erzeugte, entschlüsselte Nachricht im Editor lesen.

Das Schreiben von Nachrichten erfolgt ebenfalls im lokalen Texteditor. Man speichert die Datei lokal ab, verschlüsselt den Inhalt (Kontextmenü der Datei) und kopiert diesen aus der neu angelegten Datei mit der Endung asc wieder in den Webmailer zurück.

Und nun?

Das einfache Lesen von S/MIME-verschlüsselten Nachrichten unter den genannten Bedingungen wird in der Redaktion sicherlich gut ankommen. Ich selbst finde weiterhin den Weg für Lesen und Schreiben bei GnuPG sympathischer. Das ist zwar in beiden Fällen fummelig – aber einheitlich, unterliegt einer Logik, einer Vorgangsweise und nicht derselben zwei.

Eine berechtigte Frage ist natürlich, wie oft so was vorkommt und ob man nicht schlicht warten kann mit dem Lesen und Schreiben verschlüsselter Nachrichten, bis man wieder zu Hause / im Office ist.

Ach ja – getestet habe ich mit Textmails. Wie sich das mit HTML Mails und Anhängen anfühlt … die Tests stehen noch aus.