Aktualisierungen gibt es im Changelog, als RSS-Feed
oder im [matrix] Raum #prhdb-changes:nitro.chat

Privacy-Handbuch

Die Übernahme von WhatsApp durch Facebook zeigt, dass es einfach Sch.... ist, sich das Adress­buch klauen zu lassen. Irgendwann landet es in den Datensammlungen von Facebook (oder Google, Microsoft oder...), die alle als PRISM-Partner der NSA gelistet sind.

Juristisch kann man es DSGVO-konform so formulieren (AG Bad Hersfeld Familiengericht):

Wer den Messenger-Dienst "WhatsApp" nutzt, übermittelt nach den Vorgaben des Dienstes fortlaufend Daten in Klardaten-Form von allen in dem eigenen Adress­buch eingetragenen Kontakt­personen an das hinter dem Dienst stehende Unternehmen (Facebook).

Wer durch seine Nutzung von "WhatsApp" diese andauernde Daten­weiter­gabe zulässt, ohne zuvor von seinen Kontakt­personen aus dem eigenen Adress­buch hierfür jeweils eine Erlaubnis eingeholt zu haben, begeht gegenüber diesen Personen eine deliktische Handlung und begibt sich in die Gefahr, von den betroffenen Personen kostenpflichtig abgemahnt zu werden.

Wenn man als WhatsApp Nutzer die Telefon­nummern mit Bekannten austauscht, dann müsste man also eigentlich um die Zustimmung bitten, Name, Telefon­nummer und Freundschafts­status an Facebook zu schicken. Das Gespräch könnte so ablaufen:

Anforderungen an einen guten Messenger

Unter Berücksichtigung der massiven Überwachung von Instant Messaging, welche durch Edward Snowden bekannt gemacht wurde, und des Crypto War 3.0 ergeben sich folgende Anforderungen an einen guten Messenger Dienst:
  1. Sichere Ende-zu-Ende Verschlüsselung nach dem aktuellen Stand der Technik, die durch unabhängige Experten evaluiert wird. Die Auswertung von 160.000 Überwachungs­berichten aus dem Snowden-Fundus zeigt, dass Geheim­dienste die Messenger massiv überwachen.
  2. Sichere Transportverschlüsselung (SSL/TLS) für die notwendige Kommunikation der Apps mit den Servern und zwischen den Servern. Dabei sollten alle Best Practice Empfehlungen umgesetzt werden inklusive Certificate Pinning u.ä.
  3. Der Account sollte frei wählbar und nur optional mit einer Telefon­nummer verbunden sein. Telefon­nummern sind im Gegensatz zu E-Mail Adressen ein eindeutiges Identifizierungs­merkmal und nicht so einfach austauschbar wie (Wegwerf-) E-Mail Adressen. Das ermöglicht die Verknüpfung verschiedener Accounts bei unter­schiedlichen Messaging Diensten und die Zuordnung zu einer Person. Außerdem schützt die Weitergabe eines Pseudonyms statt Telefon­nummer gegen Stalking.
  4. Es sollte keine unerwünschten Uploads (Daten­klau) ohne ausdrückliche Zustimmung geben. Der Dienst sollte komplett ohne Daten­klau nutzbar sein und nur optional auf Daten wie das Adress­buch zugreifen, wenn es als Komfort- oder Sicherheits­feature gewünscht wird.
  5. Google-freie Installation (beispw. via F-Droid) und Nutzung sollte möglich sein.
  6. Die Nutzung auf dem Desktop PC sollte möglich sein. Oft lässt es sich auf dem PC oder Laptop mit Tastatur und Bildschirm besser arbeiten als mit einem Smartphone.
  7. Die Infrastruktur des Dienstes sollte dezentral verteilt sein und nicht von einem einzelnen Betreiber kontrolliert werden. Dezentrale Strukturen sind nur schwer von Regierungen durch Gesetze kompromittierbar, um Geheim­diensten die Über­wachung zu ermöglichen.

    Anmerkung: Im Gegensatz zu einigen Open Source Dogmatikern bin ich nicht der Meinung, dass eine dezentrale Infrastruktur "freier Messenger" gegen die Installation von Back­doors auf den Servern schützt. Während bei Threema oder Signal App immer wieder angezweifelt wird, ob dort wirklich die auditierte Software auf den Servern läuft, werden die Admins von [matrix] oder XMPP Servern per Definition zu Heiligen erklärt, die niemals etwas anderes installieren würden als die offizielle Software oder neugierig die Metadaten beschnüffeln.

    Für diese Glorifizierung der Open Source Admins gibt es keinen Grund. Als wir vor einigen Jahren noch Jabber/XMPP mit OTR-Verschlüsselung verwendeten, haben wir gehofft, das die Admins der Server nicht mit dem Modul mod_otr: man-in-the-middle module for Off-the-Record spielen oder es zumindest nicht gegen uns anwenden.

    Man musste vertrauen, so wie man heute Threema oder Signal App vertrauen muss.

    Die Gründe für Vertrauen sind sehr individuell. Manch einer sagt sich "Ich vertraue dem Admin, weil es ein Bekannter ist." und ein anderer denkt "Ich vertraue dem Admin nicht, weil es ein Bekannter ist, da die Neugier und Verführung zu einer kleinen Schnüffelei unter Bekannten am größten ist." (Stichwort Love-INT o.ä.)

  8. Es wäre schön, wenn die Bedienung so einfach wäre, dass auch meine Tante und ihre Kaffeekranz Freundinnen ohne lange Erklärungen damit umgehen können.
