Security – RRZK – Regionales Rechenzentrum

Das sichere Aufbewahren von Passwörtern – Einrichtung und Nutzung von KeePassXC

Vorwort

Bitte beachten Sie, dass das RRZK bzw. der RRZK-Helpdesk zur Aufbewahrung von Passwörtern mit KeePassXC keinen Support leisten kann. Die Verwendung von KeePassXC stellt keine Nutzungsempfehlung des RRZK dar, sondern die folgenden Ausführungen sind lediglich als persönlicher Erfahrungsbericht zu verstehen.

Warum ein Passwortmanager?

Durch immer neue Arten von Trojanern, Sicherheitslecks und Datendiebstahl wird die Bedeutung von Passwörtern und der Umgang damit immer wichtiger. Schaut man sich die beliebtesten Passwörter des Jahres 2018[1] an, so wird verständlich, wieso auch ohne tiefgreifendes IT-Knowhow ein Account durch Raten und Ausprobieren vergleichsweise einfach zu „hacken“ ist.

Dabei geht es nicht nur um die Einfachheit und Beliebtheit eines Passworts, sondern auch um dessen gleichzeitige Verwendung für mehrere Dienste: Mit einer E-Mail-Adresse/einem bekannten Benutzernamen und einem erratenen oder gehackten Passwort gelangen Kriminelle so bspw. nicht nur an ein E-Mailpostfach, sondern ebenfalls an die Anmeldedaten für Netflix, das Online-Banking und das Online-Portal der Krankenkasse. Die mittlerweile allseits bekannte Schlussfolgerung ist naheliegend: Für jeden Dienst sollte ein unterschiedliches und darüber hinaus ausreichend sicheres Passwort gewählt werden. Dies ist auch die offizielle Empfehlung des Bundesamtes für Sicherheit in der Informationstechnik (BSI). Seine bisherige Empfehlung Passwörter regelmäßig zu ändern, hat das BSI inzwischen zurückgenommen.

In Zeiten, in denen viele Menschen dutzende verschiedene Dienste im Internet benutzen, wird es jedoch immer schwieriger, sich alle Zugangsdaten zu merken bzw. diese verlässlich zu speichern. Das Anlegen einer Liste mit Passwörtern in einem Word- oder Exceldokument eignet sich aufgrund der fehlenden bzw. unzureichenden Verschlüsselungsmöglichkeiten ebenso nicht wie bei allen anderen Methoden, bei denen der Zugriff nicht ausreichend geschützt werden kann. Ein klassisches Notizbuch mit handschriftlich notierten Passwörtern scheidet ebenfalls aus, denn bei Verlust sind nicht nur alle Zugangsdaten weg, sondern können unter Umständen sogar in fremde Hände gelangen.

Es bietet sich daher an, einen der zahlreichen Passwortmanager zu verwenden, die es mittlerweile gibt. Ein Passwortmanager ist ein Programm bzw. eine Datenbank, in der die Zugangsdaten für unendlich viele Dienste verschlüsselt und damit sicher gespeichert werden können. In der Grundfunktion wird diese Datenbank mit einem Master-Passwort gesichert, welches im Anschluss das einzige ist, das sich die Nutzer*innen für den Zugang zur Passwortdatenbank merken bzw. aufbewahren müssen. Falls dieses Passwort jemals vergessen sollte, ist der Zugang auf die Datenbank unwiederbringlich verloren und der Zugriff auf die gespeicherten Zugangsdaten somit für immer verschlossen. Es bietet sich daher an, das Passwort einem sicheren Ort, z.B. einem Safe oder einem Bankschließfach, aufzubewahren.

In diesem Artikel soll das Programm „KeePassXC“ vorgestellt werden. Bei zahlreichen unabhängigen Tests zählte es bislang zu den am besten bewerteten Passwortmanagern und ist darüber hinaus als Open-Source-Software kostenlos. Zudem ist es für die gängigsten Betriebssysteme (Windows, Linux und macOS; für Android und iOS gibt kompatible Programme) verfügbar.

Bitte lassen Sie nicht verwirren lassen: Unter dem Namen KeePass gibt es mittlerweile zahlreiche unterschiedliche Versionen, so zum Beispiel KeePassX oder KeePass2. Die hier vorgestellte Version KeePassXC[2] ist im Gegensatz zu den anderen Versionen unter Windows, Linux und macOS nutzbar und hat viele sinnvolle und bereits integrierte Features, welche in den anderen Versionen händisch nachinstalliert werden müssen.

Speicherort der Datenbank

Wie schon erläutert werden die Zugangsdaten im Passwortmanager in einer verschlüsselten Datenbank gespeichert. Wählen Sie als Speicherort für diese Datenbank die lokale Festplatte, bietet dies zunächst keinen größeren Mehrwert. Denn sobald Sie den Computer nicht bei sich haben, können Sie unterwegs auch nicht auf die Zugangsdaten zugreifen. Auch wenn Sie die Passwortdatenbank auf ihrem Handy mit sich tragen würden, könnte sie bei Verlust des Handys verloren gehen. Es bietet sich daher an, die Passwort-Datenbank in einer Cloud abzuspeichern. Somit können Sie nicht nur von überall auf Ihre Passwörter zugreifen, Sie müssen sich auch keine Gedanken über ein Backup Ihrer Passwort-Datenbank machen. Als Angehörige/r der Universität zu Köln können Sie hierzu sciebo[3] verwenden. Im Gegensatz zu den anderen gängigen Cloud-Diensten wie bspw. iCloud, OneDrive, Dropbox befinden sich Ihre Daten auf einem von der WWU Münster verwalteten und DGSVO-konformen Server in NRW.

Einrichtung von KeePassXC

Im Folgenden wird die Einrichtung von KeePassXC und sciebo beschrieben. Die Anleitung[4] orientiert sich dabei an der Windows-Version, gilt aber ebenso mit minimalen Abweichungen für Linux und MacOS.

Installieren Sie zunächst den sciebo-Client[5] und richten diesen mit Ihrem sciebo-Account ein.
Laden Sie KeePassXC von der Internetseite[6] für Ihr jeweiliges Betriebssystem herunter und installieren Sie es anschließend (mit den Standardvoreinstellungen). Alternativ ist auch die Nutzung einer Portable-Version möglich, welche Sie nicht installieren müssen.
Klicken Sie nun auf „Neue Datenbank erstellen“ (oder alternativ im Menü unter „Datenbank“ auf „Neue Datenbank“).
Vergeben Sie nun einen Namen für Ihre Passwort-Datenbank („Datenbankname“). Optional können Sie noch eine Beschreibung hinzufügen.
Lassen Sie bei den „Verschlüsselungseinstellungen“ die Werte unverändert und klicken auf „weiter“.
Vergeben Sie nun bei „Datenbank-Anmeldedaten“ ein neues Master-Passwort, welches besonders sicher sein sollte. Verwenden Sie eine hinreichende Anzahl der Zeichen, Groß- und Kleinschreibung sowie Ziffern und Sonderzeichen. Folgen Sie hierfür bspw. den Hinweisen des Bundesamtes für Sicherheit in der Informationstechnik BSI https://www.bsi-fuer-buerger.de/BSIFB/DE/Empfehlungen/Passwoerter/passwoerter_node.html.
Wie bereits erwähnt: Wenn Sie das Master-Passwort jemals vergessen sollten, ist der Zugriff auf Ihre Passwörter unwiederbringlich verloren!

Durch Klick auf das Würfel-Symbol erhalten Sie alternativ auch die Möglichkeit, sich ein sicheres Passwort per Zufall generieren zu lassen.

Sollten Sie einen Yubikey[7] besitzen, haben Sie sogar die Möglichkeit, ein sehr langes, mit vielen Sonderzeichen versehenes und „nicht sprechendes“ Passwort nicht händisch eingeben zu müssen, sondern dies per Knopfdruck den Yubikey erledigen lassen (folgen Sie hierfür der Anleitung „Static Password Mode“[8]).

Über „Zusätzlichen Schutz hinzufügen“ können Sie die Datenbank zusätzlich zum Passwort noch durch weitere Sicherheitsmechanismen schützen, siehe Exkurs „zusätzlicher Schutz“.
Nach Klick auf „Fertig“ ist Ihre Datenbank erstellt und Sie müssen diese noch abspeichern. Wählen Sie als Dateispeicherort nun einen Ordner aus, der von sciebo synchronisiert wird. Damit wird Ihre Datenbank auf allen Endgeräten sowie auf dem sciebo-Server auf dem aktuellen Stand gehalten.[9]
Nun können Sie die Datenbank mit Einträgen befüllen und Ihre Zugangsdaten eintragen. Durch das Anlegen von „Gruppen“ können Sie diese thematisch gliedern.

Sobald Ihre Datenbankdatei per sciebo synchronisiert wurde, können Sie auf diese auch von anderen Computern/Endgeräten zugreifen. Für Windows, MacOS und Linux gilt: Installieren Sie hierzu jeweils zunächst den sciebo-Client sowie KeePassXC.

Exkurs: „zusätzlicher Schutz“

Es ist festzuhalten, dass Sie den Zugang zu Ihren Passwörtern bislang zweifach gesichert haben: mit den Zugangsdaten zu sciebo sowie durch das Datenbank-Master-Passwort. Falls Sie also in KeePassXC die Datenbank noch zusätzlich mit einem Sicherheitsmechanismus versehen, erhöht sich die Zahl der Schranken auf drei (oder gar vier). Ob Sie die Passwortdatenbank zusätzlich–schützen sollten, hängt von Ihrem eigenen Schutzbedürfnis ab, ggf. auch von den zu speichernden Zugangsdaten in Ihrer Datenbank. Sie haben hierzu verschiedene Alternativen, die Nutzung einer Schlüsseldatei oder eines Yubikeys.

Durch das Generieren einer „Schlüsseldatei“ erhalten Sie eine Datei, welche fortwährend zusätzlich zur Eingabe eines Passworts für das Öffnen der Datenbank erforderlich ist. Beim Erstellen der Datei wird ein Zahlencode erzeugt, der ein Unikat darstellt bzw. nahezu unmöglich zu erraten ist. Stellen Sie sich die Schlüsseldatei einfach wie eine Schlüsselkarte vor, wie sie bspw. zum Öffnen der Zimmertür in Hotels heutzutage üblich ist. Immer wenn Sie das Passwort zum Öffnen der Datenbank eingeben, müssen Sie parallel auch die Schlüsseldatei vorzeigen. Dementsprechend müssen Sie diese immerzu „mit dabei haben“, falls Sie die Datenbank unterwegs öffnen möchten.

Damit stellt sich die Frage, wo die Schlüsseldatei aufbewahrt werden kann:

Falls Sie ausschließlich Desktop-Computer oder Laptops verwenden, bietet es sich an, die Datei auf einen USB-Stick zu speichern, den Sie immer mit sich herumtragen (bspw. am Schlüsselbund, im Geldbeutel). Die Schlüsseldatei befindet sich somit nie dauerhaft auf einem der Computer selbst. Auf mobilen Endgeräten kann der USB-Stick jedoch nicht verwendet werden.
Sie können die Schlüsseldatei auch direkt auf die entsprechenden Endgeräte kopieren. Sie ist dann aber einer potentiellen Gefahr ausgesetzt, wenn sich jemand Zugriff auf das mobile Endgerät verschafft. Durch Verschlüsselung des Datenträgers sowie durch das Einrichten eines Zugriffsschutz in Form eines Passworts (Windows, MacOS, Linux), einer PIN oder eines Fingerabdrucks usw. (Android, iOS) kann dieses Risiko wiederum minimiert werden.

Falls jemand Unerwünschtes in Besitz der Schlüsseldatei kommen sollte, sei bemerkt, dass diese ohne das Passwort und ohne Zugriff auf die Datenbank (die Cloud) wertlos ist. Wie beim Passwort gilt, dass die Schlüsseldatei bei Verlust nicht wiederhergestellt werden kann; der Zugriff auf die Datenbank wäre – auch mit dem richtigen Passwort – unwiderruflich verloren. Es bietet sich daher erneut an, die Schlüsseldatei bspw. auf einem (zweiten) USB-Stick zu Hause sicher zu verwahren.
Um eine Schlüsseldatei zu verwenden und zu erstellen, folgen Sie der obigen Anleitung unter Punkt 7 und klicken dort auf „Schlüsseldatei hinzufügen“. Wählen Sie dabei mit „Durchsuchen“ den Pfad aus, unter der die Schlüsseldatei nach dem Erstellen abgelegt werden soll und von wo Sie diesen

Mit Hilfe eines „Yubikeys“ können Sie Ihre Datenbank zusätzlich zu einem Passwort (und zu einer Schlüsseldatei) per sog. „challenge response“ absichern. Eine Anleitung findet sich hier[10]. Ähnlich wie bei einer Schlüsseldatei müssen Sie diesen immer dabeihaben, um Ihre Datenbank zu öffnen. Dieser Sicherungsmechanismus ist nur fortgeschrittenen Userinnen und Usern empfohlen. Zudem ist im Einzelfall zu prüfen, wie der Yubikey unter Android und iOS zum Einsatz kommen kann.

