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.

USB-Sticks auf Fehler prüfen

Im ersten Schritt müsst ihr die Geräte-ID des USB-Sticks oder der Speicherkarte herausfinden. Steckt den Datenträger daher an den Rechner an oder legt die SD-Karte in das entsprechende Lesegerät und gebt im Terminal lsblk ein. Das Kommando listet euch sämtliche am Rechner angeschlossene Datenträger auf. Anhand der Größe des Datenträgers lässt sich in der Regel die Geräte-ID erkennen. In meinem Beispiel bindet das System meinen 8 GByte großen USB-Stick unter sdc (also /dev/sdc in der vollständigen Syntax) ein. Seid ihr euch nicht sicher, dann zieht den zu kontrollierenden Datenträger ab und wiederholt lsblk. Fehlt sdc in der ausgegebenen Liste, dann habt ihr die richtige Kennung. Alternativ lässt sich die Kennung auch mit grafischen Tools wie der Laufwerksverwaltung von Gnome ermitteln.

$ lsblk
[...]
sdc           8:32   1   7,5G  0 disk 
├─sdc1        8:33   1   2,9G  0 part /run/media/toff/Ubuntu 21.10 amd64
├─sdc2        8:34   1   4,1M  0 part 
└─sdc3        8:35   1   300K  0 part 
[...]

Für die eigentliche Fehlersuche kommt nun das Kommando badblocks aus dem Paket e2fsprogs zum Einsatz, das zur Grundausstattung der üblichen Distributionen gehört. Es kann vorkommen, dass sich Badblocks erst einmal weigert, die Überprüfung zu starten, da das Laufwerk bereits vom System benutzt sei. In der Regel kommt das davon, dass das Betriebssystem den Datenträger automatisch einbindet, sobald ihr den USB-Stick ansteckt. Auf meinem System genügt das Antippen des Icons zum Aushängen des Laufwerks im Dateimanager nicht, ich muss die Geräte-ID des Laufwerks und der dazugehörigen Partitionen gezielt mit umount aushängen.

Achtung: An dieser Stelle muss ich eine Warnung schreiben: Beim Prüfen auf Fehler überschreibt Badblocks sämtliche Daten und Partitionen auf dem angegebenen Datenträger. Stellt daher auf jeden Fall sicher, dass ihr die richtige Geräte-ID an das Kommando übergibt und sichert vor der Aktion wichtige Daten vom betroffenen USB-Stick oder der SD-Speicherkarte. Im Fall der Fälle könnt die Daten nach der Fehlerüberprüfung nicht wiederherstellen.

$ sudo badblocks -wsv /dev/sdc
/dev/sdc wird offensichtlich vom System genutzt; es ist zu unsicher, Badblocks zu starten!
$ sudo umount /dev/sdc*
umount: /dev/sdc: nicht eingehängt.
umount: /dev/sdc2: nicht eingehängt.
umount: /dev/sdc3: nicht eingehängt.

Beim Aufruf von Badblocks übergebt ihr dem Kommando die Parameter -wsv sowie die Geräte-ID. Die Parameter weisen das Programm an, einen destruktiven Schreibtest auszuführen (-w), den Fortschritt anzuzeigen (-s) und generell mehr Informationen auszugeben (-v). Der ausführliche Test beschreibt jeden Block des Datenträgers viermal hintereinander mit unterschiedlichen Mustern (0xaa, 0x55, 0xff und 0x00). Je nach Geschwindigkeit und Kapazität müsst ihr dafür eine längere Zeit einplanen. Die Prüfung des von mir im Beispiel benutzten USB-Sticks nach dem USB-2.0-Standard und 8 GByte Kapazität benötigte über eine Stunde.

$ sudo badblocks -wsv /dev/sdc
Es wird getestet Mit Muster 0xaa:   0.00% erledigt, 0:00 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x55:   0.00% erledigt, 23:47 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0xff:   0.00% erledigt, 47:33 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt
Es wird getestet Mit Muster 0x00:   0.00% erledigt, 1:11:26 verstrichen. (0/0/0 Fehler) erledigt                                             
Lesen und Vergleichen:erledigt

Neben der destruktiven Prüfmethode unterstützt Badblocks einen zerstörungsfreien Lesen+Schreiben-Modus. Diesen aktiviert ihr mit dem Parameter -n anstatt von -w. In dieser Variante sichert Badblocks die Daten des geprüften Speicherblocks zuerst in den Arbeitsspeicher, überschreibt dann den Datenblock mit Zufallsdaten und prüft, ob die Daten korrekt geschrieben werden konnten. Abschließend schreibt Badblocks die Sicherung wieder auf den Datenträger zurück. Auf den ersten Blick erscheint die Prüfroutine schneller, da es nur einen Prüfdurchlauf gibt, in der Praxis brauch das Sichern und Zurückschreiben der bestehenden Daten allerdings wesentlich mehr Zeit. In meinem Beispiel anstatt nur etwas mehr als einer Stunde über 2,5 Stunden.

