Finger drauf – Tür auf: Was das BGH entschieden hat

Der BGH in einem gerade veröffentlichtem Urteil hat klargestellt: Ermittlungsbehörden dürfen Beschuldigte zwingen, ihr Smartphone per Fingerabdruck oder Gesichtserkennung zu entsperren. Die sogenannte Selbstbelastungsfreiheit (auch bekannt als nemo tenetur) greift dabei nicht – denn biometrische Entsperrung gilt juristisch als passiv. Solange ich also nicht aktiv eine PIN mitteile, ist der Zwang rechtlich zulässig.

Das Urteil (Az. 2 StR 232/24) findet sich hier im Volltext und ist in seiner juristischen Tragweite ziemlich deutlich: Der Staat darf bei entsprechender Verdachtslage biometrische Entsperrmethoden gegen den Willen der Betroffenen nutzen. Die Hürde liegt damit nicht mehr in der technischen Umsetzbarkeit, sondern nur noch in der rechtlichen Begründung durch die Ermittler.

Warum uns das alle betrifft – nicht nur Kriminelle

Natürlich wird niemand gezwungen, biometrische Sperren zu verwenden. Aber genau das ist der Punkt: Viele von uns tun es freiwillig, oft ohne zu wissen, was das im Ernstfall bedeutet. Wer glaubt, dass Datenschutz nur für „die mit was zu verbergen“ gilt, hat das Prinzip nicht verstanden. Es geht um Selbstbestimmung. Darum, wer Zugriff auf unsere privaten Daten hat – und unter welchen Bedingungen.

Unsere Smartphones enthalten weit mehr als nur Telefonnummern, Chats und Urlaubsfotos. Kalender, Standortverläufe, 2FA-Apps, Banking, Trading, Passwortmanager und vieles mehr. Wer Zugriff auf ein entsperrtes Gerät hat, kann in kürzester Zeit tiefe Einblicke in unser digitales Leben gewinnen. Umso wichtiger ist es, bewusst zu entscheiden, wie wir unsere täglich mit uns herumgetragenen Geräte schützen.

Biometrischen Entsperren temporär deaktivieren

Zum Glück bieten moderne Smartphones und Tablets mit Android oder iOS mittlerweile direkte Wege, biometrische Entsperrung wie eben den Fingerabdruck mit einem oder wenigen Knopfdrücken auszuschalten, ohne die Biometrie komplett zu deaktivieren. Das kann in Situationen wichtig sein, in denen ihr kurz davor steht, euer Gerät aus der Hand zu geben. Etwa bei einer Kontrolle oder Durchsuchung.

Android (Google, Samsung und Co.)

• Allgemein (meiste Geräte): Ein/Aus-Taste lange gedrückt halten » Sperren
• Google Pixel: Ein/Aus-Taste + Lauter gleichzeitig » Sperren

Damit wird die aktuelle Sitzung gesperrt und biometrische Entsperrung per Fingerabdruck oder Gesichtserkennung ist deaktiviert. Eine PIN oder ein Passwort ist danach zum Entsperren des Geräts zwingend erforderlich. Auch ein Neustart würde in diesem Fall nicht weiterhelfen, da sich das Gerät danach sowieso nur per Pin aufsperren ließe.

Hinweis: Wer möchte, kann das Verhalten der Powertaste in den Einstellungen von Android anpassen: Einstellungen » System » Touch-Gesten & Bewegungen » Ein-/Aus-Taste gedrückt halten » Ein-/Aus-Menü

Apple (iPhone, iPad, iOS)

• 5x schnell die Seitentaste drücken » biometrische Entsperrung wird deaktiviert (auch bekannt als Lockdown Mode)

Seit iOS 18.4 gibt es außerdem ein interessantes Detail: Wird das iPhone drei Tage lang nicht benutzt, startet es automatisch neu und wechselt in den sogenannten BFU-Modus („Before First Unlock“). Selbst professionelle Forensiklösungen wie Cellebrite haben dann (zumindest laut ihrer eigenen Aussage nach) Probleme, an die Daten zu kommen. Solange die PIN eben nicht bekannt ist.

Konsequenz: Komfort oder Kontrolle – ihr entscheidet

Ich will niemandem vorschreiben, wie ihr eure Geräte absichert. Aber ich finde es wichtig, die Folgen zu kennen. Biometrie ist bequem, aber eben auch angreifbar, gerade aus juristischer Sicht. Wer sich auf den Schutz durch Fingerabdruck oder Gesichtserkennung verlässt, sollte sich bewusst sein, dass dieser Schutz in bestimmten Situationen keinen Bestand hat. Die einfache Alternative: PIN oder Passwort und im Zweifel schnell auf den Sperren-Knopf. Damit behaltet ihr die Kontrolle darüber, wann euer Gerät entsperrt wird und vor allem, durch wen.

DNS-Blocking direkt am Client

AdGuard für Linux funktioniert nach dem gleichen Prinzip wie die bereits genannten Projekte: Es klinkt sich auf Systemebene in den DNS-Verkehr ein und blockiert darüber Domains, die Werbung, Tracking oder Malware ausliefern. Statt also in jedem einzelnen Browser Erweiterungen zu installieren, läuft das Programm im Hintergrund als lokaler DNS-Proxy. Auch in verschlüsselte Verbindungen klinkt sich AdGuard mit einem eigenen CA-Zertifikat ein.

