Qbi's Weblog

Mastodon ist ein soziales Netzwerk zum Selberbasteln. So oder ähnlich lautet eine der Versprechungen des Dienstes. Wer mag, kann einen eigenen Server betreiben und sich somit dem Fediverse vernetzen. Daher betreibe ich Anfang 2023 auch einen Server. Der ist unter den Adressen

• https://freie-re.de
• http://az7swyjuxw4pf4bbsmsgbfpwtyfs5y5pa6a4d5vklnw7ziv54cn7u2ad.onion/

erreichbar.

Seit kurzem gibt es nun die Version 4.2.0, die recht viele Verbesserungen bietet. Also wollte ich die Software aktualisieren. Bei Mastodon erfolgen Aktualisierungen in der Regel über git. Das heißt, mittels git fetch wird das Repository aktualisiert und dann wird die “richtige” Version ausgecheckt. Eventuell sind noch Pakete zu aktualisieren und das wars im Wesentlichen.

Als ich das bei meinem Server versuchte, stellte ich fest, dass einige Programme veraltet waren. Das Image, was ich zur Installation verwendete, basiert auf Debian bullseye. Mittlerweile ist Debian bookworm aktuell. Vor dem Update von Mastodon stand also ein Update von Debian. In der Regel ist ein Update von der Vor- zur nächsten Debian-Version recht unproblematisch. So auch hier. Das Update war schnell gemacht.

Also gab ich ein git fetch && git checkout v4.2.0 ein und startete so die Aktualisierung von Mastodon. Danach mussten die Befehle

• bundle install
• yarn install --frozen-lockfile

durchgeführt werden. Bei letzten Kommando sagte mir mein System, dass dieser Befehl nicht verfügbar sei. Allerdings lag im Unterverzeichnis bin/ eine ausführbare Datei namens yarn. Als ich diese direkt ausführte, war die Ausgabe wieder, dass Yarn nicht verfügbar sei. Yarn wurde mittels corepack installiert. Aber corepack war auch nicht verfügbar. Damit musste ich noch einen Schritt zurückgehen: zur Installation von node.js selbst.

Hier lag dann die Lösung: Beim Update von Debian wurde auch node.js aktualisiert. In dem Update war vermutlich corepack und anderes nicht mit eingeschlossen. Ich deinstallierte also node.js, aktualisierte die sources.list-Datei und installierte node.js wieder. Damit waren corepack und yarn auch wieder verfügbar und der obige Befehl lief problemlos durch.

Die letzte Hürde bestand im Neustart der Mastodon-Dienste. Ich hatte diese mittels systemctl restart mastodon-* neu gestartet. Dies führte zu Connection refused-Meldungen. Der Streaming-Dienst unter Port 4000 war nicht erreichbar. Dies lag daran, dass der Systemd-Service mastodon-streaming erneuert wurde. Also fehlte noch ein systemctl daemon-reload gefolgt vom Neustart.

Das war dann der Punkt, an dem der Server mit Version 4.2.0 anstandslos weiterlief.

Ich habe im Blog schon einige Male über Logseq geschrieben. Ich habe die Software über Flatpak installiert, ähnlich wie schon OnionShare. Hin und wieder muss die Software aktualisiert werden. Dies passiert über den Befehl 

flatpak update com.logseq.Logseq

Alternativ kann man auch den Namen einer anderen Software oder auch nichts angeben. Im letzteren Fall aktualisiert FlatPak alle installierte Software.

Als ich das nun heute versuchte, begrüßte mich FlatPak mit einer Fehlermeldung:

Warnung: Failed to create a mountpoint for revokefs-fuse: Can't create temporary directory
Warning: Can't create temporary directory

Tja, was tun? Der erste Versuch war, FlatPak mit einer Verbose-Option zu mehr Ausgabe zu überreden. Dies sagte mir nur, Calling system helper. Das ist für die Fehlersuche wenig hilfreich.