Nutzung unter iOS und Android

Für iOS und Android gibt es keine KeePassXC-Version; hier ist auf andere Apps zurückzugreifen: für iOS die App „Strongbox“[11] (erhältlich im AppStore), für Android die App „Keepass2Android“[12] (zu beziehen über den PlayStore). Da die Benutzung dieser Apps sich betriebssystembedingt etwas von den Desktop-Versionen unterscheidet, soll hier kurz auf diese eingegangen werden.

iOS

Installieren Sie die Apps „Strongbox“ sowie „sciebo“ und richten Sie letzteres ein. Öffnen Sie die App „Strongbox“ und klicken rechts oben auf das Plus-Symbol. Wählen Sie dort „Vorhandene hinzufügen…“. In der angezeigten Liste klicken Sie auf „WebDAV“. Geben Sie bei Verzeichnis die URL „https://uni-koeln.sciebo.de/remote.php/webdav“, bei „Benutzername“ Ihren sciebo-Benutzernamen (Achtung: Vergessen Sie nicht den Zusatz „@uni-koeln.de“ nach Ihrem Personal-Accountnamen!) sowie Ihr dazugehöriges Passwort ein. Wählen Sie im Anschluss den Pfad zu Ihrer Datenbank-Datei (die Datei hat die Endung „.kdbx“). Sie können nun den Namen der zu öffnenden Datenbank verändern oder per „Hinzufügen“ bestätigen. Klicken Sie nun auf den neu erstellten Eintrag in der Datenbankliste. Dort müssen Sie das Passwort Ihrer Datenbank eingeben und ggf. die Schlüsseldatei „Auswählen“.

Android

Installieren Sie die Apps „Keepass2Android“ und „sciebo“. Öffnen Sie diese und wählen „Datei öffnen“ sowie anschließend „ownCloud“. Geben Sie bei im obersten Feld („ownCloud-URL“) „uni-koeln.sciebo.de“, bei „Benutzername“ Ihren sciebo-Benutzernamen (Achtung: Vergessen Sie nicht den Zusatz „@uni-koeln.de“ nach Ihrem Personal-Accountnamen!) sowie Ihr dazugehöriges Passwort ein. Wählen Sie im Anschluss den Pfad zu Ihrer Datenbank-Datei (die Datei hat die Endung „.kdbx“). Im folgenden Fenster müssen Sie nun den Schutz der Datenbank auswählen: Wählen Sie bspw. „Nur Kennwort“ oder „Kennwort + Schlüsseldatei“. Geben Sie nun Ihr (Master-)Kennwort Ihrer Datenbank ein und wählen ganz unten „Entsperren“.

[1] https://hpi.de/pressemitteilungen/2018/die-top-ten-deutscher-passwoerter.html

[2] https://keepassxc.org/

[3] https://www.sciebo.de

[4] Eine sehr ausführliche Anleitung, in der alle Funktionen und Details beschrieben werden, finden Sie unter https://keepassxc.org/docs/KeePassXC_GettingStarted.html#_welcome.

[5] https://hochschulcloud.nrw/de/download/index.html

[6] https://keepassxc.org/download/

[7] Ein Yubikey ist Security-Token mit vielen verschiedenen Funktionen in Hardwareform, der wie ein kleiner USB-Stick aussieht und bspw. am Schlüsselbund oder im Geldbeutel mit sich geführt werden kann, siehe https://www.yubico.com/der-yubikey/?lang=de.

[8] https://keepass.info/help/kb/yubikey.html

[9] Alternativ ist es auch möglich, sciebo per WebDAV-Protokoll als Laufwerk im Windows-Explorer zu verbinden. Die hierfür zu verwendende URL lautet: https://uni-koeln.sciebo.de/remote.php/webdav/.

[10] https://keepassxc.org/docs/#faq-yubikey-howto

[11] https://apps.apple.com/us/app/strongbox-password-safe/id897283731

[12] https://play.google.com/store/apps/details?id=keepass2android.keepass2android

Sicheres Surfen unter Privacy-Aspekten – Tracker, Cookies, Cookie-Banner und Werbung blockieren

Cookie-Banner der Webseite thomann.de — Keine Kekse? Die Firma Thomann fragt danach in einem schön gestalteten Cookie-Banner – trotzdem kann so etwas nerven.

Beim Surfen im Web begegnet man heutzutage quer durch die Bänke der verschiedenen Browser und Betriebssysteme einigem, das das angenehme Surfen erschwert: Entweder nerven Cookie-Banner, man wird über sämtliche Webseiten mit der immer gleichen Werbung bombardiert und im Hintergrund sammeln Google und Co. fleißig Daten über unsere Webseitenbesuche oder Online-Käufe.

In diesem Beitrag geht es um folgende Fragen:

Wie kann man „sicher“ surfen, ohne dass Daten über mich und mein Surfverhalten abfließen?
Was kann ich tun, um trotzdem einigermaßen bequem zu Surfen, ohne von Cookiewarnungen gestört zu werden? Und:
Wie bekommt man das Blockieren von Cookies in den Griff, ohne dass mein Browser die Webseiten vor lauter Datenschutzeinstellungen nicht mehr richtig anzeigen kann (bespielsweise weil im Hintergrund die nötigen Funktionen zur Anzeige blockiert werden)?

Die c’t hat sich mit diesen Themen auch vor einiger Zeit beschäftigt. Hier versuchen wir, mit noch etwas weniger Aufwand möglichst viel zu erreichen und gehen dabei möglicherweise nicht ganz so weit wie die c’t.

Worum es hier nicht geht

Natürlich gibt es weitere Themen, die ebenso beachtenswert sind, wie beispielsweise „Das absolut sichere Betriebssystem fürs Online-Banking“ oder sehr effektive Skript-Blocker wie NoScript – eines der wirkungsvollsten Tools beim Blockieren von Webinhalten, aber auch eines der am schwierigsten zu bedienenden Tools, wo täglich viel Handarbeit beim Surfen nötig ist. Aber: Geht man so tief, dann bewegt man sich erstens an den Grenzen dessen, was man einem „normal-IT-informierten“ Menschen zumuten kann. Das ist also nur in den seltensten Fällen etwas, das man seinen Eltern empfehlen oder gar einstellen mag.

Zum anderen soll es hier ja um bequeme Lösungen gehen, die alltagstauglich und für alle schnell umsetzbar sind.

Auch das anonyme Surfen ist nicht Ziel dieser Betrachtung.

Der richtige Browser