Wenn ihr eine Webseite aufruft, prüft AdGuard im Hintergrund, ob diese Inhalte nachlädt, die auf einer Blockliste stehen – und unterbindet die Verbindung gegebenenfalls direkt auf DNS-Ebene. So lässt sich Werbung auch aus Anwendungen entfernen, für die es keine Adblocker-Erweiterung gibt. Wichtig unter Android, wo Apps alle Nase lang Werbung einblenden, eher irrelevant unter Linux, wo man mit Open-Source-Anwendungen von Anzeigen verschont bleibt.

Der große Unterschied zu AdGuard Home oder Pi-hole besteht darin, dass AdGuard für Linux nicht zentral im Netzwerk arbeitet, sondern lokal auf dem jeweiligen Gerät. Das macht es vor allem für mobile oder Einzelplatz-Systeme interessant – etwa Notebooks, mit denen ihr regelmäßig unterwegs seid und nicht auf euren heimischen DNS-Server zugreifen könnt.

Nur Konsole – keine grafische Oberfläche

AdGuard für Linux verzichtet vollständig auf eine grafische Benutzeroberfläche. Stattdessen erfolgt die gesamte Konfiguration und Steuerung über ein Kommandozeilenwerkzeug namens adguard-cli. Wer ohnehin lieber im Terminal arbeitet, wird sich damit schnell zurechtfinden.

Eine interaktive Konfiguration führt euch nach der Installation durch die wichtigsten Einstellungen. Praktisch: Ihr könnt direkt entscheiden, ob ihr eine Testlizenz nutzen wollt – dazu ist allerdings ein kostenloser AdGuard-Account notwendig. Danach könnt ihr das Programm aktivieren, konfigurieren und starten.

Features in AdGuard für Linux 1.0

AdGuard für Linux fehlt in der ersten Version zwar eine GUI, aber über das reine Adblocking hinaus gibt es eine Reihe von Funktionen:

• App-Exclusion-Feature: Damit könnt ihr einzelne Programme oder Browser von der Filterung ausnehmen, wenn es zu Problemen kommt.
• Vordefinierte Ausnahmelisten: Für häufig genutzte Anwendungen stellt AdGuard bereits Ausnahmelisten zur Verfügung – das spart euch manuellen Aufwand.
• Filterverwaltung: Ihr könnt eigene Filterlisten hinzufügen, bestehende aktivieren oder deaktivieren und AdGuard-Filter individuell anpassen.
• Effizientere Updates: Beim Aktualisieren der Filterlisten lädt AdGuard nur die veränderten Teile nach – das spart Bandbreite.
• Proxy-Unterstützung: Sowohl HTTP- als auch SOCKS5-Proxys werden unterstützt. Änderungen an der Konfiguration oder den Filterlisten werden automatisch übernommen, ohne dass ihr AdGuard neu starten müsst.

Installation (getestet unter Ubuntu 25.04)

Die Installation beschreibt AdGuard in der Dokumentation. Hier nochmal die wichtigsten Schritte: Um das Tool auf euer Linux-System zu bringen, führt ihr einfach folgenden Befehl im Terminal aus:

$ sudo apt install curl
$ curl -fsSL https://raw.githubusercontent.com/AdguardTeam/AdGuardCLI/release/install.sh | sh -s -- -v

Gebt bei Nachfrage euer Passwort ein, bestätigt den Installationsvorgang mit Y und drückt Enter. Nach der Installation startet ihr mit:

$ adguard-cli activate

Wählt hier beispielsweise Get a trial license, wenn ihr AdGuard erst einmal testen möchtet. Ohne eine Registrierung kann man den Spaß allerdings nicht ausprobieren.

Lizenz ab 2,49 Euro im Monat

Apropos Registrierung: Wer AdGuard für Linux nicht nur testen, sondern auch dauerhaft nutzen möchte, muss eine Lizenz kaufen. Die Einzellizenz (bis zu 3 Geräte) kostet 2,49 Euro/Monat. Die Familienlizenz (bis zu 9 Geräte) schlägt aktuell mit 4,99 Euro/Monat zu Buche. Der Preis soll auf 7,47 Euro/Monat steigen. Abgerechnet wird jeweils für ein ganzes Jahr. Die „lebenslange“ Lizenz kostet einmalig 74,99 bzw. 159,99 Euro (später 224,97 Euro).

Konfiguration (die wichtigsten Schritte)

Danach ruft ihr den Konfigurationsassistenten auf:

$ adguard-cli configure

Und schließlich startet ihr den Dienst mit:

$ adguard-cli start

Zum Anhalten oder Überprüfen des Status könnt ihr diese Befehle nutzen:

$ adguard-cli stop
$ adguard-cli status

Fazit: Interessant, aber eher nicht nötig

AdGuard für Linux ist ein Tool für alle, die auf einfache Weise DNS-basiertes Adblocking auf ihrem Linux-System einsetzen möchten – ohne einen dedizierten Netzwerkdienst wie Pi-hole oder AdGuard Home einzurichten. Der Verzicht auf eine grafische Oberfläche ist für viele von euch sicher kein Nachteil, sondern eher ein Pluspunkt.

Trotzdem bleibt ein Wermutstropfen: AdGuard ist keine freie Software. Ihr gebt bei der Nutzung persönliche Daten wie eure E-Mail-Adresse an, müsst euch für die Testlizenz registrieren und euch auf einen proprietären Dienst verlassen. Wenn ihr maximale Kontrolle und Transparenz sucht, bleibt Pi-hole auf einem dedizierten Gerät oder ein selbst gehostetes AdGuard Home oft die bessere Wahl.