Einen idealen Messenger, der alle Bedingungen erfüllt, gibt es nicht. Man muss abwägen, was wichtig ist und welche Schwer­punkte man bei den Anforderungen setzt.

Multi-Device-Support als Sicherheitsrisiko

Multi-Device-Support ist ein heutzutage ein häufig gewünschtes Standard­feature für Messenger. Man möchte via PC und Laptop online sein, um eine vernüftige Tastatur und einen großen Bild­schirm zu nutzen, und man möchte via Smartphone unterwegs erreichbar sein. Dieses Feature erschwert es aber, eine sichere Ende-zu-Ende Verschlüsselung zu realisieren.

Ein potenter Angreifer kann den Multi-Device-Support ausnutzen, um ein weiteres Gerät im Namen des Opfers zu registrieren. Damit können alle Unterhaltungen mitgelesen werden und es sind auch Ende-zu-Ende verschlüsselte Chats betroffen. Das betrifft alle Multi-Device fähigen Protokolle.

Es ist eine alte Weisheit, dass eine Kommunikation erst dann wirklich vertrauenswürdig ist, wenn man die Schlüssel verifiziert hat und sicherstellt, dass nur diese verifizierten Schlüssel verwendet werden. Alle Messenger bieten die Möglichkeit, bei einem Treffen oder out-of-band über einen unabhängigen Kanal die verwendeten Schlüssel zu verifizieren.

Außerdem kann man bei vielen Multi-Device fähigen Messengern eine zweistufige Bestätigung für das Hinzufügen weiterer Geräte aktivieren. Damit ist eine zusätzliche Passphrase erforderlich, die sich vom Account Passwort unterscheiden sollte, wenn ein neues Gerät angemeldet wird.

Als Schutz gegen Angriffe bei (kurzzeitigem) physischem Zugriff auf ein entsperrtes Smart­phone bieten hochwertige Messenger eine zusätzliche PIN-Sperre für die App, die man bei hohem Schutz­bedarf aktivieren kann. Damit wird verhindert, dass ein Angreifer die App auf dem Smart­phone starten kann und damit die Rechte erlangt, um ein zusätzliches Gerät anzumelden.

Anmerkung: Die Krypto-Protokolle OTR (Jabber) und MTProto (Telegram) sind nicht Multi-Device fähig und daher von diesem Angriff nicht betroffen. 

Harte und weiche Verifikation

Auch wenn die Krypto nicht gebrochen werden kann, sind verschiedene Angriffe möglich:

Gegen diese Angriffe schützt eine Verifikation der Kommunikationspartner:

Notifications und Notificaton History

Beim Eintreffen neuer Nachrichten kann man sich Beanchrichtigungen anzeigen lassen. Die Anzeige ist auch auf dem Sperrbildschirm möglich. Damit könnte ein Angreifer, der physisch Zugriff auf das Smartphone hat, Informationen über Inhalte erlangen, die verschlüsselt sein sollten. Die angezeigten Daten werden außerdem in der Notification History gespeichert und bleiben auch dann erhalten, wenn man die eigentliche Nachricht löscht. Ein Beispiel:

Diese Anzeige der Nachrichten könnte im Freundes- oder Familienkreis für Verwirrung sorgen, wenn beispielsweise der Ehemann auf dem Smartphone seiner Frau öfters Nachrichten von anderen Männern mit Küsschen und Herzchen Smilies sieht.

Deshalb bieten gute Messenger die Möglichkeit, die angezeigten Inhalte zu konfigurieren und keine (verschlüsselten) Inhalte in Notifications zu leaken. Beispielsweise Threema: Oder Signal App:

Link Previews in Messengern

Einige Messenger bieten ein Link Preview, wenn man eine URL in das Eingabefeld tippt oder kopiert. Man kann den angebotenen Preview mit versenden oder vor dem Versand löschen. Oder ohne Bild:
Voraussetzung für einen Link Preview ist, das die Webseite im HTML Header die Open Graph Metatags enthält. Anhand dieser Metatags wird der Preview generiert (mit oder ohne Bild): <HTML>
  <HEAD>
...
    <meta property="og:title" content="Ein Beispiel">
    <meta property="og:description" content="Das ist nur ein sinnloses Beispiel">
    <meta property="og:image" content="https://beispiel.tld/images/preview01.png">
...
Um einen Link Preview zu generieren, kontaktiert der Messaging Client den Webserver und versucht die Webseite zu laden, sobald eine URL im Eingabefeld erkannt wird. Wenn die Webseite im Header die Open Graph Tags enthält, wird ein Preview generiert und evtl. das Bild vom Webserver geladen. Diesen Ablauf kann man sehr unterschiedliche implementieren: