Autor: mauri

Containerize all the things! Seit vielen Jahren ist die Container-Technologie aus der IT-Welt nicht mehr wegzudenken. Mittlerweile gibt es viele Lösungen und Varianten, einige sogar schon wieder veraltet. Über die Container-Engine hinaus gibt es auch Komplettlösungen, die eine Verwaltung bzw. Orchestrierung bieten – wie zum Beispiel Kubernetes.

Weiterlesen

HTTPS dürfte im Zusammenhang mit Internetdiensten heutzutage jedem ein Begriff und zudem Standard sein. Hierbei wird die HTTP Kommunikation verschlüsselt, was in den meisten Anwendungsfällen herkömmliche Webseiten wie diese betrifft. Und bei dieser Kommunikation stoßen wir auf ein sehr altes grundsätzliches Problem, denn das Internet ist eigentlich kaputt…

Die Adressermittlung (bzw. Umwandlung) im Internet findet nach wie vor über das Dynamic Name System, kurz DNS, statt. Ich werde ich jetzt nicht im Detail auf die Arbeitsweise von DNS eingehen, aber kurz gesagt, nach wie vor kommunizieren Computer im Internet über IP Adressen, welche zu einer (oder mehreren) Adressen gehören (das Telefonbuchprinzip). Daher muss ein Computer bevor er eine Webseite o.Ä. aufruft, zunächst seinen bekannten DNS Resolver befragen, welcher weiß, welche IP zu der aufgerufenen Adresse gehört. Einige Webseiten laden externen Inhalt, sei es duch Werbung, oder die Verlinkung zu anderen Artikeln o.Ä. Daher kann das Aufrufen einer einzigen Webseite u.U. mehrere DNS Anfragen zur Folge haben. Alleine nur das Aufrufen der Seite www.heise.de beinhaltet über 50 Anfragen zu weiterführenden Webseiten. Wieviele Anfragen nochmals jede dieser 50 Seiten produziert, lässt sich nicht einmal erahnen.

Und hier kommt die Krux an der Sache: Diese (DNS) Anfragen sind standardmäßig nicht verschlüsselt. Damals (in den 1980ern) hat man sich über Verschlüsselung wenig bis keine Gedanken gemacht. Und es hat zu dieser Zeit bestimmt niemand damit gerechnet, wie man DNS Anfragen missbrauchen kann bzw. was sich mit diesen Informationen sonst noch anstellen lässt.

Problem 1:

Da die Anfragen unverschlüsselt sind, lassen sich diese natürlich an jeder beliebigen Stelle mitlesen, was eine sogenannte „Man in the Middle“ Attacke (MITM) zulässt. Hierbei kann der Angreifer DNS Anfragen umlenken indem er statt auf www.abc.de das Opfer auf www.xyz.de umleitet, dieses davon aber nicht mitbekommt, bzw. erst wenn es zu spät ist (der Schadcode ist auf dem PC, oder die wertvollen Daten wurden abgegriffen, da das Opfer diese auf der gefälschten Seite gutgläubig eingegeben hat).

Problem 2:

Von dem oben genannten „Phishing“ hat fast jeder schon einmal gehört. Aber abseits von sicherheitsrelevanten Problemen im DNS, gibt es ein weiteres nicht unerhebliches Problem im Bereich der digitalen Privatsphäre. Dadurch das die DNS Anfragen unverschlüsselt sind, ist angefangen beim ISP (Telekom, Vodafone etc.) einsehbar, welche Webseiten wann besucht wurden. Hier befinden wir uns im Bereich des User-Tracking, sprich dem Sammeln von Benutzerdaten, welche anhand der IP- und ggf. der MAC Adresse des Quellgerätes personifiziert werden können und somit ein wahrer Goldschatz für die Werbeindustriee sind. Dr. Dominik Hermann hat hierzu eine ausführliche Dissertation veröffentlicht.

DoH oder DoT (DNS over TLS) ermöglicht es diesen Datenstrom zu verschlüsseln. Allerdings passiert dies nur bis zum ISP, danach findet die DNS Kommunikation wieder unverschlüsselt statt. Angeblich soll es hierzu aber Pläne geben, diese weiterführende Kommunikation ebenfalls komplett auf Verschlüsselung umzustellen.