Bei der Browser-Wahl ist man immer am Rande der Gretchenfrage: Wie hast Du’s mit dem Webbrowser? Firefox? Chrome? oder gar: Edge? Sicherlich kann man die Entscheidung, welches Programm man nutzt, guten Gewissens als Geschmacksfrage betrachten. Objektiv gesehen gibt es Browser, die privacyfreundlicher sind als andere. Erst vor kurzem gab es in der c’t 14/2021 vom heise-Verlag einen Browsertest dazu, siehe hier. Der eigentliche Test in der Onlinefassung befindet sich leider hinter einer Paywall, aber an der Überschrift lässt sich schon das Ergebnis erahnen: Vorne liegen der Brave-Browser (auf dem Google-freien Chromium-Browser basierend), dicht gefolgt von dem bekannten Mozilla Firefox und der Apple-Browser Safari.

Würde man eine Empfehlung aussprechen, ist der Brave-Browser ohne weitere Einschränkungen zu empfehlen. Will man aber noch einige Add-Ons einsetzen, die das bequeme, privacy-bewusste Surfen wirksam unterstützen, hat der Firefox die Nase vorn. Es gibt sicherlich auch für Chrome/Chromium/Brave gute Erweiterungen, aber hier legen wir den Fokus auf den Mozilla-Browser – wobei viele der hiesigen Erweiterungsempfehlungen sowohl für den Firefox als auch für chromium-artige Browser verfügbar sind.

Damit gibt es auch eine klare Warnung vor dem von Google entwickelten Chrome-Browser: Hier werden sämtliche Websuchen, Google-Ergebnisse und aufgerufene URLs mit Google geteilt. <ironie>Falls Sie als Chrome-User:in also mal vergessen haben sollten, auf welcher Webseite Sie dies oder jenes gefunden hatten: Einfach mal bei Google nachfragen, dort wissen sie das sicherlich noch.<ironie /> Bei Chromium und bei Brave ist dies nicht der Fall. Zudem avisiert Google seinen User:innen, dass es zukünftig jegliche Erweiterungen, die die Übermittlung von Werbeanzeigen einschränken, nicht mehr zulassen will.

Kekse ja/nein und wenn ja, wie viele? Cookie-Banner blockieren

Wer es satt ist, bei jeder neuen Seite die Bestätigung für mehr oder weniger Cookies geben zu müssen, und sich darüber zu ärgern, dass die Banner fast alle unterschiedlich aussehen (und wo war jetzt nochmal die Funktion zum Konfigurieren, wie viel Cookies was an welche Firma weitergeben?), dafür ist das Add-on „I don’t care about Cookies“ geeignet. Nicht ausnahmslos, aber doch in einem größeren Anteil werden sämtliche Cookie-Banner im Hintergrund ohne menschliches Zutun „beantwortet“. Dies jeweils möglichst privacyfreundlich. Wer mag, kann bei fehlgeschlagenen Cookiebannerblockierungsversuchen die URL an den Betreiber übermitteln, in der Hoffnung, dass zukünftig auch diese URL cookie-banner-frei sein wird.

Cookies automatisiert löschen

Der Firefox bringt von sich aus einige cookie-freundliche Einstellungen mit, die man unter den Einstellungen findet. Werden dort Cookies generell blockiert, kann das zu Problemen beim Surfen führen, gerade dann, wenn man beispielsweise bei Webshops eingeloggt ist. Sicherlich ist der Inkognitomodus hier auch eine Möglichkeit, aber wenn man „einfach nur“ möchte, dass nach dem Besuch einer Webseite das dazugehörige Sessioncookie und andere gelöscht werden, leistet dies das Add-on „Cookie Auto-Delete“ (für Firefox und Chrome/ium). Dies lässt sich außerdem konfortabel einstellen, wo wann und in welcher Frequenz Cookies nach Webseitenbesuchen gelöscht werden sollen.

Übermittlung von Daten an Drittanbieter überwachen/deaktivieren

Wissen Sie, wer im Hintergrund eigentlich mitliest, wo und auf welchen Seiten Sie surfen? Das zu analysieren kann schon mal zu überraschenden Erkenntnissen führen. Dazu brauchen Sie das Add-on uBlock origin. Dies gibt es ebenfalls für Firefox und Chrome/ium.

Wenn Sie es ausprobieren wollen, gehen Sie einmal auf die Webseite der Süddeutschen Zeitung oder noch besser: dem Spiegel und schauen Sie, wo die Daten hinfließen! Übrigens: Bei der Zeit besteht übrigens die spannende Option, sich von der Datenübermittlung freizukaufen, für ein paar Euro pro Woche…

Ebenso wirkungsvoll ist der „Privacy Badger„. Hier eine Entscheidung zu fällen, ob uBlock oder der Privacy Badger seine Dienste besser leistet, ist schwer abzuwägen. Beide Add-ons lassen sich bestens nebeneinander betreiben, und meistens werden beide Erweiterungen „fündig“.

Werbung blockieren

Auch das Ermitteln von Werbeanzeigen und das Eintragen in eine Blocklist erledigt das uBlock Origin. Zudem werden Übermittlungen von Webseiten, die bekanntermaßen Schadsoftware verteilen, wirkungsvoll blockiert.

AdBlock Plus ließe sich unter Umständen auch als Werbeblocker verwenden, wobei in den letzten Jahren bekannt wurde, dass bestimmte Werbeeinblendungen bewusst durchgelassen wurden. Offiziell heißt es „einige, nicht aufdringliche Werbung„. Jedoch gab es in der Vergangenheit gewisse Verdachtsmomente, dass sich Werbetreibende auf eine Allowlist einkaufen konnten. Hierzu sei auch auf ein Gerichtsurteil hingewiesen.

Ganz abzuraten ist von AdBlock Plus also nicht. Aber uBlock origin erfüllt sehr ähnliche Zwecke, und zwar sehr wirkungsvoll, so dass die Empfehlungstendenz hier eher in Richtung uBlock geht.

Noch etwas zur Suchmaschinennutzung

Viele Webinhalte sind so ausgelegt, dass die Datenkrake Google sie möglichst gut finden kann. Die Technik der Search Engine Optimization („SEO“) macht leider dort Halt. Beispielsweise schafft es die deutlich datenschutzfreundlichere Suchmaschine duckduckgo.com nicht, sämtliche Inhalte der uni-koeln.de-Webseiten auszulesen. Sucht man etwas auf den universitären Portal- oder Verwaltungsseiten, ist Google derzeit oft die einzige Suchmaschine, die zu den richtigen Stellen führt.

Aus Privacy-Sicht ist duckduckgo.com fraglos die Suchmaschine der Wahl. Aber sie ist leider eben nicht so effektiv, wie man sich das wünscht. Immerhin ist zumindest ein Großteil der Seiten darüber auffindbar. Für uni-koeln-Ergebnisse aber steige ich hin und wieder temporär auf Google um (beispielsweise im Inkognito-Modus).