Also habe im nächsten Versuch mal eine Suchanfrage gestartet. Hier gab es ein paar Hinweise auf fusermount, ein paar Beiträge empfehlen, die Rechte von Verzeichnissen zu ändern oder es wird den Fragenden gleich empfohlen, eine andere Art der Installation zu wählen. Insgesamt war die Ausbeute wenig hilfreich.

Viel hilfreicher war ein Blick auf das Dateisystem. Neben dem FlatPak-Updates gab es auch Updates meines Betriebssystems. Und die große Menge an Dateien hatte die Partition, die /var beinhaltet, gefüllt. Also flugs aufgeräumt:

apt autoremove

Damit war das var-Verzeichnis wieder frei und das Update von FlatPak lief problemlos durch. Falls ihr also auch die Meldung erhaltet, könnte es sich lohnen, einen Blick auf das Dateisystem zu werfen.

Ich überlege noch, ob es nicht sinnvoll wäre, wenn FlatPak dies auch als Fehler meldet und werde diesbezüglich eventuell einen Bugreport einreichen.

Als das Tor-Projekt den Tor-Browser entwarf, machten sie sich viele Gedanken zum Schutz der Privatsphäre. Sie versuchten jegliche Gefahren zu identifizieren und diese zu umschiffen. Daraus entstand das Design zum Tor-Browser. Seitdem versuchen die Entwickler, die Schwachstellen in Bezug auf die Privatsphäre im Mozilla Firefox im Griff zu behalten. Neben dem Tor-Button kommen viele individuelle Patches zum Einsatz. Die meisten davon wurden bisher von Mozilla nicht in den Firefox eingepflegt. Doch dies ändert sich jetzt.

Seit Anfang Mai gibt es im Wiki von Mozilla eine Seite, die sich Tor Uplift nennt. Mozilla fängt nämlich nun doch an, Patches vom Tor-Projekt in den Firefox wieder einzubauen. Auf der Wikiseite wird der Fortschritt festgehalten. Bisher kamen 26 Änderungen weiter und an sechs wird gerade aktiv gearbeitet. Sören Hentzschel beschreibt in seinem Blogbeitrag, welche neuen Optionen es im Firefox gibt und wie diese aktiviert werden können.

Insgesamt ist das ein guter Schritt der Entwickler, den Schutz der Privatsphäre im Firefox weiter zu erhöhen. Wie Sören in seinem Beitrag schreibt, engagiert sich Mozilla auch weiterhin stark im Tor-Projekt. Weiter so!

Der macht eine Meldung über die LogJam-Schwachstelle die Runde. Ein Besuch der Webseite WeakDH.org offenbarte auch bei meinen Browser-Einstellungen Schwächen. Doch wie sichere ich den gegen die Attacke?

Im Firefox ist das recht einfach: In die Adresszeile einfach about:config eingeben und dann in den Konfigurationseinstellungen nach dem Wert .dhe suchen. Der Punkt vor dhe ist wichtig, dass nur die relevanten Algorithmen gefunden werden. Alle Werte (je nach Version sind das zwei oder mehr) werden auf false gesetzt. WeakDH.org sollte nun keine Warnung mehr anzeigen.

Einstellungen im Tor Browser Bundle

Im Chrome oder Chromium gibt es keine Möglichkeit, die Einstellung über ein Menü zu machen. Der beste Weg, den ich fand, ist, zunächst die Cipher-Suite-Detail-Seite zu besuchen. Dort findet ihr eine Tabelle mit Algorithmen, die euer Browser unterstützt. In der Spalte Spec stehen Zahlen-/Buchstaben-Kombinationen. So findet sich bei mir beispielsweise der Eintrag: (00,0a). Sucht nun nach allen Einträgen, bei denen der Cipher-Suite-Name mit DHE (nicht ECHDE) beginnt und entfernt die Klammern und das Komma von der Spec. Nun fügt ihr noch ein 0x an den Anfang. Im obigen Beispiel wird also aus (00,0a) ein 0x000a. Diese unerwünschten Algorithmen werden als Option dem Chrome oder Chromium übergeben: google-chrome --cipher-suite-blacklist=0x009e,0x0033,0x0032,0x0039,0x0004,0x0005 ist das bei meinem Browser.