Und ganz ehrlich: Warum braucht man DNS-Level-Adblocking direkt auf seinem Linux-System? Noch dazu mit einem nicht gerade günstigen Abonnement? Für Firefox und Chrome gibt es Adblocker-Erweiterungen wie uBlock Origin, die deutlich mehr Kontrolle über das Adblocking bieten. Browser-Alternativen wie Brave bringen einen integrierten Werbeblocker gleich mit. Und selbst der GNOME-Webbrowser „Web“ blockiert Anzeigen ganz ohne zusätzliche Erweiterungen.

Ansonsten ist bei mir freie Software am Start, die nicht nach Hause telefoniert und keine Anzeigen einblendet. DNS-Level-Adblocking ist super, wenn man keinen Einfluss auf Geräte oder Apps hat. So darf beispielsweise mein Smart-TV via Pi-hole ins Netz. Ohne den kleistert LG den Homescreen und selbst das laufende Fernsehbild mit Werbung und Eigenanzeigen zu. Aber für ein Linux-System braucht es den Spaß in meinen Augen nicht. Wer – aus welchem Grund auch immer – sowieso ein AdGuard-Abo hat, findet vielleicht einen Nutzen bei der Linux-Version. Aber ein Argument, jetzt ein Abo abzuschließen, ist die Linux-Version sicher nicht.

Falls ihr ein Abonnement von AdGuard ernsthaft in Erwägung zieht: Für welchen Einsatzzweck genau? Mich interessiert, ob ich einen sinnvollen Use Case übersehe – etwa bei speziellen Netzwerkkonfigurationen, im beruflichen Umfeld oder in komplexeren Setups. Teilt gern eure Erfahrungen oder bevorzugten Alternativen.

Poseidon ist noch ein sehr junges Projekt. Die ersten Commits im Github der Entwickler stammen von Anfang September des letzten Jahres. Die aktuelle Versionsnummer steht bei Poseidon 0.3.9. Daher lässt sich das Programm in der Regel auch noch nicht aus den offiziellen Paketquellen installieren. Arch-User haben es dennoch leicht den Browser auf ihrem System einzuspielen. Eine kurze Recherche im AUR treibt das PKGBUILD poseidon-browser-git auf, sodass sich die Installation (bei installiertem AUR-Helper) auf ein Kommando beschränkt. Optional sollte man sich vielleicht gleich noch die auf der Projekt-Seite beschriebenen optionalen Abhängigkeiten installieren. Man braucht sie nicht zwingend, allerdings erlauben Sie das Streamen von Videos oder erweiterten Funktionen wie der Anzeige eines Terminalfensters direkt im Browser.

Installation unter Arch Linux

### Poseidon unter Arch Linux installieren.
### Browser aus dem AUR, plus optionale Abhängigkeiten:
$ pacaur -S poseidon-browser-git
$ sudo pacman -S gst-libav gst-plugins-base gst-plugins-good evince vte3 flashplugin icedtea-web

Für Anwender mit Ubuntu auf dem Rechner gibt es derzeit weder eine PPA-Paketquelle, noch separate DEB-Pakete. Man muss die Anwendung daher aus dem Quellcode installieren — Da sie in Python entwickelt wird, lässt sich dies jedoch recht leicht bewerkstelligen. Poseidon benötigt mindestens WebKit 2.12.3, was ab Ubuntu 14.04 vorhanden sein sollte, ich habe die Installation allerdings lediglich mit Ubuntu Gnome 16.10 getestet: Das Vorgehen beschränkt sich auf die Installation der Abhängigkeiten, anschließend holt ihr euch den Code aus dem Quellcode und verschiebt ihn mit Root-Rechten nach /opt. Anschließend kopiert ihr die .desktop-Datei noch nach /usr/share/applications, so erscheint Poseidon dann auch in den Anwendnungsmenüs eurer Desktopumgebung.

Installation unter Ubuntu 16.10

### Poseidon unter Ubuntu 16.10 aus dem Git laden und installieren:
a$ sudo apt install git gir1.2-evince-3.0 gir1.2-webkit2-4.0 python3-decorator python3-openssl
### Zum Aktualiseren von Poseideon die folgenden zwei Kommandos wiederholen:
$ git clone https://github.com/sidus-dev/poseidon /tmp/poseidon-browser-git
$ sudo mv /tmp/poseidon-browser-git /opt
### Programmstarter im Anwendungsmenü ablegen:
$ sudo cp /opt/poseidon-browser-git/poseidon.desktop /usr/share/applications

Das Erscheinungsbild von Poseidon ist nun recht schlicht: Der Aufbau der Oberfläche unterscheidet Poseidon nun nicht groß von Chrome oder Firefox. Über die Adresszeile ruft ihr die gewünschten Webseiten aus, Tabs findet ihr am oberen Rand, die üblichen Tastenkürzel wie [Strg]+[T], [Strg]+[W] oder [Strg]+[N] zum Öffnen und Schließen von neuen Tabs und Öffnen eines neuen Fenster funktionieren auch in Poseidon. Die Optionen öffnet ihr über das Hamburger-Menü in der rechten oberen Ecke der Toolbar. Hier lassen sich die Einstellungen öffnen oder Funktionen wie der Adblocker, NoScript oder Plugins und ein SSL-Enforcer de-/aktivieren. Der Defcon Mode entspricht dem Incognito-Modus von Chrome/Chromium. Dieser deaktiviert den Cache, vermeidet Cookies und speichert den Seitenverlauf nicht in der Browserhistorie ab.