Das „Einer kennt alles“ Problem

Im Regelfall benutzen Systeme einen einzigen DNS Resolver. Man kann zwar mehr als einen konfigurieren, aber üblicherweise wird der erste solange genutzt, bis dieser nicht mehr erreichbar ist. Das bedeutet, ein Resolver kennt alle DNS Anfragen. Jetzt kann man natürlich gut und gerne die Frage stellen, was machen ISPs wie die Telekom, Vodafone, 1&1 usw. mit unseren ganzen DNS Anfragen? Jedenfalls werden diese zunächst einmal geloggt und gespeichert. Was damit weiterhin passiert, kann niemand mit absoluter Sicherheit sagen und vielleicht werden diese sogar an Dritte weitergegeben/verkauft. Und selbst wenn damit nichts passieren sollte, ist theoretisch der Datenstrom der Benutzer mitsamt IP und DNS Anfragen nach dem ISP wieder erfassbar. Und diese „Ausgänge“ sind natürlich nur bedingt dynamisch und relativ leicht aufzufinden.

Es spricht also einiges dafür unabhängig von der Verschlüsselung seinen DNS Resolver genauer auszuwählen, oder vielleicht sogar einen eigenen DNS Resolver zu betreiben. Einige Resolver werben auch extra dafür, dass z.B. keinerlei Logging erfolgt. Ein Abschöpfen des ausgehenden Datenstroms ist bei kleineren unbekannten Resolvern natürlich ebenfalls unwahrscheinlich. Somit wird das Risiko minimiert, auch wenn es nicht gänzlich verschwindet. Zumindest ist eine Rückverfolgung des ursprünglichen Systems, welches die Anfrage gestartet hat, deutlich schwieriger.

DoH, DoT, DNSCrypt, DwasBitte?

Bei DoH (DNS over HTTPS) wird tatsächlich normal über den Port 443 (das reguläre HTTPS Protokoll) kommuniziert, was es ermöglicht, dass eine DNS Anfrage nicht von einer normalen Webseiten-Anfrage zu unterscheiden ist. Dieses Verfahren macht es allerdings auch zu dem langsameren, wobei die Unterschiede bei herkömmlichen Verbindungsgeschwindigkeiten marginal ausfallen dürften. DoH ist als RFC 8484 standardisiert.

DNS over TLS (DoH) nimmt die bisherige Basis der DNS Kommunkation per UDP/53 und entwickelt diese weiter indem eine Verschlüsselung per TLS hinzugefügt und ein eigenständiger Port (normalerweise 853) verwendet wird. Dadurch ist DoT schneller als DoH. DoT ist zwar nicht standardisiert, aber als RFC 7858 vorgeschlagen.

DNSCrypt ist gegenüber den beiden anderen das ältere Verfahren und basiert weder auf HTTPS noch TLS, sondern setzt auf einen eigenen Algorithmus. Allerdings läuft DNSCrypt ebenfalls über den Port 443 (standardmäßig allerdings UDP, Fallback TCP) was somit bis zu einem gewissen Grad auch den Vorteil der „Paketverschleierung“ beinhaltet. DNSCrypt  wurde jedoch nie als Standard vorgeschlagen.  
Weitere Protokolle zur Verschlüsselung von DNS ist bspw. QUIC, auf welches ich hier aber nicht weiter eingehe.

DoH und DoT sind somit derzeit die gängisten Lösungen. Aber wie nutzt man nun verschlüsseltes DNS?

Die betriebssystemseitige Lösung

Ich habe bereits im Sailfish Artikel oder auch auf Mastodon mehrfach auf die Software dnscrypt-proxy hingewiesen. Anders als der Name vermuten lässt, unterstützt dies natürlich auch DoH/DoT.
Der Vorteil dieser Software ist, dass die Verschlüsselung auf OS Ebene erfolgt, unabhängig von den nachfolgenden Geräten/Zugängen. Somit hat man DoH/DoT/DNSCrypt bspw. auf seinem Notebook, egal wo man sich befindet. Zusätzlich bietet die Software die Nutzung von Domain- und IP Blacklists und dadurch natürlich auch Whitelists. Der zu verwendende Resolver ist frei wählbar, wobei auch mehrere Resolver mit unterschiedlichen Protokollen genutzt werden können.