Fazit

Wer will, kann etwas dafür tun, weniger transparent im Netz unterwegs zu sein. Letztlich ist das Katz- und Mausspiel des Datensammelns durch die DSGVO zwar nicht völlig ausgeschlossen worden, aber zumindest ist das Thema des Schützens der eigenen (Surf-)Daten den Menschen nun etwas bewusster geworden. Mit dem Interesse wuchsen auch die Anreize für Entwicklungsteams, mit Browsererweiterungen wirksam die Übermittlung von Surfdaten zu unterbinden. So ganz intransparent ist man als User:in natürlich nie, aber zumindest fällt es den Datensammelstellen so etwas schwerer, uns allzusehr zu einem vollständigen Profil zusammenzusetzen.

Auch Apple kann kompliziert: Mails signieren und verschlüsseln mit iPhone und iPad

Auf die Gefahr hin, dass die letzten Beiträge unseres Blogs ein klein wenig Apple-lastig werden, folgt auf den letzten Beitrag ein weiterer über iGeräte, genauer: Über verschlüsselte E-Mails, und warum die Sache mit der Usability nicht immer so einfach ist, wie man das als User*in gerne hätte.

Haben Sie, liebe Blog-Lesende, schon einmal eine E-Mail verschlüsselt? Nein? Dann gehören Sie wahrscheinlich zur großen Mehrheit von IT-Nutzenden, die das Thema zwar „schon einmal irgendwo gehört oder gelesen“ haben, aber sich selbst noch nie damit befasst haben.

Zumindest könnten Sie einmal darüber nachdenken, Ihre E-Mails mit Hilfe eines S/MIME-Zertifikats zu signieren, was gleichzusetzen ist mit einer Unterschrift. Wie Sie an der Uni Köln ein solches Zertifikat beantragen und wofür das gut ist, können Sie hier nachlesen.

Wie man sein Zertifikat dann auf verschiedenen Geräten einrichtet und nutzt, haben wir an dieser Stelle dokumentiert. Einmal eingerichtet, ist das Ganze sofort lauffähig, und Ihre Mails werden fast unmerklich digital signiert. In diesem Beitrag legen wir den Fokus auf mobile Apple-Geräte. iOS unterstützt S/MIME-Zertifikate und die E-Mail-Verschlüsselung schon seit dem Jahr 2015 – so neu ist das Thema zugegebenermaßen also nicht.

Bildschirmabbild, das das Fenster zum Erstellen einer neuen E-Mail zeigt

Verschlüsselte oder signierte E-Mails zu empfangen ist kinderleicht. Neben dem Absende-Namen taucht bei einer signierten und/oder verschlüsselten E-Mail ein kleines Häkchen und gegebenenfalls ein Schlosssymbol auf.

Jetzt kommt der Teil, der komplizierter ist, als es sein müsste: Spannend wird es, wenn man seine Mails neben dem Signieren auch verschlüsseln möchte. Dazu schweigt sich interessanterweise sogar die Anleitung von Apple selbst aus. Das führt dann dazu, dass man zunächst einmal eine Fehlermeldung erhält, wenn man es mit dem Verschlüsseln versucht (siehe Bild). Wo hakt’s? Die Anleitung von Apple sagt, dass in diesem Fall das Zertifikat der Empfänger*in nicht gefunden wurde. Aber kein Wort darüber, was man nun tun soll, damit das iGerät diesen öffentlichen Schlüssel der anderen Person kennenlernen kann…?

Spoiler: Dazu muss man das Zertifikat tatsächlich „installieren“, sagt die Oberfläche, wenn man ein bisschen danach sucht.

Hat man diese Schritte einmal gefunden, ist es ganz einfach:

1.) Eine E-Mail der Person öffnen,
2.) in der Kopfzeile auf den Namen klicken,
3.) gegebenenfalls nochmals auf den Namen klicken, dann
4.) auf „Zertifikat anzeigen“, und zum Schluss
5.) auf „Installieren“ klicken.

Diese Schritte muss man für jede Person vornehmen, der man verschlüsselte E-Mails senden will.

Zusammenfassend kann man sagen: Wenn man einmal weiß, was man tun muss, ist es gar nicht so kompliziert. Aber warum gestaltet man – beziehungsweise Apple – diesen Vorgang so umständlich? Einfacher wäre es wie beim Open-Source-Mail-Programm Mozilla Thunderbird: Hier wird der öffentliche Schlüssel der Absender*in – also der Teil des Zertifikats, der dem iOS-System wie oben genannt zunächst „bekannt gemacht“ werden muss – direkt automatisch gespeichert.

Kurzes Fazit: Weniger ist mehr. Ich würde mir wünschen, dass Apple dieses Prozedere vielleicht etwas einfacher gestaltet und zukünftig weniger Arbeitsschritte nötig sind. Das würde zur Akzeptanz von E-Mail-Zertifikaten und deren Einsatz sicher enorm beitragen.

sshblack under macOS Sierra

When you run a computer that is SSH-enabled and open to access from the internet, you should use safe passwords (or even better: private key authentication) and a restrictive sshd.conf. But even with that, the barrage of malicious connection attempts can cause performance issues.

I have been using sshblack for many years on my Mac to battle that issue: when an IP address makes multiple failed attempts to login, it gets banned for a while. The popular fail2ban does that for Linux systems, but it doesn’t work on Mac OS X/macOS.

sshblack always needed some hand-holding with new OS releases, but with Sierra there was an entirely new challenge: there are no log files for sshd anymore! In previous versions, sshblack would look in /var/log/system.log for failed login attempts. The file still exists, but most logging in Sierra uses Apple’s new Unified Logging and Tracing System. That means the only way to access logging for sshd is either Console.app or the log CLI command. Using log with its stream parameter to get real-time logging data incurs a huge performance penalty, so the only way to go seems to be log show. So instead of tailing a log file, the script now has this definition:

my ($LOG) = ‚/usr/bin/log show –style syslog –last 1m |‘;

I added a sleep 60 statement to the loop and removed the code meant to deal with log rotation. Seems to work fine.

UniNow – Bequem durch’s Studium?

UniNow liefert genau das, was viele Studierende sich schon lange wünschen: Eine App fürs Studium, die alles kann, unter einer Oberfläche. Sich nicht mehr an gefühlt tausend unterschiedlichen Systemen anmelden zu müssen, die zudem für eine mobile Ansicht häufig nicht geeignet sind. Toll.