Wie sieht es bei anderen Browsern aus? Meines Wissens kann man den Internet Explorer nicht so detailliert steuern. Ich freue mich über Hinweise und nehme die gern mit in den Beitrag auf. Schließlich sollte das Ergebnis der Webseite dann wie unten aussehen.

Keine Angriffsmöglichkeit durch LogJam

Kürzlich führte ich einen Workshop zum technischen Datenschutz und Verschlüsselung durch. Während Workshops zeigte ich den Teilnehmern verschiedene Werkzeuge, unter anderem auch den Tor Browser. Dabei meinte ein Teilnehmer, dass er ZenMate einsetzt und dies genauso sicher wie der Tor Browser ist.

Was ist ZenMate? Auf der Webseite verspricht die Anwendung Verschlüsselung sowie anonymes Browsen. Der Internetverkehr wird durch virtuelle private Netze (VPNs) geleitet. Das Plugin lässt sich einfach installieren und fragt anschliessend nach einer E-Mail-Adresse. Nachdem eine E-Mail-Adresse eingegeben wurde, wird das Plugin nach einer kleinen Wartezeit aktiv. In der Browserleiste im Firefox erscheint ein grünes Schild und nach einem Klick lässt sich rechts unten der Ort wechseln (Change Location). Auf Empfehlung des Teilnehmers wählten wir im Kurs Hong-Kong aus und fühlten uns geschützt. Doch wie sieht die Realität aus?

Ich nutze für Tests auf Anonymisierung meist die Seite IP-Check. Nach dem Start des Tests und einer kurzen Wartezeit ergab sich folgendes Bild:

Das Plugin leitet zwar die Verbindungen über das VPN weiter und nutzt einen Server in Hong-Kong (oder auch anderen Städten). Weitere Browsereinstellungen bleiben jedoch unangetastet. Im Beispiel oben war es das Flash-Plugin, was in vielen Browsern standardmäßig aktiv ist, das sogar die reale, gerade verwendete IP-Adresse preisgegeben hat. Mit der manuellen Deaktivierung von Flash wird die eigene IP-Adresse nicht mehr unmittelbar erkannt. Allerdings bleiben noch genügend andere Möglichkeiten übrig das Onlineverhalten der Benutzer zu verfolgen.

Letztlich stecken die Entwickler des Tor Browsers sehr viel Zeit und Energie, Lücken im Firefox zu schließen. Daher wäre es schon sehr verwunderlich, wenn sich gleiches Ziel, nämlich anonymes Browsen, mit einem einfachen Plugin erreichen ließe.

Wer also ZenMate einsetzen will, sollte sich der Risiken im Klaren sein und ggf. selbst weitere Anpassungen im Browser vornehmen. Eventuell funktioniert die Kombination des JondoFox-Profils mit ZenMate besser. Diesen Versuch überlasse ich euch. Ihr könnt gern einen Kommentar hinterlassen.

Die Podiumsdiskussion mit Hans-Christian Ströbele und Prof. Dr. Michael Dreyer wurde von Campus TV aufgezeichnet. Mittlerweile ist das Video bei YouTube verfügbar. Die Audioqualität ist verbesserungswürdig. Dennoch viel Spass beim Anhören und -sehen!

Jetzt ist der Zeitpunkt gekommen, an dem ich meine Anleitung zu sicheren SSL-Einstellungen löschen kann. Der aktuelle Firefox ist in der Version 27 erschienen. Wie angekündigt, unterstützt der Browser nun standardmäßig TLS 1.1 und 1.2. Damit werden die TLS-Einstellungen über about:config hinfällig. Die Seite How’s my SSL zeigt den Firefox mit Standardeinstellungen als Probably OK an. Sogar Seiten mit AES im GCM-Modus werden korrekt verschlüsselt.