dnscrypt-proxy arbeitet mit sogenannten DNS Stamps. Diese Stamps beinhalten alle relevanten Informationen um sich mit den gesicherten DNS Resolver verbinden zu können. Eine Liste mit Resolvern und den dazugehörigen Stamps findet sich hier. Zusätzlich kann man Stamps auch selbst generieren.

Pihole

Der PiHole dürfte eines der bekanntesten und weit verbreitetesten Raspberry Pi Projekte überhaupt sein. Mit seiner Hilfe lässt sich die gesamte DNS Kommunikation in einem Netzwerk filtern – überwiegend natürlich dazu gedacht, Werbung und Tracking zu unterbinden. Der PiHole arbeitet dabei auch nur mit einfachen Blocklisten, welche beinhalten, was für DNS Namen gefiltert werden sollen. Um den PiHole im Netzwerk nutzen zu können, muss dieser natürlich auch als erster DNS Resolver im Netzwerk konfiguriert werden (z.B. am Router). Leider bietet PiHole aber bisher von Haus aus nicht die Möglichkeit, die DNS Kommunikation zu verschlüsseln bzw. DoH o.Ä. zu nutzen, weshalb hier Hand angelegt werden muss.

Auf der eigenen PiHole Webseite wird beschrieben, wie man einen DoH Client von Cloudflare (cloudflared) installieren kann.
Zwar kann man theoretisch auch einen anderen Resolver verwenden als Cloudflare, für mich persönlich hatte aber die Firma im Hintergrund bei der Lösung einen bitteren Beigeschmack (siehe Punkt „Firefox“).

Die o.g. Software dnscrypt-proxy ist allerdings so vielseitig einsetzbar, dass auch diese auf einem PiHole funktioniert. Man muss nur beachten, dass der dnscrypt-proxy Daemon nicht auf Port 53 läuft, sondern bspw. auf 5053. Anschließend muss dann der PiHole selbst mit der 127.0.0.1#5053 als Custom Upstream DNS Server in der grafischen Konfiguration eingetragen werden.

Firefox

Seit 2018 experimentiert Firefox mit DoH als implementierte Lösung innerhalb des Browsers, was seit 2019 Bestandteil ist und auch standardmäßig aktiviert wird. Diese Lösung birgt allerdings mehrere Nachteile. Erstens findet die Verschlüsselung der DNS Anfragen nicht auf OS Ebene statt, sprich es werden nur Anfragen aus dem Firefox Browser verschlüsselt. Damit fällt die restliche Kommunikation diverser Anwendungen etc. hinten runter. Zweitens setzt Firefox (bzw. Mozilla) zunächst auf Cloudflare als DNS Resolver, welcher auch von Haus aus eingestellt ist.

Hierbei kommen wir wieder auf das „einer kennt alles“ Problem, zudem die Firma Cloudflare recht fragwürdig ist. Cloudflare wird in der Security/Privacy Szene mittlerweile skeptisch betrachtet, da diese die Benutzerdaten loggen und analysieren. Was das bedeutet kann man zwar nur erahnen, aber lässt höchstwahrscheinlich darauf schließen, dass ein Datentrog exisitiert. Und wo ein Trog ist…
Zusätzlich untersteht das große Unternehmen mit Sitz in San Francisco natürlich der US Administration. Nach einigen Protesten ist man mittlereweile in der Lage eigene Resolver einzutragen, was aber nicht den ersten Nachteil löst, dass DoH nicht systemweit läuft.

Fazit

Das Thema DNS Verschlüsselung wird gerade in heutiger Zeit immer wichtiger. Unabhängig von den sicherheitsrelevanten Aspekten, nützt es auch der digitalen Privatsphäre um es Internetfirmen zu erschweren, personenbezogene Profile für Werbung o.Ä. erstellen zu können.

Ich für meinen Teil setze bisher vollumfänglich auf die Software dnscrypt-proxy mit zusätzlicher Blacklist und wechsel hin und wieder den Resolver. Auf lange Sicht hin wäre es allerdings wünschenswert, wenn die DNS Kommunikation endlich als Standard im Internet verschlüsselt wäre.

