Donnerstag Abend (09.01.2025) ab 19:30 Uhr ist wieder DLUG online Treff (Jitsi).
#dlug:matrix.org
z.B.
https://matrix.to/#/#dlug:matrix.org
https://dlug.de/
https://dlug.de/kontakt.html
Mittwoch 08.01. LUGA
Harald Lesch vermittelt diverse Erkenntnisse über die Zeit und über unsere Wahrnehmung der Zeit. Ist Zeit physikalisch oder psychologisch? Kann man Zeit beeinflussen? Kann man die Wahrnehmung der Zeit beeinflussen? Was ist nur Konvention und was hat das mit dem Kalander zu tun?
Neulich wurde hier im Blog das SHIMPS Software Repository im Debian-Stil für GnuPG 2.4 und 2.5 vorgestellt. Dabei gab es noch kleinere Probleme mit dem Setup, die aber mit Hilfe der Community (DLUG und Debian) behoben werden konnten.
Zum Auftakt war das Repository manuell erstellt (Anleitung (en)) und die Release-Datei wurde mit apt-ftparchive erzeugt. Mit dieser Methode sieht man zwar, was hinter den Kulissen passiert, aber für den alltäglichen Arbeitsablauf ist das suboptimal. Es wurden keine kaskadierenden Release-Dateien erzeugt, was mutmaßlich der Grund dafür ist, dass in der Datei shimps.list das dot-slash-Konstrukt ./valilla stehen musste, um beim Update via aptitude (apt, apt-get) die Warnung W: Conflicting distribution: ... zu vermeiden.
Dieser unangenehme Schmonz, beginnend mit dem händischen Anlegen der Verzeichnisstruktur und dem händischen Kopieren der .deb-Dateien an die passende Stelle, gefolgt von dpkg-scanpackages zum Erzeugen der Packages-Dateien, lässt sich mit reprepro komplett erschlagen. Dazu gibt es im Debian Wiki eine Anleitung (en). Allerdings war diese unvollständig und fehlerhaft. Beides konnte vom Autor zwischenzeitlich korrigiert werden. Zum Einen wurden keine Contents-*.gz-Dateien generiert. Deshalb sieht man mit apt-file trotz Update keine Paketinhalte. Das Erzeugen dieser Dateien kann reprepro mit korrekter Konfiguration automatisch. Zum Anderen wurde der GnuPG encryption key [E] für die Signatur empfohlen an Stelle des signature and certification keys [SC]. Laut Zeitstempel des Schlüssels im Beispiel stand das ~15 Jahre so im Wiki (ungeprüft).
Insgesamt ist reprepro ein schönes Tool, welches die Dinge erheblich vereinfacht und automatisiert. Die Probleme mit dem Repository sind behoben und man kann sich auf inhaltliche Dinge beim Paketbau fokussieren
Für das Editieren im Debian Wiki braucht man einen Account, den man via Webseite anlegen können soll. Nach Eingabe der Daten (Username, Passwort, E-Mail-Adresse) kommt ein Hinweis, dass der Prozess als Schutz gegen Spammer gesperrt ist. Man möge bitte eine E-Mail an das Wiki-Team senden. Dort wird dann die E-Mail-Adresse für das Anlegen eines Accounts freigeschaltet. Leider erfährt man das nicht, bevor man seine Daten dort eingegeben hat. Hinsichtlich der DSGVO in Verbindung mit dem Prinzip der Auslobung nach BGB kann man den Eindruck gewinnen, dass dieser Prozess formaljuristisch nicht völlig korrekt ist. Da der Autor keine Ambitionen auf das Amt des Präsidenten des Bundesverbandes der Korinthenkacker verspürt, wollen wir das geflissentlich übersehen.
Debian liefert aktuell in unstable/sid immer noch GnuPG 2.2 aus; inzwischen ist Version 2.4 zumindest in experimental angekommen. Ubuntu hat Version 2.4 bereits in 24.04 LTS noble verfügbar.
SHIMPS stellt jetzt ein Debian apt Repository zur Verfügung, mit dem die Upstream-Versionen 2.4 (stable) und 2.5 (developer) installiert werden können. Die Kurzanleitung zum Einbinden des Repos in Debian oder Devuan ist hier. Man benötigt im Verzeichnis /etc/apt/sources.list.d/ die Datei shimps.list
cd /etc/apt/sources.list.d wget https://software.shimps.net/debian/shimps.list
und in /etc/apt/keyrings/ den öffentlichen Signaturschlüssel shimps-signing-2024.gpg.
cd /etc/apt/keyrings wget https://software.shimps.net/keys/gnupg/shimps-signing-2024.gpg
Dann das obligatorische Update zur Kontrolle, es sollten zwei neue Pakete sichtbar werden:
aptitude update
Die Pakete, die man installieren kann, sind dann shimps-gnupg und shimps-gnupg-ng.
apt-cache search shimps apt-cache show shimps-gnupg apt-cache show shimps-gnupg-ng
Ersteres bringt den kompletten entpackten tarball GnuPG 2.4.7 mit und die mit ./configure ; make gebauten binaries (126M). Alle Dateien liegen unterhalb von /opt/shimps. Das andere Paket baut auf GnuPG 2.5.2 auf und wurde mit make -f build-aux/speedo.mk this-native und make -f build-aux/speedo.mk install SYSROOT=[...] gebaut (32M). Dafür sind dort aktuellere Bibliotheken mit dabei. Alle Dateien liegen unterhalb von /opt/local/shimps. Beide Pakete sind disjunkt voneinander und auch von Debian/Devuan und können störungsfrei installiert und deinstalliert werden. Zur Benutzung der Software als Standardvariante muss man ggf. den Pfad in z.B. der .bashrc oder .profile anpassen, oder systemweit in /etc/bash.bashrc oder /etc/profile . Beispiel:
PATH=/opt/local/shimps/bin:/opt/shimps/bin:${PATH} export PATH
Die Dependencies und Recommendations sind noch work in progress, auch die Einleitung für den Pfad ./vanilla in shimps.list muss nochmal überarbeitet werden (vielleicht htaccess Regel?). Aber dafür gibt es pünktlich zum Weihnachtsfest die aktuellen GnuPG Upstream Versionen in einem Debian apt repository.
Update 2024-12-18: das dot-slash-Problem ./vanilla ist mit der Benutzung von reprepro verschwunden, damit werden u.a. kaskadierende Release files erzeugt. Das neue Repository ist mit angepasster shimps.list verfügbar.
Donnerstag Abend (12.12.2024) ab 19:30 Uhr ist wieder DLUG online Treff (Jitsi).
#dlug:matrix.org
z.B.
https://matrix.to/#/#dlug:matrix.org
https://dlug.de/
https://dlug.de/kontakt.html
Mittwoch 11.12. LUGA
Wie neulich dargestellt ist das Web of Trust in der alten Form nicht praktikabel (und auch nicht konform zur DSGVO) und die Ersatzmethode mit zentralistischen Keyservern nicht wünschenswert. Das Vertrauensprinzip bei letzterer Methode ist die direkte Überprüfung per E-Mail, also des Zugriffs des hochladenden Schlüsselinhabers auf den E-Mail-Account. Diese Idee kann verfeinert werden, um einen dezentraleren Lösungsansatz zu erreichen.
Der Ansatz, der einen Kompromiss zwischen den dezentralen (föderalen) Keyservern des Web of Trust und den zentralen moderneren Keyservern darstellt, ist das Web Key Directory (WKD). Dabei kann der Domänenteil der E-Mail-Adresse als Domäne für einen Web-Zugriff verwendet werden, der lokale Teil wird gehasht und für den abzurufenden Dateinamen verwendet. Als Domain-Inhaber mit Webspace kann man seinen Schlüssel selber ohne zusätzliche Hilfe Dritter veröffentlichen. Auch einige E-Mail-Anbieter bieten eine entsprechende Möglichkeit an.
Man könnte als Domain-Inhaber seinen Schlüssel einfach zum Download anbieten und auf seiner Webseite verlinken. Allerdings wären dann weder der Ablageort noch das Namensschema einheitlich definiert und eine Automatisierbarkeit kaum möglich. Mit WKD kann man E-Mail-Programme so erweitern, dass der Import fehlender Schlüssel aus Sicht des Benutzers sehr einfach ist. Eine Reihe von bekannten E-Mail-Programmen haben das bereits implementiert. Thunderbird hatte es, als Enigmail noch aktiv benutzt wurde, und weitere Beispiele sind KMail und Outlook. Diese Liste erhebt keinen Anspruch auf Vollständigkeit. GnuPG kann mit dieser Methode Schlüssel via Kommandozeile importieren.
Der angezeigte Hash-Wert ist frei erfunden und dient nur der Illustration.
$ gpg --with-wkd-hash --fingerprint john.doe@example.net | grep @ | grep -v john 7p53u1sqwxrgerffd6ip3jieqcqzea43@example.net $ gpg --no-armor --export john.doe@example.net > 7p53u1sqwxrgerffd6ip3jieqcqzea43
https://openpgp.example.net/.well-known/openpgpkey/hu/7p53u1sqwxrgerffd6ip3jieqcqzea43
$ gpg --locate-external-keys john.doe@example.net
Eine weiterführende und deutschsprachige Anleitung gibt es im Kuketz-Blog (s.u.) seit 2019-09-11. Einige erforderliche Details sind hier nicht aufgeführt. Das betrifft die Existenz einer ggf. leeren Datei policy und die Konfiguration des DNS. Für einen Domain-Inhaber ist das keine ernsthafte Schwierigkeit.
Als Domain-Inhaber oder Inhaber der E-Mail-Adresse muss man dem Provider für Webspace oder E-Mail vertrauen, den korrekten Schlüssel auszuliefern. Als Benutzer sind fremdsignierte Schlüssel wünschenswert, aber auch über die Kombination E-Mail/Web/DNS-Validierung begründet sich ein Erstvertrauen, das etwas stärker ist als einen Schlüssel aus einer beliebigen Quelle nach dem Prinzip Trust on first use (TOFU) (s.u.) zu verwenden. Ein Angreifer müsste die Kommunikationskanäle E-Mail und Web gleichzeitig unbemerkt kompromittieren.
WKD (en)
GnuPG: Web Key Directory (WKD) einrichten
WP: Trust on first use (en) - TOFU
Für vertrauliche verschlüsselte Kommunikation bietet sich asymmetrische Kryptographie an. Hier skaliert die Lösung des Schlüsselverteilungsproblems deutlich besser (linear) als bei symmetrischer Kryptographie (quadratisch).
Gelöst werden muss nach dem Verteilungsproblem auch das Fälschungsproblem. Das Web of Trust ersetzt eine klassische Public-Key-Infrastruktur durch ein benutzerbasiertes Vertrauensnetzwerk. Ein Benutzer kann überprüfte Schlüssel anderer Benutzer signieren und auf einen sog. Schlüsselserver hochladen. Andere Benutzer können dann wahlweise dieser Signatur vertrauen, auch wenn sie den signierten Schlüssel selber nie überprüft haben.
Alice, Bob und Charlie erzeugen jeweils einen Schlüssel. Alice und Bob signieren sich gegenseitig, ebenso Bob und Charlie. Charlie möchte mit Alice kommunizieren und kann sich darauf verlassen, dass der von Bob signierte Schlüssel von Alice tatsächlich zu der Person Alice gehört und nicht gefälscht ist.
Mit der Zeit hatte sich ein Netzwerk von Schlüsselservern gebildet, welche untereinander die Schlüssel der Benutzer austauschten und so redundant im Netzwerk - insbesondere im weltweiten Internet - verfügbar machten. Für (u.a.) Überprüfungen zwischen den Benutzern gab es Kryptoparties. Für die Interaktion der Server untereinander gab es SKS (Synchronizing Key Server), für die Interaktion mit Benutzern HKP (HTTP Keyserver Protocol), letzteres auch als HKPS via TLS, sowie HTTPS und aus ganz alten Tagen E-Mail.
Der Ansatz und die damalige Implementierung hatten einige Probleme, die sich im Laufe der Zeit immer deutlicher offenbarten.
Im Jahr 2019 gingen Meldungen über eine Community basierte, zentralisierte Server-Lösung durch die Presse:
Damit hat sich das Vertrauensproblem wieder auf eine zentrale Stelle - den Server https://keys.openpgp.org/ und dessen Betreiber - verschoben, ähnlich wie bei einer PKI. Es gibt zwar Alternativen wie https://keyserver.pgp.com/vkd/GetWelcomeScreen.event - allerdings schließt der Lösungsansatz strukturell aus, dass sich die Server abgleichen und Redundanz erzeugen. Dem müsste nämlich schon aus Datenschutzgründen jeder Benutzer jeweils zustimmen, und dann könnte er den Schlüssel gleich selbst mehrfach hochladen.
Eine gute Idee war in der Praxis nicht robust genug, umd sich gegen die Rahmenbedingungen der Realität durchzusetzen. Die Community ist wieder bei zentralistischen Lösungsansätzen gelandet, die sowohl Single Point of Failure als auch Single Point of Control sind.
Es gibt Ansätze, die wieder zu etwas mehr Dezentralisierung führen.
To be continued...
Am kommenden Mittwoch ist wieder das traditionelle Monatstreffen der Freie Software Freunde am letzten Mittwoch des Monats. Abweichend gibt es einen neuen Treffpunkt.
Vormerken: 12.12.2024 DLUG online Treff
Vereinswebseite: Freie Software Freunde
Für die Arbeit mit der Shell auf einem anderen Computer ist SSH Stand der Technik. Aus Sicherheitsgründen sollte man auf Telnet, Remote login oder Remote Shell verzichten. Da die Verwendung von Passwörtern ebenfalls zu sicherheitskritischen Problemen führt, bietet SSH die Verwendung von Schlüsseln nach dem Public-Key-Verfahren an. Diese können lokal auf dem Client mit einer Passphrase zusätzlich geschützt werden. Im täglichen Arbeitsablauf ist das permanente Eingeben dieser Passphrase jedoch störend. Daher kann der Schlüssel in den ssh-agent (en) geladen und bequem benutzt werden. Als Freie Software sind z.B. OpenSSH oder auch lsh verfügbar. Der Autor hat mit OpenSSH getestet (Client und Server).
Der Zugriff von Außen auf kritische Server erfolgt oft nicht direkt, sondern über einen Jump Host. Um den privaten - also geheimen - ssh-Schlüssel nicht zusätzlich dort ablegen zu müssen, was ein Sicherheitsrisiko darstellt, kann der ssh-agent des Jump Servers mit dem ssh-agent des Clients kommunizieren und die Login-Aufforderung des nächjsten Servers durchreichen - also forwarden. Damit verbleibt der private Schlüssel sicher auf dem Client.
Eine weitere Anwendung von Public-Key-Kyptographie ist das Ver- und Entschlüsseln von Daten wie z.B. E-Mails. Um die wiederholte Eingabe der schützenden Passphrase zu vermeiden, gibt es den gpg-agent als Bestandteil der Freien Software GnuPG (en).
Sollen Daten auf einem anderen Computer, auf den Zugriff per SSH besteht, entschlüsselt werden, könnte man seinen ptivaten - also geheimen - Schlüssel dorthin kopieren, was ein Sicherheitsrisiko darstellt. Um das zu vermeiden, kann man die Funktionalität von GnuPG mit der von OpenSSH kombinieren und den ssh-agent durch den gpg-agent ersetzen. Dazu benötigt man einen authentication key (subkey), den man einfach erzeugen und dann einen ssh public key für den/die Server ableiten - also exportieren - kann. Die lokale Konfiguration für ssh (u.a. Umgebungsvariable SSH_AUTH_SOCK) wird auf gpg umgestellt und dann kann der Login mit den Credentials via GnuPG erfolgen. Für das bequeme Arbeiten sind zwei Dinge aus der Anleitung (en) zu beachten:
Hat man sein Setup richtig konfiguriert, muss man weder private SSH-Schlüssel noch private GPG-Schlüssel einem externen fremden Computer - und damit dessen Administrator - anvertrauen. Man kann eine Login-Kette ebenso bequem benutzen wie die Entschlüsselung von Daten auf dem entfernten Computer. Das kann auch bei einem Zoo an Privatrechnern und virtuellen Maschinen hilfreich sein.
$ cat switch-ssh2gpg # change default config in a shell on the fly - quick and dirty # . switch-ssh2gpg ssh-add -l if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then export SSH_AUTH_SOCK="$(gpgconf --list-dirs agent-ssh-socket)" ; fi unset SSH_AGENT_PID export GPG_TTY=$(tty) gpg-connect-agent updatestartuptty /bye > /dev/null ssh-add -l $
Bei unixoiden Systemen ist das X Window System als GUI weit verbreitet. Der Login erfolgt über einen Displaymanager.
Besonders elegant ist KDM, der z.B. im Projekt Trinity Desktop Environment weiter verfügbar ist.
Das Protokoll XDMCP kann den lokalen Displaymanager mit einem anderen Rechner mit remote Displaymanager, auch mit einer virtuellen Maschine auf dem gleichen Gerät, verbinden. Das erlaubt ein Arbeiten, als wäre man lokal auf dem anderen Rechner eingeloggt.
Je nach Setup kommt es ab und an zu Störungen, die etwas willkürlich aussehen. Als Anwendungsfall betrachten wir einen Laptop mit VMs. Hier hat es auf einem Rechner mal geklappt und mal nicht. Nach etwas Debugging mit tcpdump ergab sich folgendes Bild:
Die Absender-IP-Adresse des Clients (Laptop) muss also vom Server (VM) aus einem reverse lookup zugänglich sein. Das geht wahlweise über die /etc/hosts oder über DNS. Für letzteres braucht es:
Bekommt man im WLAN eine IP-Adresse per DHCP, die nicht in der /etc/hosts der VM bekannt ist, können Störungen im Netz oder beim Nameserver die XDMCP-Verbindung stören.
Das Protokoll ist nicht abgesichert. Im LAN kann es empfehlenswert sein, eine Absicherung über VPN zu bauen, um keine Login Credentials zu leaken.