Ungewöhnliches findet ihr nun hingegen im Untermenü Utilities: In diesem könnt ihr unter anderem einen Passwortgenerator öffnen, es gibt einen User Agent Switcher (so dass ihr für den Webserver wie ein anderer Browser erscheint) sowie eine Option zum Einblenden eines Terminalfensters am unteren Rand des Browsers. Diese Funktion finde ich recht praktisch, wenn man beispielsweise gerne mal Daten mit Kommandozeilenwerkzeugen wie wget oder youtube-dl aus dem Netz lädt. Zudem kann man hier einen Fullscreen-Modus aktivieren oder sich die für den Browser zugänglichen Plugins anzeigen lassen. Auch der Browserverlauf und den Bookmarkmanager ruft man aus diesem Menü heraus auf. Wer es ein wenig bunter mag, öffnet ein beliebiges Bild im Browser und klickt dann im Kontextmenü die Option Apply as theme an. Diese übernimmt das Bild dann als Hintergrund unter der Tableiste des Browsers.

Etwas ungewohnt sind die Schaltflächen in der Fensterleiste: Mit den Hoch- und Runter-Pfeilen am linken Rand speichert ihr die aktuelle Seite ab beziehungsweise öffnet eine lokale Datei von der Festplatte. Die Schalter „+“ und „-“ am rechten Fensterrand öffnen einen neuen Tab oder schließen den aktuellen. Üblicherweise findet sich der Knopf zum Schließen eines Reiters direkt auf diesem, von daher finde ich diese Design-Entscheidung ein wenig verwirrend. Mir persönlich fehlt zudem die Möglichkeit eine Webseite mit [F5] neu zu laden. Poseidon verwendet stattdessen das Tastenkürzel [Strg]+[R]. Ein [Umschalt]+[F5] (oder eben [Strg]+[Umschalt]+[R]) zum Auffrischen des Caches gibt es gar nicht.

Alles in Allem finde ich Poseidon eigentlich recht gelungen. Das noch sehr zarte Alter merkt man dem Programm kaum an. Der Browser passt sich gut in GTK3-Desktops wie Gnome, Budgie oder Cinnamon ein. Da Adblock und NoScript von Haus aus vorhanden und aktiv sind, halte ich den Webbrowser für eine gute Lösung, wenn man schnell mal eine Webseite abseites seines Standardbrowsers laden möchte. Was von fehlt ist eine deutsche Übersetzung (aktuell gibt es das Programm auf Englisch und Italienisch) sowie Funktionen zum Bearbeiten der Adblocker und NoScript-Einstellungen. Bislang lassen sich diese Funktionen lediglich global ab- und wieder anschalten. Etwa einzelne Seiten vom Adblocker auszuklammern ist nicht möglich.

Stylish ist bei vielen Anwendern beliebt: Die Chrome-Version verzeichnete bereits über 1,6 Millionen Installationen, das entsprechende Firefox-Add-on wurde über 420.000 mal in den Browser geladen. Der Code der Erweiterung liegt offen, er ist unter der GPLv3 lizenziert — so weit, so gut. Nun nimmt die Entwicklung solch eines Projekts nicht wenig Zeit in Anspruch. Der Aufwand ließ sich bislang kaum refinanzieren. Der ursprüngliche Gründer der Erweiterung Jason Barnabe hat wohl auch aus diesem Grund im September 2016 die Segel gestrichen und mit Justin Hindman einen neuen Projektleiter ernannt. Dieser führt Stylish nun zu komplett neuen Gefilden: Er holt mit SimilarWeb (hier die Wikipedia zum Unternehmen) eine Data-Mining-Spezialisten an Bord.

Anfang 2017 wurde Stylish nun von SimilarWeb aufgekauft. In seiner Ankündigung spricht Hindman davon, dass man einen für die Weiterentwicklung von Stylish einen Partner mit den entsprechenden Ressourcen bräuchte: Diesen hat man nun mit den Schnüffelspezialisten von SimilarWeb gefunden. SimilarWeb kauft Stylish natürlich nicht ohne Grund. In Zukunft unterstützen die Nutzer der Erweiterung die Datensammlerei des Tracking-Unternehmens: „Stylish users will be joining SimilarWeb’s market research panel“. Was das bedeutet zeigt sich im aktuellen Update der Erweiterung, diese überträgt nun automatisch Informationen über das Surfverhalten zu SimilarWeb, die Zustimming dazu wird automatisch gesetzt, man muss die Funktion extra deaktivieren.

In der Diskussion der Ankündigung schreibt die neue Produktmanagerin „Natalieg“, wie die Datensammlung funktionieren soll. Um dem User Vorschläge für passende Userstyles geben zu können, wird nun jeder Seitenaufruf inklusive den Referrer mit einer für jede Installation zufällig generierten User-ID an Stylish (und damit SimilarWeb) gemeldet. Ganz selbstverständlich client- und serverseitig anonymisiert sowie verschlüsselt übertragen, sodass die Privatsphäre gewahrt bleibt. Man muss nicht lange überlegen, wie gut so eine Strategie bei ähnlichen Verfahren (Stichwort Web of Trust oder kurz WOT) funktioniert hat… Gar nicht.

Let me give you a quick rundown of how it works: every time a browser navigates to a new page, the extension queries the servers for saved and available styles. The data collected includes the current, previous and referrer pages and for each new install a random user ID is created. All communication runs through https, to provide a layer of protection. The collected data is cleaned from PII in the client and server side, to make sure privacy is preserved and personal information isn’t used at any point.