Der Haken an der Sache? Die App stammt von keiner Uni, sondern von einem Drittanbieter. Diesem Anbieter müsst Ihr die Zugangsdaten zu Eurem Studierendenaccount anvertrauen, an dem mittlerweile eine ganze Reihe von Diensten hängen: Mail, Klips, Ilias, Wlan, VPN, Eduroam, SOFS, Softwareshop, lizenzierte Zugänge u.s.w. Dienste also, die sehr persönliche Daten beinhalten bzw. Dienste mit hohem Missbrauchspotenzial. Mit Euren Zugangsdaten wird sich UniNow dann mittels seiner Server bei den unterschiedlichen Diensten der Uni anmelden und Eure Daten abfischen. Dass die Weitergabe der Accountdaten gegen jegliche Benutzungsordnungen verstoßen, eine Exmatrikulation bzw. fristlose Kündigung zur Folge haben kann, soll hier jetzt gar nicht das Thema sein. Vielmehr soll es um den Schutz Eurer Daten gehen und Euren eigenverantwortlichen Umgang mit diesen.

Die Uni Köln betreibt ziemlich viel Aufwand, um Eure Daten vor unberechtigten Zugriffen zu schützen. Es ist zudem penibel reglementiert, was gespeichert werden darf und wer zu welchem Zweck Einsicht in Eure Daten erhält. Sobald an der Uni irgendetwas mit personenbezogenen Daten passieren soll, müssen Datenschutzbeauftragter und ggf. Personalrat in langen Verfahren diesem zustimmen. Ein Beispiel dazu aus dem Tagesgeschäft des Helpdesk: Diesen erreichen häufig Anfragen, Euch Euer Passwort des Studierendenaccounts zuzumailen, da Ihr dieses vergessen habt. Das wird aus vielerlei Gründen nicht passieren: Der Helpdesk hat keine Einsicht auf diese Daten. Selbst wenn, wäre das nutzlos, da das Passwort nur verschlüsselt vorliegt. Und zu guter Letzt würde der Helpdesk solch sensiblen Daten nie über eine ungesicherte Mailverbindung hinauspusten.

All solche Bemühungen um Datenschutz würden natürlich ad absurdum geführt, wenn Ihr freiwillig Eure Daten aus der Hand gebt. Als Ausweg aus diesem Dilemma bliebe letztendlich nur der Rückgriff auf eine „vertrauenswürdige“ App bzw. einer App, die wenigstens den gleichen Datenschutzbestimmungen unterliegt, wie alle anderen Dienste der Uni auch. Eine solche App gibt es aber noch nicht. Die Gründe hierfür sind vielfältig. Positiv ist zu erwähnen, dass die Uni Köln – über das RRZK sowie das Prorektorat für Lehre und Studium – zur Zeit gemeinsam mit anderen Hochschulen am Projekt „StApps“ arbeitet, welches die Erstellung eigener Uni-Apps zum Ziel hat. Mehrere Mitarbeiter wollen dafür sorgen, dass wir Euch diese App möglichst bald bereitstellen können.

Verschlüsselung dank Let’s Encrypt

Dank der Initiative „Let’s Encrypt“ kann nun jede(r) Betreiber(in) von Webseiten diese kostenfrei auch per https bereitstellen, also den Transportweg mit SSL verschlüsseln. Dies war zwar bislang auch mit anderen Anbietern möglich, aber die damit erstellten Zertifikate waren nicht in den gängigen Browsern vertreten, sodass beim ersten Besuch der Seite stets eine Warnmeldung erschien. Bei „Let’s Encrypt“ ist dies nicht mehr so.

Dementsprechend habe ich auch die Domains auf meinem eigenen privaten Server nun per https verfügbar gemacht. Eigentlich wollte ich an dieser Stelle eine kleine Anleitung verfassen, da ich mir meinen Erfolgsweg bei diversen Blog- und Foreneinträgen zusammengesucht hatte. Inzwischen habe ich aber einen Beitrag entdeckt, der exakt meine Vorgehensweise beschreibt, incl. mehrerer Domains in einem Server und Auto-Renew per Cronjob. Daher verweise ich unten auf diesen Artikel von Dominic Pratt und ergänze lediglich, dass man inzwischen das Auto-Renew auch einfacher machen kann, nämlich per Crontab-Eintrag á la:

30 2 * * 1 /opt/letsencrypt/letsencrypt-auto renew >> /var/log/le-renew.log

Zudem sollte man unbedingt darauf achten, ausschließlich sichere Protokolle und Cipher Suites zu aktivieren. Leider unterstützen nicht alle Server und Clients automatisch die neuesten und besten Einstellungen. Ein guter Kompromiss ist derzeit im Apache z.B.:

SSLProtocol all -SSLv2 -SSLv3
SSLCipherSuite HIGH:MEDIUM:!ADH:!MD5:!RC4

