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.
Im Sommer gab es in Wien einen Gastvortrag von Alexander Kulbartsch (DLUG) zum Thema GnuPG für Fortgeschrittene. Die österreichischen Freunde von der LUGA hatten eingeladen, um sich umfassend informieren zu lassen. Der Videomitschnitt ist ca. zwei Stunden lang und deckt sehr viele Themen ab. Geduld und Aufmerksamkeit werden mit diesem Vortrag reichhaltig belohnt.
Donnerstag Abend (14.11.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 13.11. LUGA
# echo remove systemd
Debian installiert man aus der subjektiven Sicht des Autors idealerweise über debootstrap. Das bereitet man wie folgt vor.
mkfs.ext4 /dev/vdb1 mount /dev/vdb1 /mnt debootstrap --arch amd64 trixie /mnt https://ftp.debian.org/debian/ mount -o bind /dev /mnt/dev mount -o bind /dev/pts /mnt/dev/pts mount -o bind /proc /mnt/proc mount -o bind /sys /mnt/sys chroot /mnt
Innerhalb der chroot-Umgebung erfolgt dann die eigentliche Arbeit. Zunächst befreit man apt von der Last der empfohlenen Pakete.
# cat /etc/apt/apt.conf APT::Cache-Limit "67108864"; APT::Install-Recommends "0"; APT::Install-Suggests "0"; Aptitude::Recommends-Important "false";
Jetzt kann man aptitude installieren und danach ausschließlich benutzen.
apt-get install aptitude aptitude install sysvinit-core # REMOVED systemd-sysv{a} aptitude install systemd-standalone-sysusers # REMOVED systemd{a} aptitude install libelogind0 # REMOVED libsystemd0{a}
Jetzt fehlen noch ssh, linux und grub sowie Konfigurationen /etc/hostname, /etc/hosts, /etc/fstab und /etc/network/interfaces sowie /etc/ssh/sshd_config und /root/.ssh/authorized_keys. Damit hat man ziemlich schnell ein bootfähiges Debian trixie ohne systemd und kann sich per ssh (mit public key, root hat gar kein Passwort definiert) einloggen.
Das ist alles sehr minimalistisch und nur als proof of concept gedacht. Bei Debian bookworm kommt man noch ohne systemd-standalone-sysusers aus.
Nach Verlassen der chroot-Umgebung das Aufräumen (LIFO) nicht vergessen.
umount /mnt/sys umount /mnt/proc umount /mnt/dev/pts umount /mnt/dev umount /mnt
Harald Lesch in Alpha Centauri Folge 17 vom 9. Mai 1999, mit einem interessanten Zitat (7:49):
Es gibt ja sehr viele Leute, die einem immer wieder im Selbstdruck irgendwas schicken, die Relativitätstheorie ist falsch, es gibt gar keine schwarzen Löcher, das ist alles was ganz Anderes.
Am kommenden Mittwoch ist wieder das traditionelle Monatstreffen der Freie Software Freunde am letzten Mittwoch des Monats. Abweichend gibt es einen neuen Treffpunkt.
Vormerken: 14.11.2024 DLUG online Treff
Vereinswebseite: Freie Software Freunde