In einem unkritischen Beitrag zum Thema auf Ghacks hat Ublock Origin-Entwickler Gorhill seine Analyse zum „neuen“ Stylish veröffentlicht. Ich zitiere seinen Kommentar hier fast in kompletter Länge, damit die Analyse auf jeden Fall erhalten bleibt. Sein niederschlagendes Ergebnis: Stylish versucht die übertragenen Daten zu verschleiern, die User-ID braucht es eigentlich nicht, Stylish überträgt die vollständige URL aller aufgerufenen Webseiten (warum nicht nur die Domain?), ebenso wird auch die vollständige Referer-URL übertragen (warum überhaupt?). Alles werden Stylish-User nun zum gläsernen User.

So yes, Stylish can now build a profile of your browsing history. The two-pass encoded base64 is something I have seen elsewhere in other such extensions with tracking ability, for example with Web of Trust and Popup Blocker. There is no other purpose than a silly attempt at obfuscating what it is doing. Any rationale to explain this attempt at obfuscation will be pure BS (there is no valid reason AT ALL to encode twice base64 — so the only explanation left is „let’s not make it too obvious what we are sending“).

[…]

It must be noted that the information sent is by no mean anonymous, because of the unique user id in each POSTed request, and on top of this by sending data to „api .userstyles.org“ server, the server will be able to match your IP with the data sent (your browsing history). But regardless, even if using a VPN, the POSTed data still identify you through the unique id (very bad — defeats the purpose of using a VPN as a mean to enhance anonymity).

[…]

All these are not necessary for the official stated goal — and of course the worst is that the claim that the data is anonymous is false. If the will to not collect browsing history was really genuine, the extension would have been written in a very different way to accomplish the stated goal.

Seiner Analyse nach funktioniert wenigstens die Opt-Out-Funktion: „My advice is if you *really* need that extension, disable the option to send supposedly anonymous data — so far, as of writing, it seems it does what it says.“ Wenn man Stylish unbedingt nutzen möchte, sollte man daher auf jeden Fall in den Einstellungen den entsprechenden Schalter setzen. Nutzer von Firefox sind aktuell noch auf der sicheren Seite, anscheinend hat Mozilla das Update noch nicht durchgewunken. Als Alternative kann man sich allerdings schon jetzt FreeStyler oder StylRRR ansehen.

Die umfassende Liste vergleicht auf Google Docs über 120 aktuell aktive VPN-Anbieter aus allen Herren Länder nach verschiedenen Kriterien wie Rechtsstandort, Logging-Aktivitäten, anonyme Bezahloptionen, verfügbare VPN-Protokolle (PPTP, OpenVPN, etc.), Anzahl der Exit-Länder und Server, die generelle Einstellung zu Anonymität im Netz sowie natürlich auch die Preise der jeweiligen Angebote. Im Endeffekt kann man sich so wirklich sehr einfach einen Überblick über die derzeitige VPN-Landschaft verschaffen und schnell den für sich am besten geeigneten VPN-Anbieter heraussuchen.

Mit „Funktioniert in China“ fehlt in meinen Augen jedoch auf den ersten Blick eine wichtige Information (von dort aus hat man keinen Zugriff auf Google oder auch heimische Webmail-Anbieter wie GMX). Doch wie die FAQ erklärt, geht die VPN-Vergleichs-Liste auf dieses Kriterium ganz bewusst nicht ein, da man so den Zensoren die Arbeit abnehmen würde, die noch funktionierenden VPN-Dienste aufzuspüren — Wobei die Liste natürlich allein aufgrund ihrer Existenz den Ausschluss weiterer VPN-Anbieter erleichtert. Von daher müssen China-Reisende die Verfügbarkeit selber austesten, oder sich sich am besten gleich Zuhause oder im Netz einen kleinen VPN-Server aufsetzen.

UPDATE 22.01.2016: Dieser Artikel ist inzwischen veraltet, da Synology DSM 6.0 das Einbinden und Aktualisieren von Lets’s Encrypt-Zertifikaten out-of-the-box unterstützt. Wer eine halbwegs aktuelle Diskstation besitzt, sollte daher besser das System auf einen aktuellen Stand bringen, sodass DSM 6.0 läuft und sich dann an diese Anleitung halten: Mit DSM 6.0 Let’s Encrypt-Zertifikate auf Synology-NAS einrichten.

Zum Erzeugen des Let’s-Encrpyt-Zertifikat holt ich euch den vom Projekt bereitgestellten Client auf den Rechner. Unter Arch Linux bekommt ihr das Programm schon aus den offiziellen Paketquellen, für Ubuntu hat zum Beispiel Thomas Leister bereits eine kleine Installationsanleitung geschrieben. Der Client fungiert als Schnittstelle zwischen eurem System und den Servern des Projekts. Er kann auch Zertifikate direkt im System installieren und in Apache einbinden. Für das Erstellen eines Zertifikats, das später einmal auf einem NAS landen soll, braucht man diese Funktionen allerdings gar nicht.

$ pacman -Ss letsencrypt
community/letsencrypt 0.1.0-1 [Installiert: 0.0.0.dev20151201-1]
    A tool to automatically receive and install X.509 certificates to enable TLS
    on servers. The client will interoperate with the Let’s Encrypt CA which
    will be issuing browser-trusted certificates for free.