---

Datum	Änderung
16.10.2020	Veröffentlichung
07.07.2025	– Wiederveröffentlichung – Veraltete Links entfernt

Auf die Firma Jolla und ihre Hard- bzw. Software wurde ich bereits im Jahr 2013 aufmerksam, als das erste Jolla Phone mit dem hauseigenen OS Sailfish auf den Markt kam und dies breit durch die Medien ging. SailfishOS basiert auf Mer, welches eine Fortführung von MeeGo ist. MeeGo sollte eigentlich (u.a.) in Nokias neuen Smartphones Verwendung finden, was allerdings durch den damaligen Kauf Nokias von Microsoft nicht mehr stattfand (das einzige MeeGo Gerät war das Nokia N9). Im Nachhinein betrachtet eine bedauerliche Entwicklung, denn was hätte aus Nokias bekanntlich guter Hardware mit diesem System werden können…

Hardware

Jolla selbst produziert seit längerer Zeit keine eigene Hardware mehr und ein Test auf einem 7 Jahre alten Gerät kam eher nicht in Frage. Stattdessen kann man nun alternativ unterstützte Hardware und eine SailfishX Lizenz für ca. 50€ erwerben. Nach Erfahrungsberichten in der Community, scheinen die Xperia Geräte von Sony eine gute Wahl zu sein, weshalb ich mich auch für ein XA2 entschied und die Meinung der Community insofern bestätigen kann.

Installation

Die Installation von SailfishX findet fast genauso wie bei einem Android Custom ROM statt. Benötigt wird hier nur fastboot bzw. die Android Tools um sich mit dem Gerät zu verbinden. Einziger Unterschied ist, dass noch ein Unlock-Key auf Basis der IMEI bei Sony abgefragt werden muss, welchen man vor der Installation angibt. Die eigentliche Installation (flashen) findet über ein Shellscript auf Kommandozeile statt, welches aufgerufen wird.
Übrigens ist die Lizenz anschließend an das Gerät gebunden (eigentlich auch an die Person). Ein Weiterverkauf der Lizenz ist also leider nicht möglich.

Design

Sailfish hob sich damals schon von der Masse ab und die Entwickler haben sich scheinbar einige Gedanken zur Bedienbarkeit eines Smartphones ohne Tasten gemacht. Das System war seiner Zeit voraus. Nach einem sehr guten Tutorial ist man eigentlich sofort in der Lage das UI bzw. die eingängige Gestensteuerung zu bedienen. Das Ganze ist dabei auch noch nett anzuschauen. Sailfish ist recht minimalistisch gehalten, was mir persönlich sehr gut gefällt. Der Ansatz laufende Apps auf dem Home-Screen statt im Hintergrund anzuzeigen ist zwar einzigartig, aber bestimmt auch Geschmackssache. Das System kommt von Haus aus mit einigen Themes, sogenannten Ambients, welche sich auch selber erstellen lassen. Über diese Funktion werden auch die Hintergrundbilder verwaltet bzw. geändert.

Basissystem

Das Basissystem ist sehr aufgeräumt und kommt nur mit den notwendigsten bzw. gängigsten vorinstallierten Apps (Kalender, Kontakte, Taschenrechner, Kamera etc.). Von Bloatware ist hier natürlich keine Spur, das System kann individuell „aufgebaut“ werden. Die Einstellungen sind übersichtlich und intuitiv aufgebaut. Ein „verirren“ in den Unterpunkten, wie es mir manchmal bei Android erging, ist hier eher ausgeschlossen. Das System verhält sich in seiner Basis schnell und flüssig. Ruckler, Abstürze, Hänger gibt es hier selten bis gar nicht. Dies kommt nur manchmal (aber in meinem Fall fast gar nicht) bei den Android Apps vor. Die Telefonqualität, welche bei Smartphones gerne mal außer Acht gelassen wird, ist bei Sailfish in Kombination mit dem XA2 meines Erachtens sehr gut.
Auch die vorinstallierte Kamera macht einen soliden Eindruck. Zwar liefert diese nur 16MP, aber für den ein oder anderen Schnappschuss reicht dies vollkommen aus. Wer hier mehr rausholen möchte, kann natürlich auf Drittanbieterapps zurückgreifen. Beim Thema Sicherheit kann das Sailfish noch durch eine Vollverschlüsselung des Systems punkten, welche nach der Installation automatisch aktiv ist.
Ein nicht weiter analysierter Fehler scheint in den Energiesparoptionen zu stecken. Selbst wenn diese gänzlich deaktiviert sind, ist das Gerät nicht mehr nutzbar wenn der Akku unter 10% fällt. Scheinbar wird die CPU dennoch massiv gedrosselt.
Die Akkuleistung bewegt sich in einem normalen Rahmen. Ich kam auf ca. 1-2 Tage.