$ sudo badblocks -nsv /dev/sdc
Es wird nach defekten Blöcken im zerstörungsfreien Lesen+Schreiben-Modus gesucht
Von Block 0 bis 7812607
Es wird nach defekten Blöcken gesucht (zerstörungsfreier Lesen+Schreiben-Modus)
Es wird mit zufälligen Mustern getestet:  94.36% erledigt, 2:35:18 verstrichen. (0/0/0 Fehler)

Gefälschte USB-Sticks ermitteln

Einen Schritt weiter geht das Tool F3 oder etwas länger Fight Flash Fraud. Das Open-Source-Programm prüft ausführlich, ob ein Datenträger wirklich die Kapazität besitzt, die er vorgibt zu haben. Ein Thema, das leider immer noch aktuell ist, besonders wenn man super günstige Angebote aus dem Internet kauft. Um gefälschte USB-Sticks oder SD-Speicherkarten aufzudecken, müsst ihr das Programm aus dem Paketquellen installieren. Debian, Ubuntu, Fedora und Co. führen das Konsolenwerkzeug in den offiziellen Repositories, das Paket nennt sich in der Regel f3. Arch Linux führt das Programm nur im AUR, zur Installation braucht ihr daher einen AUR-Helper.

### Installation unter Arch Linux oder Manjaro:
$ yay -S f3
### Installation unter Debian, Ubuntu oder Raspberry Pi OS:
$ sudo apt install f3

Die Kommandos zum Prüfen von USB-Datenträgern lauten nun f3write, f3read und f3probe. Die ersten zwei Befehle müsst ihr in Kombination nutzen. Als Option übergebt ihr den Kommandos jeweils den Mountpunkt des Datenträgers. f3write schreibt nun so lange ein Gigabyte große Dateien auf den eingebundenen Datenträger, bis der Platz ausgeht. Anschließend prüft ihr mit f3read, ob die geschriebenen Daten auch wirklich wieder gelesen werden können. Falls es sich um einen gefälschten USB-Stick oder eine manipulierte SD-Speicherkarte handeln sollte, dann würde f3read korrupte Sektoren ausgeben. Bei dieser Prüfung bleiben alle Daten auf dem Datenträger erhalten, ihr müsst am Ende nur wieder die h2w-Dateien löschen, sonst habt ihr keinen Platz mehr auf dem Stick.