community/letsencrypt-apache 0.1.0-1
    Apache plugin for Let’s Encrypt client
community/letsencrypt-nginx 0.1.0-1
    Nginx plugin for Let’s Encrypt client
community/letshelp-letsencrypt 0.1.0-1
    Let's help Let's Encrypt client
$ sudo pacman -S letsencrypt

Anschließend ruft ihr den Let’s-Encrpyt-Client mit Root-Rechten auf. Die Option certonly -a manual sorgt dabei dafür, dass der Client das Zertifikat nur erzeugt, aber nicht auch noch zu installieren versucht. In der Beta-Version musste man zudem noch mit etwa --server https://acme-v01.api.letsencrypt.org/directory der Server angeben, mit der heute veröffentlichten Version 0.1.0 des Clients ist diese Option nun nicht mehr nötig. Verzichtet ihr auf die Angabe einer Domain und einer E-Mail-Adresse wird euch das Programm nach diesen Angaben fragen, alternativ gibt ihr diese Infos dem Client gleich mit auf dem Weg.

### Ohne Optionen, Abfragen erfolgen in einer Ncurses-Oberfläche
$ sudo letsencrypt certonly -a manual
### Direkt mit allen Angaben
$ sudo letsencrypt certonly -a manual --email du@email.de -d domain.example.com