Apps

Und hier kommen wir zu einem Vor- und gleichzeitig großen Nachteil bei SailfishX. Die native App-Unterstützung ist wie zu erwarten war vergleichsweise mau. Was mich wirklich erstaunt hatte, war das (nicht vorhandene) Angebot an nativen Webbrowsern. Der mitgelieferte Browser ist sehr langsam, was unter anderem an dem Unterbau liegt (Render-Engine Gecko mittels Qt5-Embedding) und es gibt nur sehr wenige Alternativen im Jolla-Store. Das Problem scheint länger bekannt zu sein und nur für das XA2 zu bestehen.

Sofern es native Apps gibt, sind diese allgemein entweder akzeptabel, oder nicht zumutbar. Das trifft bspw. auch auf die Mastodon App „Tooter“ zu. Mir persönlich gefiel das durchsichtige Design nicht und die Bedienung war leider umständlich. Die Verfolgung von zusammenhängenden Toots und das Antworten auf solche ist enorm umständlich. Außerdem meinte Tooter mir nach einiger Zeit immer wieder alle Benachrichtigungen anzeigen zu müssen, auch solche die Tage zurücklagen. Wenn man Toot! unter iOS gewohnt ist, ist Tooter zweifelsohne ein enormer Rückschritt. Auch die populärste OSM App aus dem Jolla Store gehörte in diese Kategorie. Für das nötigste reicht es, wobei die Suche nach einigen Orten keinerlei Ergebnisse lieferte. Für Matrix gab es leider noch nicht einmal eine native App. Bei meinem Ausflug über ein paar Tage hatte ich am Ende lediglich nur noch zwei native alltägliche Apps installiert (KeePass, GhostCloud). Der Rest kam aus dem Android Store bzw. F-Droid.

SailfishX lebt nach meiner Meinung also von der Android App Unterstützung. Diese läuft dafür auch sehr gut. Apps wie Osmand sind tatsächlich performant. Bis der richtige Webbrowser gefunden war, dauerte es allerdings eine Weile, da Firefox Focus bspw. recht langsam ist. Schlussendlich erwies sich Firefox Preview sogar mit uBlockOrigin Addon als gut nutzbar (während Firefox for Android Beta noch das Gegenteil bewies).

Da es den Signal Messenger nativ nicht gibt und dies mein Hauptmessenger ist, musste auch dieser über den Android Store kommen. Signal funktionierte grundsätzlich zwar, aber ein Bug mit Nextcloud und CardDAV sorgt dafür, dass die Kontakte nicht synchronisiert werden. Spiele habe ich abgesehen von Shakes&Fidget, welches einigermaßen ok lief, nicht getestet.

Nextcloud

Seit kurzem hat Sailfish eine im System implementierte Nextcloud Unterstützung, was ein riesiger Pluspunkt ist. So lassen sich direkt Dinge wie Kontakte, Kalender, usw. systemseitig konfigurieren.
Einzig die Möglichkeit mehrere Bilder auf einmal hochzuladen funktioniert leider nicht. Hierfür muss man auf auf die native App GhostCloud zurückgreifen. Die integrierte Datensicherung des Systems, welche allerdings warum auch immer Medieninhalte ausschließt, kann ebenfalls mit Nextcloud out of the box realisiert werden.

Unterbau