$ f3write /run/media/toff/291E-6F9C
[...]
Free space: 3.72 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK!
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 3.91 MB/s
$ f3read /run/media/toff/291E-6F9C
[...]
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1518736/        0/      0/      0

  Data OK: 3.72 GB (7810192 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 14.73 MB/s
$ ls -al /run/media/toff/291E-6F9C
insgesamt 3907596
drwxr-xr-x  3 toff toff       4096  1. Jan 1970   .
drwxr-x---+ 4 root root         80  7. Dez 16:27  ..
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:35  1.h2w
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:40  2.h2w
-rw-r--r--  1 toff toff 1073741824  7. Dez 18:44  3.h2w
-rw-r--r--  1 toff toff  777592832  7. Dez 18:47  4.h2w
[...]

Ein wenig schneller arbeitet f3probe --destructive. Die Option --destructive ist optional, die beschleunigt die Aktion jedoch ganz wesentlich. Bei diesem Test beschreibt F3 nur die nötigsten Sektoren und kümmert sich auch nicht um eine Datensicherung. Da die Probe direkt auf die Hardware zugreif, gebt ihr als Parameter nicht den Mountpunkt sondern die Geräte-ID (hier /dev/sdg) an. Der Test mit meinem 4 GByte großen USB-2.0-Stick dauert so nur ein wenig mehr als sieben Minuten. Habt aber bei dieser Prüfung wieder im Hinterkopf, dass die Routine sämtliche Datenblöcke auf dem Datenträger überschreibt.

$ f3probe --destructive --time-ops /dev/sdg
[...]
Good news: The device `/dev/sdg' is the real thing

Device geometry:
	         *Usable* size: 3.73 GB (7831552 blocks)
	        Announced size: 3.73 GB (7831552 blocks)
	                Module: 4.00 GB (2^32 Bytes)
	Approximate cache size: 0.00 Byte (0 blocks), need-reset=no
	   Physical block size: 512.00 Byte (2^9 Bytes)

Probe time: 7'17"
 Operation: total time / count = avg time
      Read: 2.73s / 4812 = 568us
     Write: 7'13" / 3637313 = 119us
     Reset: 1us / 1 = 1us

Sowohl Badblocks als auch F3 helfen beim Analysieren von Fehlern auf Datenträgern. Bei der Prüfung müsst ihr allerdings immer ein wenig Zeit mitbringen. Die ausführliche Analyse eines 8 GByte großen USB-Sticks kann schonmal zwei Stunden dauern, besonders wenn bei der Prüfung die Daten erhalten bleiben sollen und der USB-Stick nur mit dem langsamen USB-2.0-Protokoll arbeitet. Danach könnt ihr aber davon ausgehen, dass der USB-Stick oder die SD-Speicherkarte auch wirklich funktionieren und die Kapazität besitzen, die auf dem Aufdruck steht.

Sudoedit, das bessere sudo $editor

Das gilt nicht nur in einer grafischen Desktopumgebung, sondern auch für Editoren im Terminal. Wir rufen üblicherweise nano, vi, emacs und Co. mittels sudo nano /was/auch/immer komplett mit Root-Rechten auf. Dadurch müssen wir darauf vertrauen, dass sich der Editor nicht auf irgendeine Art und Weise missbrauchen lässt. Wenn man bedenkt, welche Funktionsfülle Vi oder Emacs mitbringen, birgt das Vorgehen durchaus ein Gefahrenpotential. Daher gibt es bereits seit 2004 mit sudoedit bzw. sudo -e ein Kommando, das dieses Problem umschifft.

$ sudo -e /etc/hosts
$ sudoedit /etc/hosts

Dabei kopiert Sudo die zu bearbeitende Datei erst einmal in ein temporäres Verzeichnis (unter Arch Linux nach /var/tmp), öffnet die Kopie dann im Kontext des Benutzers in den Editor und schiebt die temporäre Datei dann nach dem Schließen des Editors wieder an die ursprüngliche Stelle. Auf diesem Weg muss man den Editor selbst und damit alle mit angezogenen Bibliotheken nicht mehr mit Root-Rechten ausführen. Nur für das Kopieren der Dateien braucht es die administrativen Rechten.

$ VISUAL=gedit sudoedit /etc/hosts
$ EDITOR=nano sudoedit /etc/hosts

Mit den Umgebungsvariablen $VISUAL und $EDITOR lässt sich dem Kommando der gewünschte Editor mit auf den Weg geben, wobei $EDITOR für einen einfachen Editor wie etwa Nano oder Joe steht und $VISUAL mit einem Brocken wie Emacs oder Vi (oder grafischen Editoren wie Gedit oder Kate) belegt werden sollte — Sind beide Variablen definiert, zieht Sudo $VISUAL dem einfachen $EDITOR vor. Ich definiere „meine“ Editoren daher in der ~/.bashrc (den einfachen Editor) sowie in der ~/.xprofile (mit Gedit einen Editor in der GUI). Somit muss ich dann zum Bearbeiten einer Systemdatei nur noch sudoedit /foo/bar eingeben und öffne die Datei dann automatisch im „passenden“ Editor.

### Die Umgebungsvariablen $EDITOR und $Visual kann man beispielsweise
### über die ~/.bashrc oder 
$ grep EDITOR ~/.bashrc
export EDITOR=/usr/bin/joe
$ grep VISUAL ~/.xprofile
export VISUAL=/usr/bin/gedit
### Je nachdem ob man sich in einer grafischen Umgebung befindet, oder
### in einem virtuellen Terminal, startet sudoedit den Terminal-Editor
### Joe oder Gedit.
$ sudoedit /etc/hosts

Sudoedit gibt es nun schon seit 2004, aber kaum jemand nutzt diese Methode: Das Wiki der Ubuntuusers erwähnt das Kommando zum Beispiel mit keinem einzigen Wort und auch im Arch Wiki findet sich Sudoedit nur auf einer einzigen Unterseite — Damit ignorieren die in meinen Augen zwei besten Dokumentationen rund um Linux Sudoedit bisher fast komplett. In Sachen Root-Rechte in der grafischen Desktopumgebung hat mich allerdings ein aktueller Blogbeitrag von KDE-Entwickler Martin Grässlin auf etwas neues gebracht: Der Files-Dateimanager (aka Nautilus) beherrscht seit der Version 3.22 dank einer Neuerung in Gvfs (dem Gnome virtual file system) einen Administrator-Modus, der ähnlich wie Sudoeditor funktioniert.

Root-Rechte für Files aka Nautilus

Im Gnome-Dateimanager kann man ja mit [Strg]+[L] eine Adresszeile öffnen, über die sich Pfade eintippen lassen oder über die man durch Eingabe von smb://server/freigabe oder ssh://username@example.com Daten von entfernten Rechner direkt in den Dateimanger einbinden kann. Mithilfe von aktuellen Entwicklungen in Gvfs-admin und Polit gibt es nun aber auch eine Art Admin-Modus, diesen erreicht ihr über die Eingabe von admin:///pfad/zu/verzeichnis oder einfach nur admin:// ohne eine Pfadangabe. Über eine Maske fordert der Dateimanager danach eure Root-Rechte an und leitet euch entweder in das Wurzelverzeichnis des Systems oder den angegebenen Ordner weiter.

In diesem Modus könnt ihr beispielsweise nach /etc navigieren und dann die Hosts-Datei /etc/hosts in Gedit öffnen, bearbeiten und wieder abspeichern (mit abermaligen Eingabe eures Passworts). Dasselbe funktioniert mit allen anderen Konfigurationsdateien, die man mal schnell an die eigenen Wünsche anpassen möchte. Ihr könnt auch Verzeichnisse oder Dateien in geschützten Ordnern wie /, /etc oder /usr/local/bin anlegen, diese dann verschieben, wieder löschen oder die Benutzerrechte ändern. Sinnlos walten und schalten lässt euch Files jedoch in der Regel nicht: Dateien und Ordner, die dem Root-User gehören, die User der Root-Gruppe aber nur lesen und/oder ausführen dürfen (also Dateien und Ordner mit der Zuordnung root:root und den Rechten 644 oder 755) erscheinen mit einem Schloss-Symbol. Diese lassen sich dann beispielsweise nicht löschen oder ausschneiden.

In Sachen Root-Rechte in KDE wird sich demnächst einiges ändern: Martin hat in seinem Posting angekündigt, dass die KDE-Editoren Kate und Kwrite sich in Zukunft nicht mehr direkt mit Root-Rechten öffnen lassen. Stattdessen informieren die Programme, wie der User die gewünschte Datei mittels sudoedit in den ohne Root-Rechte gestarteten Browser bekommt. Dies wird mit Sicherheit den Workflow zahlreicher User beeinträchtigen (und wie die Kommentare schon zeigen, für Unmut in der KDE-Community sorgen), allerdings ist dieser Schritt zum Beispiel in Bezug auf Wayland sowieso überfällig.

Today I pushed a change for Kate and KWrite which does no longer allow to be run as root. Instead it educates the user about how to do the same with sudoedit.

Now I understand that this will break the workflow for some users. But with a minor adjustment to your workflow you get the same. In fact it will be better, because the Kate you start is able to pick up your configured styling. And it will also work on Wayland. And most importantly it will be secure.

Langfristig wäre dann das Ziel, dass KIO und PolicyKit die eigentliche Arbeit übernehmen. So könnte man die gewünschten Dateien in den Editor öffnen, dann über Polkit „beweisen“, dass man Root-Rechte auf dem System hat, und dann die gewünschten Aktionen direkt über den Dateimanager oder den Editor durchführen. Das Ganze würde transparent im Hintergrund funktionieren, ohne dass man sich verrenken müsste. Wie das Ganze am Ende aussieht, gibt der Blog-Artikel von Martin noch nicht her. Im KDE-Bugtracker gibt es jedoch bereits schon einen entsprechenden Eintrag. Dieser stammt allerdings bereits von 2009 und bekommt hoffentlich durch die aktuelle Entwicklung ein wenig Leben eingehaucht.

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.

Die Seite listet zu jeder Version eines betroffenen Pakets die entsprechenden Meldungen mitsamt dem Gefährdungsgrad sowie dem aktuellen Status auf und zeigt, in welcher Version das Paket bereits gefixed wurde. Oft gibt es ein Arch Linux Security Advisory aka ASA mit zusätzlichen Informationen zur Sicherheitsschwachstelle in der Spalte ganz rechts. Sämtliche Meldungen sind miteinander verlinkt, sodass man sich schnell einen Überblick verschaffen kann.

Wer nun ein hochgefährdetes System betreibt (oder einfach so auf dem Laufenden bleiben möchte), sollte diese Meldungen fortlaufend im Auge behalten, allerdings gibt es noch keinen RSS-Feed der Seite — somit fällt es schwer neue Einträge zu verfolgen. Stattdessen kann man jedoch aber auch ein bestehendes System nach Paketen mit einer entsprechenden Warnung durchsuchen. Dazu dient arch-audit aus dem AUR, das ab der Version 0.1.6 auf die Einträge im Security Tracker zurückgreift.

$ pacaur -S arch-audit
$ arch-audit
Package lib32-libtiff is affected by ["CVE-2015-7554"]. VULNERABLE!
Package libusbmuxd is affected by ["CVE-2016-5104"]. VULNERABLE!
Package openssh is affected by ["CVE-2016-10012", "CVE-2016-10011", "CVE-2016-10010", "CVE-2016-10009"]. Update to 7.4p1-1!
Package php is affected by ["CVE-2016-9936", "CVE-2016-9934", "CVE-2016-9933"]. Update to 7.1.0-2!
Package libwmf is affected by ["CVE-2016-9011", "CVE-2015-4696", "CVE-2015-4695", "CVE-2015-4588", "CVE-2015-0848", "CVE-2009-3546", "CVE-2009-1364", "CVE-2007-3477", "CVE-2007-3473", "CVE-2007-3472", "CVE-2007-2756", "CVE-2007-0455", "CVE-2006-3376"]. VULNERABLE!
Package openjpeg2 is affected by ["CVE-2016-9118", "CVE-2016-9117", "CVE-2016-9116", "CVE-2016-9115", "CVE-2016-9114", "CVE-2016-9113"]. VULNERABLE!
Package libimobiledevice is affected by ["CVE-2016-5104"]. VULNERABLE!
Package openssl is affected by ["CVE-2016-7055"]. VULNERABLE!
Package bzip2 is affected by ["CVE-2016-3189"]. VULNERABLE!
Package lib32-openssl is affected by ["CVE-2016-7055"]. VULNERABLE!
Package libtiff is affected by ["CVE-2015-7554"]. VULNERABLE!
Package jasper is affected by ["CVE-2016-8886"]. VULNERABLE!
Package gst-plugins-bad is affected by ["CVE-2016-9447", "CVE-2016-9446", "CVE-2016-9445"]. VULNERABLE!
$ arch-audit --upgradable
Package php is affected by ["CVE-2016-9936", "CVE-2016-9934", "CVE-2016-9933"]. Update to 7.1.0-2!
Package openssh is affected by ["CVE-2016-10012", "CVE-2016-10011", "CVE-2016-10010", "CVE-2016-10009"]. Update to 7.4p1-1!

Das Ausführen von arch-audit ohne irgendwelche Schalter gibt sämtliche auf dem System Pakete aus, zu denen eine Sicherheitswarnung herausgegeben wurde. Mit dem Schalter --upgradable reduziert man die Ausgabe auf Pakete, zu denen es bereits ein Update in den Paketquellen von Arch Linux gibt. Ein pacman -Syu spielt diese Updates allerdings nicht zwangsläufig sofort ein, da frisch veröffentlichte Updates in der Regel erst einmal in den Testing-Quellen stecken und erst noch freigegeben werden müssen.

Kleiner Exkurs zu PwdHash

Viele User nutzen aus Bequemlichkeit für verschiedene Webseiten im Netz immer wieder dieselbe E-Mail-Adresse und dasselbe Passwort. Wird nun die Datenbank eines Dienstes gehackt, kann sich der Angreifer mit den Zugangsdaten des Users bei anderen Diensten einloggen. In der Praxis werden die Passwörter zwar nicht im Klartext abgespeichert. Doch „schlechte“ Passwörter lassen sich schnell per Brute-Force-Angriff und Rainbow-Tables cracken. Pwdhash ist nun ein simples Verfahren, dass ausgehend aus der Domain des Dienstes und einem Masterpasswort ein individuelles Passwort für jede Webseite errechnet.

Aus der Domain „beispiel.de“ und dem Passwort „ganzgeheim“ wird so am Ende das Kennwort „ISXAKd2f3Bvq“. Ändert man die Domain oder das Passwort, ergibt sich automatisch ein neues Pwdhash-Passwort. Erweiterungen für Chrome und Firefox binden Pwdhash nun quasi nahtlos in die Eingabe von Passwörtern im Browser ein, sodass man kaum mehr Aufwand mit den sicheren Passwörtern hat. Weiterführende Informationen zu Pwdhash findet ihr in einem älteren Artikel von mir hier im Blog. In der Praxis hat sich seit 2006 eigentlich nichts geändert. Lediglich eine Erweiterung für Chrome/Chromium ist hinzugekommen.

Vortrag: Cracking PwdHash

Im Zuge meiner Recherche ist mir zudem der Vortrag „Cracking PwdHash: A Bruteforce Attack on Client-Side Password Hashing“ der an der University of Cambridge angesiedelten Forscher David Llewellyn-Jones and Graham Rymer untergekommen, den die beiden Anfang Dezember im Rahmen der Konferenz Passwords 2016 in Bochum gehalten haben. In knapp 40 Minuten legen die Forscher dar, wie sie am Beispiel von drei umfangreichen Leaks der letzten Jahre Pwdhash-gesicherte Passwörter cracken konnten — ohne dass Pwdhash einen wirklichen Schutz bot. Die Schwachstellen von PwdHash liegen zum einen am Verfahren selbst und zum anderen jedoch auch am User.

Pwdhash nutzt zum Erstellen der gehashten Passwörter lediglich HMAC-MD5 und verzichtet auf ein zusätzliches Salt. Zudem ist das vom User eingegebene Passwort auf real 22 Stellen limitiert und ein paar Eigenarten (etwa dass Passwörter mit einem Kleinbuchstaben am Anfang in einen Hash mit großen Anfangsbuchstaben resultierten, vice versa) erleichtern die Arbeit. Baut man in einen effektiven Passwort-Cracker wie Hashcat nun eine Routine ein, die die per Wörterbuch generierten Passwörter durch Pwdhash jagt, dann lassen sich auf einer nur 65 Cent/h teuren Amazon-EC2-Instanz stolze 2400 MH/s (Million Hashes pro Sekunde) errechnen und somit zu einfach gestrickte Masterpasswörter der User cracken.

Llewellyn-Jones and Rymer haben daher eine erweiterte Version von Pwdhash vorgestellt, die diese Schwachstellen behebt. Der Code ist auf Github zu finden, eine Demo-Implementation analog zur „original“ Pwdhash-Seite gibt es ebenfalls. Der Proof of Concept nutzt PBKDF2-SHA256, erlaubt Passwörter mit mehr als 22 Zeichen und lässt den User ein Salz definieren (das man natürlich auch immer wieder eingeben müsste, was sich jedoch durch Einsatz einer Browsererweiterung mit einer entsprechenden Option vermeiden ließe).

Bis dieser Ansatz bei Pwdhash (und den entsprechenden Browser-Erweiterungen) zum Einsatz kommt — wenn überhaupt — sollte man daher sehr genau darauf achten, dass man ein ordentliches Masterpasswort verwendet. Wer password oder qwertzuiop in Pwdhash als Masterpasswort eingibt, ist nicht sicherer unterwegs, nur weil das an beispielsweise google.de übermittelte Passwort MW7wFvVQST heißt.

Zudem sollte man sich öfters mal auf Have i been pwned oder kurz HIBP umsehen, ob die eigene E-Mail-Adresse in einem öffentlich gewordenen Hack auftaucht. Die Seite hat die Datenbanken von 168 (Stand heute) Webseitenleaks indexiert, sodass man sehr leicht nachprüfen kann, ob die eigene E-Mail-Adresse ins Visier von Hackern geraten sein könnte. Wer möchte, kann seine E-Mail-Adresse auch auf der Webseite registrieren und erhält automatisch eine E-Mail, sobald die Adresse in einem von HIBP indexierten Leak auftaucht.

$ sudo arp-scan --localnet | grep Raspberry
192.168.0.100  b8:27:eb:76:1e:16  Raspberry Pi Foundation
192.168.0.101  b8:27:eb:e4:e1:30  Raspberry Pi Foundation

Bislang war auf den Raspian-Images der SSH-Server von Haus aus aktiv. Somit ließ sich der Raspberry Pi „headless“ aufsetzen. Man brauchte also weder Maus, Tastatur oder einen Monitor um das System des RasPis einzurichten, was die Installation eines RasPi-Servers ungemein vereinfacht. In Anbetracht der IT-Sicherheits-GAUs der letzten Tage und Wochen, macht die Raspberry Pi Foundation mit dieser Praxis nun Schluss: Seit Raspbian 2016-11-25 muss man den SSH-Server aktivieren. Kann man den RasPi direkt bedienen, ist das schnell geschehen, einen Headless-RasPi muss man jedoch gezielt vorbereiten.

SSH auf dem Raspberry Pi aktivieren

Wer auf seinen Raspberry Pi direkt zugreifen kann, weil neben Tastatur/Maus auch noch ein Monitor an dem Minirechner angeschlossen sind, muss zum Aktivieren von SSH keine großen Klimmzüge machen. In der Anwendung Preferences | Raspberry Pi Configuration findet sich im Reiter Interfaces ein Schalter zum Aktivieren des SSH-Servers. Diesen ist weiter von Haus aus installiert, man muss hier nun lediglich den Schalter auf Enabled stellen und den Dialog mit OK beenden.

Alternativ ruft man das konsolenbasierte Raspberry-Pi-Konfigurationswerkzeug mittels sudo raspi-config in einem Terminal auf und schaltet dort unter dem Eintrag 7 Advanced Options | A4 SSH die entsprechende Option ein. Dies funktioniert dann selbstverständlich auch mit dem Light-Image von Raspbian, das auf eine grafische Desktopumgebung verzichtet. Einen Neustart danach braucht es nicht zwingend, man kann man sich sofort wieder per SSH einloggen.

Dabei findet man gleich eine weitere Neuerung. Solange man das Passwort des Standardnutzers „pi“ nicht abändert, es also bei „raspberry“ belässt, bekommt man bei jedem Einloggen einen Hinweis auf den Schirm, dass man dieses doch bitte schnellstmöglichst tun solle. Dazu genügt es sich ganz normal einzuloggen und dann mit dem Kommando passwd das Kennwort abzuändern. Linux-typisch zeigt das System bei dieser Aktion keinerlei Sternchen oder andere Platzhalter an. Alternativ funktioniert das Ändern des Passworts auch über RasPi-Config.

SSH auf einem Headless-RasPi

Möchte man nun aber gar nicht erst einen Monitor und Eingabegeräte an den Raspberry Pi anschließen, dann steht man mit dem neusten Raspbian vor verschlossenen Türen: Konnte man sich früher per SSH direkt auf dem RasPi einloggen, heißt es jetzt nur noch ssh: connect to host 192.168.111.100 port 22: Connection refused und nichts geht mehr. Nun beißt sich die Katze natürlich in den Schwanz: Ohne SSH kein SSH. Doch auch für diesen Fall haben die Entwickler von Raspbian eine Lösung erdacht.

Damit Raspbian von Haus aus SSH aktiviert, schreibt man die Image-Datei wie gewohnt auf die SD-Karte. Nach Abschluss der Aktion nehmt ihr die Karte nun nicht sofort aus dem Kartenleser, sondern öffnet die /boot-Partition des Raspbian-Systems in einem Dateimanager eurer Wahl und erstellt dort eine leere Datei mit dem Namen ssh. Da mit dem FAT-Dateisystem formatiert wurde, funktioniert dies mit allen gängigen Betriebssystem, also mit Linux, MacOS X und auch mit dem Windows Explorer unter Microsoft Windows.

Ich persönlich mache es mir unter Linux ein wenig leichter: Anstatt einen Dateimanager zu bemühen, schreibe ich das Rapbian-Image wie gewohnt mit dd auf die Speicherkarte (Achtung: Bitte Namen und bei Bedarf Pfad der Image-Datei anpassen, sowie den Pfad /dev/sdd zur Speicherkarte ändern) und lege die Datei dann mit touch an. Wobei man auch hier wieder den Pfad zum Mountpunkt der /boot-Partition anpassen muss. Arch bindet externe Medien unter /run/media/benutzername ein. Das $(whoami) sorgt dafür, dass dieser automatisch aufgelöst wird.

$ sudo dd if=2016-11-25-raspbian-jessie.img of=/dev/sdd bs=512; sync
$ touch /run/media/$(whoami)/boot/ssh

In Zukunft wird es also ein klein wenig komplizierter einen Raspberry Pi ohne Monitor und Tastatur entsprechend aufzusetzen. Das Plus an Sicherheit ist es in meinen Augen jedoch wert, ich möchte nicht von einem „Raspberry-Pi-Botnet“ aus der Presse erfahren. Zahlreiche RasPi-User wussten wahrscheinlich gar nicht, dass das System aus dem Netz heraus über SSH zu erreichen war. Wurde dann nicht einmal das Standard-Passwort geändert, war das RasPi-System offen wie ein Scheunentor.

Synology DSM 6.0 unterstützt Let’s Encrypt

Nun lässt sich Synology wohl nicht lange bitten und rollt Let’s Encrypt in der kommenden Version der DSM-Software aus. Mit der aktuell vorliegenden Version DSM 6.0 Beta 2 des Betriebssystems lässt sich das Ganze bereits testen — bis zum endgültigen Release wird sich an dieser Stelle wohl auch nicht mehr viel ändern. Wer nun Let’s Encrypt zusammen mit seiner Diskstation nutzen möchte, der muss den Port 80 von seinem Router auf die Diskstation weiterleiten. Auf einer Fritzbox etwa könnt ihr diese Portweiterleitung unter Internet | Freigaben | Portfreigaben einrichten. Ihr braucht Port 80/TCP (http) für den Let’s Encrypt-Client und für später dann selbstverständlich auch Port 443/TCP (https) für die verschlüsselten Daten.

Danach öffnet ihr das Webfrontend eures Synology-Systems und geht in die Systemsteuerung. Dort wählt ihr dann Sicherheit | Zertifikate an. Die Liste ist selbstverständlich anfangs noch leer, mit einem Klick auf Hinzufügen startet ihr hier das Erzeugen eures Let’s Encrpyt-Zertifikats. Der Assistent fragt euch im ersten Schritt ob ihr ein Neues Zertifikat hinzufügen möchtet oder ob ihr ein Vorhandenes Zertifikat ersetzen möchtet — in meinem Fall gab es bereits eines, im Endeffekt unterscheidet sich das weitere Vorgehen jedoch nicht.

Let’s Encrpyt auf Synology einrichten

Der mit DSM 6.0 überarbeitete Zertifikats-Assistent bietet euch nun den Punkt Zertifikat von Let’s Encrypt abrufen. Dieser Menüpunkt startet nun, genauso wie auf einem „richtigen“ Webserver, den Let’s Encrpyt-Client. Dieser erzeugt die Schlüsselt, authentifiziert euch automatisch gegenüber Let’s Encrpyt und spielt dann abschließend die erhaltenen Zertifikate in das System ein. Mehr als ein paar Klicks braucht die Installation der Let’s Encrpyt-Zertifikate daher also nicht mehr. Das umständlich Basteln und hier und her Schieben der Daten fällt komplett weg.

Am Ende sollte euer Browser mit einem grünen Schloss-Symbol in der Adresszeile signalisieren, dass mit der Verschlüsselung eures Synology-NAS alles stimmt. Das Zertifikat kommt nun automatisch nicht nur beim Aufruf der Weboberfläche zum Einsatz, sondern unter anderem auch bei FTP- oder WebDAV-Verbindung. So könnt ihr super einfach von unterwegs — die meisten Dateimanager unter Linux unterstützen ja Verbindungen zu entfernten Systemen — auf die Daten eures NAS-Systems zugreifen. Damit dies allerdings ohne Warnungen funktioniert, müsst ihr wahrscheinlich noch das Stammzertifikat von Let’s Encrypt auf eurem Linux-System installieren.

In der Praxis fällt mir nun auf, dass die Let’s-Encrypt-Zertifikate zwar von den gängigen Browsern wie Chrome oder Firefox akzeptiert werden, das System selbst kommt mit den Zertifikaten jedoch noch nicht zurecht, da dieses das Let’s-Encrypt-Stammzertifikat in der Regel noch nicht kennt. Dies spürt man beispielsweise bei verschlüsselten WebDAV-Verbindungen, die man über den Dateimanager aufbauen möchte. Unter Gnome meldet Files (aka Nautilus) etwa recht wortkarg „Unbekannte Fehlermeldung: HTTP-Fehler: Nicht akzeptables TLS-Zertifikat“. Aufgrund eines uralten Bugs aus dem Jahr 2007 geht es danach auch nicht mehr weiter. Mit einem aktuellen Gnome-System lässt sich ein WebDAV-Share nicht verschlüsselt einbinden, egal ob Let’s Encrypt oder ein selbst-signiertes Zertifikat.

Das Geschehen kann man auch recht schön auf der Kommandozeile nachvollziehen: Nautilus macht nichts anderes als die WebDAV-Freigabe über das Gnome Virtual File System (aka GVFS) einzubinden, das entsprechende Kommando dafür lautet schlicht gvfs-mount gefolgt von der URL des entsprechenden Dienstes. Auch hier ist das Ergebnis wieder, dass GVFS den Verbindungsaufbau trotz explizierter Anweisung verweigert. Dasselbe würde übrigens auch mit einem selbst-signierten Zertifikat passieren, es sind also nicht nur Anwender von Let’s Encrypt von diesem Problem betroffen.

$ gvfs-mount davs://home.example.com:5006
Die Identität der Gegenseite kann nicht bestätigt werden:
	Die Zertifikats-Ausgabestelle ist unbekannt

Certificate information:
	Identity: home.example.com
	Verified by: Let's Encrypt Authority X1
	Expires: 02.03.2016
	Fingerprint (SHA1): 93 AD D4 91 ED 57 93 BF 53 D9 4D C2 4D D5 2D 39 1D 83 9C 95

Sind Sie absolut sicher, dass Sie fortsetzen wollen?
[1] Ja
[2] Nein
Choice: j
Fehler beim Einhängen des Ortes: HTTP-Fehler: Nicht akzeptables TLS-Zertifikat

Möchtet ihr nun nicht darauf verzichten euer NAS per verschlüsseltem WebDAV einzubinden, müsst ihr die Let’s-Encrypt-Stammzertifikate in eurem System installieren. Ihr könnt das jetzt manuell machen, oder ihr wartet bis der Distributor eurer Linux-Installation dies für euch erledigt — was je nach Distribution ein ganzes Weilchen brauchen kann. Mit den folgenden Kommandos ladet ihr die Let’s-Encrypt-Stammzertifikate aus dem Netz und installiert diese im System. Ein selbst-erstelltes Zertifikat ließe sich auf dem selben Weg einspielen, gebt bei Bedarf einfach den vollständigen Pfad zur Datei an.

$ wget https://letsencrypt.org/certs/lets-encrypt-x1-cross-signed.pem
$ wget https://letsencrypt.org/certs/lets-encrypt-x2-cross-signed.pem
$ sudo trust anchor lets-encrypt-x1-cross-signed.pem
$ sudo trust anchor lets-encrypt-x2-cross-signed.pem

Zur Kontrolle könnt ihr euch danach mit trust list die im System verfügbaren Zertifikate ausgeben lassen. Mit ein bisschen Grep-Magie sollte das Kommando dann nur die zwei neuen Let’s-Encrypt-Zertifikate ausspucken — wenn nicht, dann hat irgendwas mit der Installation der Zertifikate nicht funktioniert. Anschließend öffnet ihr wieder Nautilus und gebt abermals davs://home.example.com:port als URL in die Adresszeile ein. Diesmal sollte der Dateimanager das Zertifikat anstandslos akzeptieren und die verschlüsselte Verbindung zum NAS anstandslos aufbauen. Was ich hier mit Nautilus unter Gnome mache, sollte eigentlich auch mit den Dateimanagern anderer Desktopumgebungen funktionieren, also etwa bei KDE und Dolphin.

$ trust list | grep -C 2 "Let's Encrypt"
pkcs11:id=%a8%4a%6a%63%04%7d%dd%ba%e6%d1%39%b7%a6%45%65%ef%f3%a8%ec%a1;type=cert
    type: certificate
    label: Let's Encrypt Authority X1
    trust: anchor
    category: authority
--
pkcs11:id=%c5%b1%ab%4e%4c%b1%cd%64%30%93%7e%c1%84%99%05%ab%e6%03%e2%25;type=cert
    type: certificate
    label: Let's Encrypt Authority X2
    trust: anchor
    category: authority

Solltet ihr die Stammzertifikate (oder ein entsprechend selbst-signiertes) später einmal wieder vom System löschen wollen, dann hängt an das Kommando trust anchor einfach noch ein --remove mit dem Pfad zur Zertifikat-Datei oder der entsprechenden PKCS-Kennung an. Achtet dabei bitte darauf kein wirklich wichtiges Zertifikat zu löschen, sonst weigert sich beispielsweise die Paketverwaltung mit den Paketquellen zu sprechen oder es lassen sich viele verschlüsselte Webseiten nicht mehr öffnen.

$ trust anchor --remove /pfad/zu/zertifikat.crt
$ trust anchor --remove "pkcs11:id=%AA%BB%CC%DD%EE;object-type=cert"

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.