Voraussetzung für diese Aktion ist natürlich, dass euer NAS über HTTP und HTTPS aus dem Netz zu erreichen ist und dass ihr eine DynDNS-Adresse besitzt, unter der euer Netzwerkspeicher aus dem Internet zu erreichen ist. Eine Synology erfüllt diese Kriterien, wenn ihr unter Systemsteuerung | Externer Zugriff | DDNS ein entsprechendes Konto eines DynDNS-Anbieters einträgt (alternativ können diese Aufgabe aber auch Router wie eine Fritz!Box übernehmen und unter Systemsteuerung | Webdienste die Web Station als Dienst aktiviert und weiter unter die Option HTTPS-Verbindungen für Webdienste aktivieren setzt. Beachtet bitte auch, dass ihr mindestens die Ports 80 (für HTTP) und 443 (für HTTPS) von eurem Router auf das NAS weiterleitet müsst.

Weiter geht es mit der Zertifikat: Der Let’s-Encrpyt-Client versucht nun die angegebene Domain zu erreichen und zeigt euch bei Erfolg eine Adresse wie „http://domain.example.com/.well-known/acme-challenge/hierkommteinzufälligercode“ mitsamt einem langen kryptischen Code an. Diese URL mitsamt der damit verbundenen Datei dient zur Identifikation eures Webservers. Die Installations-Skripte des Clients könnten euch diese Aufgabe nun abnehmen, allerdings kann der Client mit eurem NAS-System nun natürlich weniger anfangen, daher müsst ihr diese Datei von Hand auf dem Webserver des NAS-Systems anlegen.

Loggt euch also beispielsweise per Samba auf eurem NAS ein, wechselt in das Verzeichnis mit den Webdaten, erzeugt die Ordnerstruktur .well-known/acme-challenge (ja, der Punkt gehört da hin) und in diesem dann die Datei hierkommteinzufälligercode mitsamt dem länglichen String, den euch der Client ausgibt. Das ganze funktioniert natürlich in der Regel auch über die Weboberfläche des NAS-Systems. Zur Kontrolle könnt ihr danach einfach mal auf den Link klicken und ihn in einem Browser auf eurem Rechner öffnen. Dazu muss natürlich die Namensauflösung der Internetdomain auch aus eurem lokalen Netzwerk heraus funktionieren. Zeigt dieser den Inhalt der Datei an, dann sollte alles funktionieren.

Make sure your web server displays the following content at
http://domain.example.com/.well-known/acme-challenge/hierkommteinzufälligercode before continuing:

o6klFxce...diesercodedientzumidentifiziereneuresnas

If you don't have HTTP server configured, you can run the following
command on the target server (as root):

mkdir -p /tmp/letsencrypt/public_html/.well-known/acme-challenge
cd /tmp/letsencrypt/public_html
printf "%s" o6klFxce...diesercodedientzumidentifiziereneuresnas > .well-known/acme-challenge/o6klFxcezfKWMClYLxIw_HDJ1uPo268aZrtiaUpOtjg
# run only once per server:
$(command -v python2 || command -v python2.7 || command -v python2.6) -c \
"import BaseHTTPServer, SimpleHTTPServer; \
s = BaseHTTPServer.HTTPServer(('', 80), SimpleHTTPServer.SimpleHTTPRequestHandler); \
s.serve_forever()"
Press ENTER to continue

Liegt die Datei auf dem Webserver und habt ihr die Erreichbarkeit über den Browser geprüft, dann geht mit der Eingabe von [Enter] einen Schritt weiter. Die Let’s-Encrypt-Server rufen die Authentifizierungsdatei von eurem Webserver ab, kontrollieren sie auf Gültigkeit und stellen dann das für die angegebene Domain für 90 Tage gültige Zertifikat aus. Dieser landet dann automatisch unter /etc/letsencrypt/live/domain.example.com auf eurer Festplatte. Die begrenzte Gültigkeit begründet Let’s Encrypt mit erhöhter Sicherheit, da so verloren gegangene oder missbrauchte Zertifikate relativ schnell ihre Gültigkeit verlieren. Das Ziel sei es sowieso das Generieren der Zertifikate zu automatisieren, dann soll die Zeitspanne sogar noch weiter sinken.

IMPORTANT NOTES:
- Congratulations! Your certificate and chain have been saved at
/etc/letsencrypt/live/domain.example.com/fullchain.pem. Your cert
will expire on 2016-03-02. To obtain a new version of the
certificate in the future, simply run Let's Encrypt again.

Für die Installation der Zertifikate auf einem Synology-NAS müsst ihr euch nun wieder in die Weboberfläche eures Netzwerkspeichers einloggen und (im Falle eines Synology-Systems) nach Systemsteuerung | Sicherheit | Zertifikat gehen. Dort wählt ihr die Option Zertifikat importieren und gebt die privkey.pem als privaten Schlüssel und die fullchain.pem als Zertifikat an. Damit ihr an diese Dateien kommt, müsst ihr sie allerdings erst einmal aus dem Ordner mit Root-Rechten rauskopieren, da nur Root Zugriff auf diese Dateien hat und somit der Browser fehlende Rechte moniert. Ein Weg dies zu tun, wäre beispielsweise der Folgende, natürlich führen hier zahlreiche andere Wege zum selben Ziel.

$ sudo -s
# cd /etc/letsencrypt/live/domain.example.com/
# ls
cert.pem chain.pem fullchain.pem privkey.pem
# cp fullchain.pem privkey.pem /tmp
# exit
$ sudo chown $USER /tmp/*.pem

Am Ende meldet die Zertifikats-Verwaltung des Synology-NAS nun ein von der „Let’s Encrypt Authority X1“ signiertes SSL-Zertifikat. Die Gültigkeit beträgt wie gesagt 90 Tage, ihr solltet das Zertifikat vor Ablauf dieser Zeitspanne erneuern, wiederholt dazu einfache alle hier gezeigten Schritte. Aktuell führt daran kein Weg vorbei, hier müssen Synology und Co. aktiv werden und eine Funktion direkt in die Software der NAS-Geräte implementieren, über die sich Let’s-Encrypt-Zertifikate direkt aus dem System heraus erzeugen und Verwalten lassen. Die wird mit Sicherheit kommen. Ich hoffe, dass die Hersteller dabei aber auch ältere Geräte nicht außen vor lassen. Noch ein Hinweis am Rande: Meldet das System ein von „Happy Hacker Fake CA“ ausgestelltes Zertifikat, dann seid ihr noch mit einem Beta-Client unterwegs.

Am Ende muss auch noch der von euch genutzte Browser das Zertifikat akzeptieren. Das wäre zum Testzeitpunkt mit Chrome 47.0 wie auch mit Chromium 47.0 der Fall. Beide Browser signalisieren über ein grünes „https://“ in der Adresszeile, dass mit dem Zertifikat alles stimmt. Firefox 42.0 hingegen und beispielsweise der in Gnome integrierte Browser stoßen sich jedoch weiterhin am Aussteller des Zertifikats und melden „This Connection is Untrusted“. Ironischerweise muss als noch Mozilla als einer der wichtigsten Platinum-Sponsoren seine Hausaufgaben machen, was allerdings mit Sicherheit bald geschehen wird.

Internetzugang ohne Root blockieren

NetGuard lässt sich auf allen Android-Geräten installieren, die mit mindestens Android 5.0 ausgestattet sind. Root-Rechte sind wie angesprochen nicht erforderlich. Wer auf einen Google-Account und damit auch den App-Store verzichtet, der findet die Anwendung bei F-Droid. Die dort vorhandene Version wird allerdings nicht vom Autor gepflegt, daher ist die F-Droid-Version eventuell veraltet, der Autor leistet für diese auch keinen Support. Alternativ gibt es bei Google Play auch eine Beta-Version der App. Interessiert euch eher für den unter der GPL lizenzierte Quellcode, dann schaut im GitHub des Entwicklers vorbei. Dort bekommt ihr auch APK-Dateien, mit denen ihr NetGuard manuell am Play Store vorbei installieren könnt. Allerdings müsst ihr euch dann selber um Updates kümmern. Fragen und Ideen richtet ihr am besten über XDA-Developers direkt an den Entwickler.

Die Funktionsweise von NetGuard ist nun eigentlich recht simpel. Anstatt aufwändig mit Root-Rechten in das Android-System einzugreifen, baut NetGuard eine interne VPN-Verbindung auf, über die nach Aktivierung der Funktion erst einmal jeglicher Internetverkehr umgeleitet wird. In der Anwendung wird dann intern geregelt, welche Apps auf WLAN oder Mobilfunk zugreifen dürfen. In der Voreinstellung wird erst einmal jeglicher Verkehr ins Nirvana geschickt. Mit einem Klick auf das entsprechende Icon rechts neben den Apps schaltet ihr den Zugriff aufs Netz per WLAN oder Mobilfunk getrennt voneinander frei. Mit dem abwärts gerichteten Pfeil klappt ihr erweiterte Einstellungen auf, in diesen könnt ihr Zugriffsrechte weiter einschränken. Etwa ob die App nur bei Aktivität ins Netz darf oder ob bei aktivem Roaming der Hahn abgedreht werden soll.

NetGuard klemmt Android-Apps vom Netz ab

Im Test funktionierte das Verfahren recht einfach und zuverlässig. Der Entwickler Marcel Bokhorst (Homepage, GitHub) hat bereits schon reichlich Erfahrung im kritischen Umgang von Android mit der Privatsphäre seiner User. Aus seiner Feder stammt auch das Xposed-Modul XPrivacy, das Zugriffsrechte noch deutlich weiter einschränken kann, dazu aber eben Root-Rechte und das Xposed-Framework benötigt. NetGuard braucht weder Root-Rechte noch zieht es nach den Angaben des Entwicklers die Batterie leer, telefoniert nicht nach Hause und enthält keine Tracking-Funktionen. Die im Play Store angekündigten In-App-Käufe beziehen sich auf die in der App integrierte Spendenfunktion, die App selber lässt sich nicht durch Bezahlfunktionen oder sonstiges Hickhack erweitern.

Neben TextSecure hat Open Whisper Systems schon eine ganze Weile mit RedPhone auch eine VoIP-App im Programm, die verschlüsselte Telefonate über das Internet möglich macht. Mit Signal für Android vereint die Hacker-Gruppe nun beide Anwendungen zu einer App — so wie das bei der iOS-Version der Anwendung schon länger der Fall ist. Aus TextSecure wird Signal, der Link zum Eintrag Play Store bleibt daher erhalten, RedPhone wird jedoch nicht mehr als eigenständige Anwendung weiterentwickelt. Wer bisher TextSecure installiert hatte, der muss sich um nichts kümmern. Anwender mit RedPhone auf dem Handy werden den Hinweis erhalten doch bitte Signal zu installieren.

Der Quellcode von Signal, sowohl von den Clients wie aber auch von der Server-Komponente, liegt offen und das Programm wird von der Electronic Frontier Foundation für verschlüsselte Kommunikation und dem Schutz der Privatsphäre empfohlen. Das Programm hat schon einige Audits hinter sich, die dem Protokoll eine hohe Sicherheit attestieren. Allerdings gibt es durchaus auch Kritik, da Signal beispielsweise auf Google Cloud Messaging zurückgreift. Aufgrund der Verschlüsselung hat Google zwar keinen Zugriff auf die Inhalte der Nachrichten, Metadaten lassen sich dadurch allerdings recht einfach erheben.

AVG sammelt mit seinem Virenscanner personenbezogene Daten, zwar „nur“ anhand einer  Advertising-ID, aber dadurch natürlich trotzdem eindeutig zuordenbar. Zu den Daten gehören nicht nur Informationen wie und wann der Virenscanner angeworfen wird und ob und welche Viren gefunden werden. Nein, zu den von AVG gesammelten pseudo-anonymisierten Daten gehört der Verlauf der von euch per Browser besuchten Webseiten, die Suchhistorie, sowie Details zu den auf dem Gerät installierten Programmen und wie sie genutzt werden.

„Wir erfassen nicht personenbezogene Daten, um aus unseren kostenlosen Angeboten Geld zu verdienen, damit sie kostenlos bleiben, einschließlich:

• Mit Ihrem Gerät verbundene Werbe-ID;
• Browser- und Suchverlauf, einschließlich Messdaten; (Anmerkung von mir: AVG meint damit Metadaten)
• Internetdienstanbieter oder Mobilfunknetz, das Sie für die Verbindung zu unseren Produkten verwenden, und
• Daten zu anderen Anwendungen, die Sie auf Ihrem Gerät haben, und wie sie genutzt werden.

Browser- und Suchverlauf enthalten manchmal Begriffe, durch die Sie ggf. identifiziert werden können. Wenn wir darauf aufmerksam werden, dass ein Teil Ihres Börsenverlaufs Sie ggf. identifizieren könnte, behandeln wir diesen Teil des Verlaufs als personenbezogene Daten und anonymisieren diese Daten.“

Man kann natürlich damit argumentieren, dass der Browserverlauf und Informationen zu den auf den Geräten installierten Anwendungen benötigt werden, um Angriffsvektoren von Malware zu analysieren und Webseiten zu identifizieren, die als Malware-Schleuder dienen. Doch der Preis ist in meinen Augen deutlich zu hoch: Besonders für Snakeoil. Also liebe Linux-User: Solange ihr keinen File- oder Mailserver betreibt, der die dort gespeicherten Daten nach Windows-Malware durchsucht, braucht ihr unter Linux definitiv keinen Virenscanner.

Mit dem heutigen Update auf Ghostery 5.4.6 macht das Add-On seine Verflechtung mit der Anzeigenindustrie deutlich: Mit der neuen Consumer Messaging Platform oder kurz „CMP“ möchte Ghostery nun „Ankündigungen, Anzeigenkampagnen oder andere angemessene Benachrichtigungen“ direkt in den Browser seiner User schicken. Die Funktion lässt sich in den erweiterten Einstellungen deaktivieren, sie ist allerdings von Haus aus scharf gestellt. Egal ob man das Add-On gerade frisch installiert oder eine bestehende Installation aktualisiert. Auch der Einrichtungsassistent erwähnt das Werbenetzwerk mit keinem Wort.

„The CMP will allow us to message our users directly in their browser with product announcements, promotions, and other appropriate notifications. This messaging system and can be turned off at any time by accessing the advanced tab of the options menu.“

In meinen Augen sollte man daher in Zukunft besser die Finger von Ghostery lassen, besonders weil mit dem Privacy Badger der Electronic Frontier Foundation eine sehr gute und vor allen Dingen freie Alternative existiert. Das Add-On gibt es als Erweiterung für Chrome und Chromium (hier auch als CRX-Datei zur Installation ohne den Chrome Web Store) sowie für Mozillas Firefox. Eine Version für Opera, Safari und Firefox Mobile soll später noch folgen.