Eine der größten Stärken wie bei allen Linux basierten Smartphones ist natürlich der Unterbau und die Möglichkeit diesen auch nutzen zu können. Unter Sailfish läuft ein vollwertiges Linux, dass sich theoretisch nach belieben anpassen lässt. Ein sehr gutes Beispiel ist hier die Nutzung eines eigenen DNS-Proxy.
Ein hilfreicher Tipp für die Nutzung der Linux Kommandozeile ist die native App ShellEx, mit welcher sich schnell Befehle absetzen lassen, welche man auch speichern kann. Das ist z.B. praktisch für die Android-Systemeinstellungen, über die man anders nich drankommt (der Punkt fehlt in den Einstellungen).
Seit Version Sailfish 3.3 wird übrigens auch Flatpak unterstützt.

Nach der Aktivierung der Remote-Verbindung ist der Zugriff auf Sailfish per SSH möglich:

Zusätzliche Software

Das Basissystem kommt stellenweise nur recht spartanisch daher. So fehlt bspw. wget.
Um zusätzliche Software installieren zu können kann man pkcon verwenden, oder zypper nachinstallieren. Für wget reicht aber pkcon vollkommen aus. Als zusätzliche Paketquellen eignet sich openrepos.net. Über diese Seite bin ich auf den User NielDK auf openrepos.net gekommen, in dessen Repo alles notwendige für wget vorhanden ist.

Nachdem man unter den Einstellungen Fremdsoftware erlaubt hat, muss der openrepos.net Hauptschlüssel importiert werden:

rpm --import https://sailfish.openrepos.net/openrepos.key

Das Repo kann man mit ssu hinzufügen und sollte sofort aktiviert (enabled) sein:

ssu addrepo openrepos https://sailfish.openrepos.net/NielDK/personal/main/

Mit „ssu repos“ kann kontrolliert werden, ob das Repo im User-Bereich aktiv ist.
Die Installation von wget erfolgt dann nur noch mit

pkcon install wget

dnscrypt-proxy

Auf allen meinen Systemen läuft mittlerweile dieses kleine Stück Software. Umso erfreulicher fand ich es, dass dnscrypt-proxy ebenfalls auf Sailfish ohne größere Probleme installiert werden kann.

Benötigt wird die arm-Version von dnscrypt-proxy (Version 2.0.44 verlinkt). Voraussetzung für die Installation ist natürlich, dass der Entwicklermodus aktiv ist und man per SSH auf dem Gerät ist.

Vor der Installation bzw. Nutzung muss der vorhandene DNS Proxy connmand deaktiviert werden:

    touch /var/lib/environment/connman/nodnsproxy.conf

    echo "CONNMAN_ARGS=--nodnsproxy" > /var/lib/environment/connman/nodnsproxy.conf

Diese Arbeit übernimmt anschließend dnscrypt-proxy, was noch für die mobilen Verbindungen konfiguriert werden muss. Dies erfolgt über Datei /home/.system/var/lib/connman/settings.
Dort sollte in der [WiFi] Sektion folgende Zeile stehen:

Nameservers=127.0.0.1;

Damit die Einstellungen wirksam werden, kann man connmand mit

systemctl restart connman.service

neustarten.

Die Installation von dnscrypt-proxy unterscheidet sich ansonsten nicht zu anderen Linux basierten Systemen.
Nachdem man die Konfigurationsdatei (dnscrypt-proxy.toml) nach seinen Anforderungen angepasst hat, kann der Dienst installiert und gestartet werden.

Fazit

Ich bin seit 2009 iOS User, allerdings mit einer einjährigen Unterbrechung mit Cyanogen Mod. Ich gebe daher offen zu, dass ich in der Hinsicht ein absolutes Gewohnheitstier bin und einige Vorzüge von iOS genieße. Ein Smartphone ist nun einmal ein alltäglicher Gebrauchsgegenstand und muss oder sollte in manchen Situationen einfach funktionieren. Sailfish ist da nur durch die Android App Unterstützung einigermaßen nah dran. Ohne diese wäre Sailfish nur zum experimentieren und entwickeln geeignet. Einen kleinen bitteren Nachgeschmack hat Sailfish insofern, dass es nur in Teilen Open Source ist. Das kann natürlich an dem Android-System Layer liegen, aber auch an der Exchange Unterstützung, welche Jolla ebenfalls nur bei einem lizensierten SailfishX anbietet.

---

Datum	Änderung
16.10.2020	Veröffentlichung
07.07.2025	– Wiederveröffentlichung – Fazit angepasst