Damit erreicht man im SSL-Test (https://www.ssllabs.com/ssltest) immerhin Grade A. Besser ginge es noch bspw. mit der Aktivierung von Forward Secrecy.

Hier nun der angesprochene Artikel:

Let’s Encrypt nutzen – eine Anleitung

Passwörter mit Dashlane aufbewahren, einsetzen und synchronisieren

Meine Ausgangspunkt

Mein digitales Leben ist „geschützt“ durch gefühlt Zillionen von Passwörtern – faktisch sind es einige Hundert, aber mit Erinnerungsvermögen ist da nichts mehr zu machen. Bisher nutzte ich meinen Browser sowie eine lokale Anwendung auf meinem Smartphone zur Verwahrung dieser Credentials. Das war mehr schlecht als recht, denn mein Gerätebestand umfasst OS X, Android, Windows7 und iOS — alles in allem ein mittlerer Alptraum.

Dashlane „betritt“ mein digitales Leben

Ein Artikel von David Pogue [1][2] machte mich auf Dashlane aufmerksam. Das Tool behebt mein Problem inzwischen wirklich recht gut. Der „Migrationsaufwand“ war bei mir nicht wirklich vernachlässigbar, weil die Import-Funktion bei mir nicht so genial funktioniert hat – also knapp unter „Do What I Think“-Niveau. Auch das Sortieren der einzelnen Records nach Kategorien nervt (auch wenn es vernünftig ist).

Nach dieser Einstiegshürde ist Dashlane aber wirklich nützlich. Ich nutze die Anwendung nicht lokal, sondern synchronisiere darüber mein gutes halbes Dutzend Devices. Das funktioniert kostenlos für 30 Tage, danach nur mit einer kostenpflichtigen Subscription – Eine schwierige Abwägung zwischen Geiz und Komfort!

Meine Konfiguration ist nun so, dass ich Dashlane auf meinem Notebook, Arbeitsplatzrechner, Android-Smartphone, iPad und den privaten Rechnern nutze. Das Smartphone nutze ich auch als One-Time-Password-Generator (Google Authenticator).

Erfahrungen

Dashlane ist schon sehr pfiffig darin, Formulare richtig auszufüllen, aber David Pogues Beschreibung erscheint mir etwas zu euphorisch. Mir sind schon etliche Seiten untergekommen, bei denen die Logik nicht funktioniert. Bei englischsprachigen Seiten funktioniert das Auto-Ausfüllen aber gut.

Wirklich cool ist, dass man das Ausfüllen auf „Subdomains“ ausdehnen bzw. einschränken kann und die Möglichkeit mit mehreren Accounts für eine Website umgehen zu können. Nett ist auch die Möglichkeit, sichere Passwörter erzeugen zu lassen; nützlich sind die Hinweise auf vermutliche kompomitierte Web-Site, bei denen man Accounts hat. Das Wallet habe ich bisher wenig (aber erfolgreich) genutzt. Die anderen Features wie Nachrichten-Austausch und so nutze ich nicht.

Risiken und Nebenwirkungen

Ach ja, das Synchronisieren geht natürlich über die Server von Dashlane. Das Sicherheitsmodell scheint mir wasserdicht zu sein, solange man auf keinem seiner Endgeräte einen Keylogger eingefangen hat oder sonst irgendwie das Masterpasswort verliert. Im Normalfall geht also „unbrauchbarer“ AES256-Datenschrott über den Austauschpunkt. Für die Sicherheit von AES256 gibt es sogar eine Zusicherung der NSA – super!

Um etwas Schutz gegen die Keylogger-Problematik zu haben, nutze ich die Zwei-Faktor-Authentifizierung. Dann kann niemand ein Endgerät mit meinem Dashlane-Datenaustausch-Account verknüpfen. Wenn ich mein Android-Smartphone UND mein Masterpasswort verliere, wäre das natürlich ganz schlecht.

Nun gut, die Prism-Tempora-Sonstwas-Maschinen wissen nun wirklich ganz genau, welche Endgeräte ich nutze. Vermutlich ist dies ja auch für jene Leute die wirklich interessante Information – Passwörter von Individuen brauchen die eh nicht so dringend. Also: „Ja, man gibt Futter für diese Maschinen“, damit das Korrelieren im Big-Data-Wust dann besser geht.

Zusammenfassung

Angesichts des Nutzens finde ich das Werkzeug sehr interessant und werde es weiterhin einsetzen. Unberührt von der technischen Coolness ist der Umstand, dass beispielsweise eine Unternehmspolicy das Hinterlegen bestimmter Credentials in Password-Manager-Anwendungen untersagen kann.

Prüfung von Sicherheitszertifikaten

Die Prüfung der von Servern verwendeten Zertifikate hinsichtlich ihrer Gültigkeit und Vertrauenswürdigkeit ist heutzutage ein elementarer Bestandteil der persönlichen Sicherheit im Internet. Viel zu oft werden solche Hinweise zwar einfach weggeklickt, spätestens bei Shops, die die Angabe der Konto- oder Kreditkartendaten erfordern, und erst recht beim Online-Banking sollten aber wirklich alle Internetnutzer misstrauisch werden, sobald der Browser eine entsprechende Warnung anzeigt.

Aus diesem Grund ist auch die Uni Köln seit Jahren einer Certificate Authority angeschlossen, die in allen gängigen Browsern und Mailclients als vertrauenswürdig bekannt ist, namentlich der Root-CA der Deutschen Telekom. Denn auch an der Uni müssen z.T. sehr vertrauliche Daten über das Netz geschickt werden, z.B. Prüfungsergebnisse, Accountdaten oder auch E-Mails.

Umso wichtiger ist es, dass die entsprechende Prüfung der gemeldeten Sicherheitszertifikate möglichst automatisiert und zuverlässig erfolgt. Hierfür gibt es ein eigenes Netzprotokoll, das „Online Certificate Status Protocol“ (OCSP). Es prüft automatisch die Gültigkeit des vom aufgerufenen Server gesendeten Zertifikates. Dies ist leider nicht bei allen Browsern und Mailclients korrekt voreingestellt. Zum Teil wird nur auf den Servernamen geprüft, zum Teil aber auch gar nicht. Wir möchten daher hier für die wichtigsten Programme kurz beschreiben, wo die korrekten Einstellungen vorzunehmen sind.

Mozilla Firefox / Mozilla Thunderbird
Bei den beiden Mozilla-Programmen finden sich die Einstellung in einem übersichtlichen Menü unter „Einstellungen“ → „Zertifikate“ → „Validierung“.

Google Chrome
In Chrome muss unter „Einstellungen“ → „Erweiterte Einstellungen anzeigen“ → „HTTPS/SSL“ ein Häkchen bei „Serverzertifikate auf Sperrung prüfen“ gesetzt werden.

Internet Explorer / Windows Mail / Outlook
Alle drei sind fest mit dem Windows-Zertikatspeicher verbunden, den man im Internet Explorer unter „Extras“ → „Internetoptionen“ → „Inhalte“ → „Zertifikate“ erreicht (die Menüfolge mag in den verschiedenen Versionen etwas anders sein). OCSP wird von Windows erst seit Vista – und damit auch in Windows 7 und 8 – unterstützt, für XP fehlt die Funktion leider. Die Aktivierung erfolgt in „Extras“ → „Internetoptionen“ → „Erweitert“ und umfasst die Einstellungen „Auf gesperrte Zertifikate überprüfen“ und „Auf gesperrte Zertifikate von Herausgebern überprüfen“.

Apple Safari
Safari nutzt den zentralen Schlüsselbund von MacOSX. Diesen erreicht man in der Regel über das Anwendungsmenü im Bereich „Utilities“ oder „Werkzeuge“. Innerhalb des Schlüsselbunds kann man im Menü „Einstellungen“, Karteireiter „Zertifikate“ die passenden Einstellungen wählen. In aller Regel ist dies bei OCSP und CRL jeweils „Bester Versuch“, die Priorität sollte auf OCSP liegen.

Opera
In Opera (ab Version 9) muss man den Umweg über die Seite „about:config“ im Browser gehen. In den „Security Prefs“ kann man den Eintrag bei „OCSP Validate Certificates“ ändern. Da dieser aber standardmäßig aktiviert ist, muss man in der Regel nichts ändern.

Zwei-Faktor-Verifikation für Google-Accounts

Ob das RRZK-Blog ein guter Platz ist, um über ein Feature von Google-Accounts zu schreiben? Ich bin nicht sicher, aber viele an der Uni nutzen ja die Google-Angebote und daher ist es vielleicht für ein paar Leute von Interesse.

Ich selbst nutze einen Google-Account seit 2006 für mein „persönliches digitales Leben“. Die Datenschutz-Problematik ist mir durchaus bewusst, aber die Funktionen sind einfach zu verführerisch, um widerstehen zu können. Schon lange hat mich gestört, dass meine Daten nur durch ein kleines Passwort von der Welt getrennt sind. In einer globalen Cloud können merk- und tippbare Passwörter praktisch nie ein geeigneter Schutzmechanismus sein.

Seit einigen Monaten bietet Google nun eine Authentifizierungsmethode an, die „Two Step Verification“ genannt wird. Das klingt verdächtig nach der klassischen Zwei- bzw. Mehr-Faktor-Authentifizierung. Dies legt auch die Intro-Page nahe, die sagt „Sign in will require something you know and something you have“. Klingt sehr gut.

Der Start ist auch recht simpel; eine kleine Änderung in den Account-Einstellungen und man erhält Einmal-Zugriff-PINs über SMS, Voice Call oder eine recht nette Authenticator-App (für Android, iOS usw.), die zusammen mit dem traditionellen Passwort den Zugriff auf das Konto ermöglichen. Außerdem kann man Geräte nach eigenem Ermessen als „vertrauenswürdig“ einstufen; dann entfällt dort die Eingabe der zusätzlichen PIN. Auch der Desaster-Fall ist bedacht: dafür gibt es Backup-PINs zum Ausdrucken (Natürlich nicht ausdrucken, falls der Drucker ein Gerät mit Festplatte oder Netzwerk-Anschluss ist 😉 ).

Wie immer gibt es in der schönen neuen Welt auch ein paar Relikte aus der hässlichen alten Welt; in diesem Fall sind das die „anwendungsspezifischen Passwörter„. Diese sind zwar nicht „anwendungsspezifisch“, aber Passwörter mit fast allen schlechten Eigenschaften, die Passwörter haben können. Sie sind nicht anwendungsspezifisch, weil sie den Zugriff auf das komplette Google-Konto ermöglichen. Die Terminologie bedeutet, dass sie nur für eine bestimmte Anwendung eingesetzt werden sollen.

Ein zusätzlicher Schutz (im Vergleich zum klassischen Passwort) besteht neben der Länge darin, dass es weniger Risiken gibt, das Passwort zu verlieren oder unabsichtlich offenzulegen (revealing). Faktisch wird es einmal angezeigt und dann nie wieder; schreibt man es nicht auf, sondern kopiert es sofort in die Anwendung der Wahl und vergisst es, so kann man es selbst nicht mehr verlieren. Trotzdem kann in der rauen Wirklichkeit das eigene Google-Konto über diesen Mechanismus „geknackt“ werden. Also: Der Provider kann es noch „für einen verlieren“ – quasi „RaaS, Revealing as a Service“.

Klar, die „anwendungssprezifischen Passwörter“ sind eben Passwörter und daher ist der Authentifizierungsmechanismus auch keine echte Zwei-Faktor-Authentifizierung. Ich vermute, dass Google daher auch von einer „Two Factor Verification“ spricht. Zu dem Mechanismus und seinen potenziellen Schwachstellen gibt es diverse mehr oder weniger technische Erläuterungen.

Alles sinnlos also? Falls das eigene digitale Leben spartanisch ist und sich auf die Browser-Schnittstelle bzw. moderne Android-Systeme (wohl >2.3) beschränkt, sind anwendungsspezifische Passwörter verzichtbar. Dann ist das Niveau des Zugriffschutzes mit Zwei-Faktor-Verifikation deutlich besser als ohne.

Andernfalls muss man halt mit dem kleinen Schönheitsfehler leben. Ein Sicherheitszuwachs bleibt: Falls man doch einmal das gute alte Passwort verlieren sollte oder falls es ein Service-Provider „für einen selbst“ verliert, kann nicht ohne weiteres von jedem Rechner im Internet auf das Konto zugegriffen werden.

Was man auch noch im Auge behalten sollte:

Gut auf die Backup-Codes aufpassen.
Einen kritischen Blick auf die Liste der Sites, Apps und Dienste, denen Zugriff auf die eine oder andere Information des Google-Kontos eingeräumt wird. Sicherheitsvorfälle in diesen Bereichen können auf das Google-Konto übergreifen.

VPN-Unterstützung für Android-Endgeräte – Konfiguration der Klienten

Die letzten Tage habe ich mit der Integration von VPN für Android-Geräte verbracht. An dieser Stelle entschuldige ich mich vorab für mehrere Verbindungsabbrüche bei den Nutzern, die den IPSec-Klienten verwenden, denn durch die Umstellung der Verschlüsselungskonfiguration musste ich mehrmals morgens die IPSec-Verbindungen trennen.

Einige der Android-Smartphones von Samsung haben schon vor einigen Monaten VPN-Unterstützung in Form des AnyConnect-Klienten erhalten. Dieser verwendet als Protokoll SSL-VPN und sollte somit die wenigsten Probleme mit Firewalls etc. haben, da die Kommunikation nur über den Port 443 (TCP und UDP) und alle Sessions nur vom Klienten aufgebaut werden. Ich empfehle daher, diesen weiterhin zu verwenden, wo dieser verfügbar ist.

Um die restlichen Android-Endgeräte ua. auch Tablets mit VPN zu versorgen, musste ein völlig anderer Typ von VPN aktiviert werden, L2TP-IPSec. Dabei wird zuerst eine IPSec-Verbindung aufgebaut, in der wiederum ein L2TP-Tunnel erstellt wird.

Wie dies auf den Endgeräten konfiguriert wird habe ich exemplarisch unter http://rrzk.uni-koeln.de/vpnandroid.html dokumentiert. Da die Hersteller teilweise die Bezeichnungen und Menüstruktur verändern, können diese unter Umständen abweichen.

Bei der Verschlüsselung habe ich mich für mehr Sicherheit und damit für AES gegenüber 3DES entschieden. In der Literatur wird AES oft als ressourcenlastiger bezeichnet, was gerade bei den leistungsschwächeren Mobilgeräten in einem höheren Energiebedarf und somit einer kürzeren Batterielaufzeit resultieren könnte. Dazu habe ich aber keine Informationen gefunden und kann die Problematik daher nicht bewerten.

Ich bin gespannt, wie hoch die Nutzung von VPN über Android sein wird. Leider dauert es ja oft, bis sich die Nachricht über die neue Unterstützung von Endgeräten herumspricht.

Anleitung zur Einrichtung von L2TP-IPSec unter Android: http://rrzk.uni-koeln.de/vpnandroid.html