IOException.de

Since WhatsApp was sold for 19 billion dollar to Facebook, lots of blogs and news seek for alternatives. In this short comment, I will point out why we all need alternatives, why we all need more than one alternative, why this works and what features our new alternative must have.

Threema, Textsecure or Telegram are just a few new so called WhatsApp competitor nowadays. But before we go out and look for alternatives, we must understand what’s the problem with WhatsApp and Facebook. And before we consider that, we must understand why Zuckerberg payed 19 billion dollar for WhatsApp. I intentionally do not say that WhatsApp is worth that much money. It’s only that much worth for Facebook. The big deal shows us what really matters in the information age. Surprise, it’s information itself. Facebook itself is free, so where comes all the money? Facebook can afford buying WhatsApp, despite Facebook has not a single paying user. This tells us that information is very important and also very expensive. Important for advertising, marketing research or insurance companies. Or intelligence agencies. Information about us. Companies make billions of dollars by selling information they know about us!

The bad thing about this is, that we only understand why this can be a problem when it’s too late. When knowledge about us is used against us and we suddendly recognize it. Before that, we all agree using our personal information. And that’s bad.

So we note that information is important and we must take care of it.

For example by not giving a single company that much information. But there is more. It’s power. Facebook not only has our personal information, it has the power of more than one billion users. And there is almost no business competition.

So we note that using one centralized service supports monopolism and helps aggregating information.

So far, we’ve learned about the disadvantages of an information collecting centralized service. Now let’s have a look at why WhatsApp has so many users despite there are a lot of alternatives. When we read about apps having the potential to compete with WhatsApp, we always stumble upon the word usability. One of the main reason why WhatsApp is so successful, is because everyone can use it. You do not even have to register (explicitly). Registering is done almost instantly and implicitly

So we note that providing a real alternative to people, we must make the barrier of using our product very, very low by optimizing its usability. Features like group-chats or the ability to send multimedia files would increase the acceptance too. Platform support is also very important.

Let’s recap that. A chat system should protect our information. This can be done partially by using the right encryption. Partially, because meta data can be very difficult to encrypt. That means, data between two chatters can be strongly encrypted, but it’s hard to encrypt the information about who talks to each other (meta data). If we store the whole meta information collection at a single place (or company), we can hide what we are talking but not when, to who, where, how often and so on. For the latter, we must take a look at network topologies first. All communication in WhatsApp or Facebook end up at one server or server-cluster (see figure 1). A better alternative is using multiple independent servers. A decentralized system (see figure 2).

Figure 1: Centralized network topology.

Here, each server can be owned by another person or company. Communication is still possible between them because the Internet is designed that way. Think about email for example. Here we have the freedom of choice which provider we want to use. On top of that, we could use TOR (a network for the anonymization of connection data) to disguise even more of our meta data.

Figure 2: Decentralized network topology.

Another network topology we consider is the peer-to-peer architecture (see figure 3). Skype used to have this before Microsoft took it over. But Skype also fails somewhere else. At first, meta data is centralized. Second, it is owned by is a network for the anonymization of connection data one company (Microsoft). Third, it fails on it’s closed source nature. We cannot control or see what’s going on inside the system.
So we note that using an open source decentralized system is good. Also note that this is where most of the recently discussed alternatives fail completely.

Figure 3: Peer-to-peer network topology.

Another problem with closed source is the denial of choice. For example the choice of crypto algorithms. In an open system, we can use any end-to-end encryption we want. And we want that choice because weak encryption is not considerable for us. We also want encryption that guarantees us deniability and perfect forward secrecy. Deniability means that nobody can proof that your conversation actually took place. Perfect forward secrecy means that if someone comes into possession of your password or encryption keys, your conversation cannot be decrypted afterwards. So we note that we need a system that allows us to use our own clients and our own encryption. Let’s summarize this. Our chat system must be decentralized, support any client and any end-to-end encryption,
be easy to use and support all available platforms. To make it short here, it already exists. It’s called XMPP and was developed in 1999.

In diesem Beitrag möchte ich einen einfachen Mechanismus beschreiben, um in einer Client-Server Infrastruktur Updates an die Clients auszuliefern. Ich hatte bei einem Projekt einige Clients in ubiquitären Umgebungen und war dafür auf der Suche nach solch einem System. Die Clients sind einfache Kleincomputer mit einer schlanken Linux-Distribution und müssen ohne technische Wartung auskommen.

Anforderungen an den Update-Mechanismus sind:

• Authentifizierung
  Die Verbindung zum Update-Server muss authentifiziert sein.
  Das war in den großen Betriebssystemen früher ein großes Problem und ist in vielen Programmen noch immer ein Schwachpunkt. Der Instant Messenger-Exploit Anfang dieses Jahr war etwa ein Beispiel, in dem der Update-Server nicht authentifiziert wurde.
• Fallbacks
  Falls ein Update schiefgeht sollte es sehr einfach möglich sein den alten Stand wiederherzustellen. Es ist nicht akzeptabel, dass Daten verloren gehen. Alles muss abgespeichert werden.
• Scripting
  Ich will an jeden Zeitpunkt des Updateprozesses einen Hook setzen können (vor dem Update, danach, etc.). Dies kann später benutzt werden um beispielsweise das Gerät nach dem Einspielen von Neuerungen zu rebooten, um zu überprüfen ob das Update erfolgreich verlaufen ist oder um etwa Datenbankänderungen durchzuführen.
• Autorisierung
  Der Updateserver darf nicht öffentlich verfügbar sein — Clients müssen sich ihm gegenüber autorisieren um Zugriff auf Updates zu bekommen. Die Option später eine gruppenbasierte License-Policy für verschiedene Softwareversionen nachrüsten zu können soll offengehalten werden.

Ich habe mich letztlich dazu entschieden hierfür git zu verwenden. Die Versionsverwaltung deckt bereits im Vornherein einen großen Teil der Anforderungen ab. Git bot sich an, da ich auch sonst sehr gerne mit dem Tool arbeite und damit also schon umgehen konnte. Der Aufbau meines Systems sieht inzwischen so aus:

Auf der Serverseite

• Webserver, Zugriff nur über HTTPS möglich, selbstsigniertes X.509 Zertifikat.
• Ein “bare” git repository, geschützt über HTTP-Authentifizierung: https://updates.foo.net/bar.git.
  Neue Updates werden zu diesem Repository gepusht.
• hooks/post-update: Wird ausgeführt nachdem neue Updates gepusht wurden.

  # wird von git für HTTP repositories benötigt
  git update-server-info  
  
  # korrekte Zugriffsrechte
  find ~/bar.git -exec chmod o+rx '{}' \;  
  

Auf der Client-Seite

• Cronjob. Überprüft regelmäßig ob neue Updates vorliegen. check.sh enthält:

  #!/bin/sh
  
  # unser Update-Repository
  cd "~/bar.git"
  
  # neue Updates fetchen, git legt diese dann in FETCH_HEAD ab
  git fetch
  
  # liegen im origin-Repository neue Änderungen vor?
  newUpdatesAvailable=`git diff HEAD FETCH_HEAD`
  
  if [ "$newUpdatesAvailable" != "" ]
  then
          # fallback erstellen
          git branch fallbacks
          git checkout fallbacks
  
          git add .
          git add -u
          git commit -m `date "+%Y-%m-%d"`
          echo "fallback created"
  
          git checkout master
          git merge FETCH_HEAD
          echo "merged updates"
  else
          echo "no updates available"
  fi
  

• Unter hooks/post-merge können Aktionen definiert werden, die nach dem Einspielen der Änderungen ausgeführt werden (Reboot, Validierung des Updateverlaufs, etc.).

Der Client hat eine Kopie des Server-Zertifikats und benutzt dieses um die Verbindung zu authentifizieren. So können die Geräte sicher sein, dass sie zum richtigen Server verbunden sind. Die passende ~/bar.git/.gitconfig sieht in etwa so aus:

[core]
        repositoryformatversion = 0
        filemode = true
        bare = false
        logallrefupdates = true
[remote "origin"]
        fetch = +refs/heads/*:refs/remotes/origin/*
        url = https://user@updates.foo.net/bar.git
[http]
        sslVerify = true
        sslCAInfo = ~/server.crt
[core]
        askpass = ~/echo_your_https_authorization_pw.sh

 
Was sind Nachteile dieses Aufbaus?
Ich habe mich bewusst für ein Versionierungssystem entschieden, da meine wichtigste Anforderung ist, dass die Geräte auf keinen Fall Daten verlieren. Dies ist gleichzeitig auch ein Nachteil des Systems, da letztlich alles archiviert wird kann dies bei Geräten mit geringem Speicher kritisch sein. Ein ähnliches Problem tritt auf, falls häufig ein großer Teil des Systems geändert werden muss. In diesem Fall würde eine Lösung mittels rsync oder ähnlichen Tools eventuell mehr Sinn machen. rdiff-backup führt etwa inkrementelle Backups durch und bietet dazu noch die Möglichkeit die Anzahl der Versionen die behalten werden zu beschränken.

Do not use SSH.
Ein einfacherer Weg solch ein System aufzubauen wären SSH-Zugänge mit eingeschränkten Dateirechten für die Clients. Das Problem hierbei ist, dass Geräte Zugriff auf den Server bekommen. Ein Angreifer könnte sich mit dem private key des Clients zum Server verbinden. Es ist nicht aussergewöhnlich, dass in Betriebssystem-Kernen oder in System-Bibliotheken Sicherheitslücken entdeckt werden. Im schlimmsten Fall könnte ein Angreifer so die Dateien innerhalb des Repositories manipulieren. Die Clients würden automatischen den manipulierten Inhalten fetchen. Das manipulierter Inhalt ausgeliefert wird, ist auch in meinem Setup nicht ausgeschlossen, dazu muss der Angreifer aber über einen Zugang zu dem Server verfügen.

Das Problem

E-Mail ist alt und kaputt. Es gehört durch modernere Kommunikationsarten ersetzt. Warum? Was erwarten wir von Kommunikation über das Internet?

• Confidentiality, Integrity, Authentication
• Perfect Forward Secrecy (PFS)
• Plausible Deniability (PD)
• Asynchrone und synchrone Kommunikationsmöglichkeit
• Gruppenkommunikation
• Kollaboration
• Multimediale Kommunikation
• Dezentrale Struktur

Wenn wir von Verschlüsselung sprechen, dann ist damit Ende-zu-Ende-Verschlüsselung gemeint und nicht die Verschlüsselung der Transportwege. Das Gleiche gilt für Integrity und Authentication.

Wir können E-Mails verschlüsseln und digital signieren (z. B. durch Verwendung von OpenPGP). Leider kann dann für immer und von jedem bewiesen werden, dass wir diese Nachricht geschrieben haben. Ein weiteres Problem entsteht, wenn einer der Keys in falsche Hände gerät. Dann sind sämtliche bisher für ihn verschlüsselten Daten kompromittiert.

E-Mail ist langsam und immer asynchron. E-Mail-Verkehr kostet unnötig Zeit.[0]

E-Mail ist nicht kollaborativ.

E-Mail-Anhänge ermöglichen zwar die Übertragung multimedialer Inhalte, sind aber unglaublich ineffizient und ressourcenfressend.

Was gibt es also für Alternativen? Wie kann besser kommuniziert werden?

Soziale Netzwerke sind Privacy-Desaster.

Instant Messaging erfüllt die meisten Zwecke. Bei vielen Protokollen ist sowohl asynchrone als auch synchrone Kommunikation möglich. Confidentiality, Integrity, Authentication, Perfect Forward Secrecy und Plausible Deniability wird durch Verwendung von OTR[1] erreicht (allerdings nur bei Kommunikation mit einem Partner). Einige Protokolle erlauben Gruppenkommunikation durch Chaträume oder multimediale Kommunikation, wie das Übertragen von Dateien oder Video-/Audio-Telefonie.

Warum reichen bestehende Instant-Messaging-Systeme nicht aus? Was fehlt uns?

• Unterhaltungen in Echtzeit
• Flexibles Hinzufügen von Teilnehmern zur Gruppenkommunikation
• Verbessertes Sharing und Darstellung von Multimediainhalten
• Verschlüsselte, möglicherweise asynchrone, Gruppenkommunikation
  (mit PD und PFS)

Die ersten drei Punkte kann Googles Wave[2,3]. Das Problem der verschlüsselten Gruppenkommunikation mit den beschriebenen Bedingungen ist leider darin bisher nicht gelöst worden. Zudem existieren keine zufriedenstellenden Clients für Wave.

Wir wollen, dass die Infrastruktur nicht von einem einzigen Knotenpunkt abhängig ist. Dezentrale Struktur wird von den Protokollen, die E-Mail bzw. Wave zugrunde liegen, unterstützt. Fast alle IM-Dienste erlauben diese nicht.

Die Lösung

Wir sehen mehrere Lösungsansätze.

Komplett neues Protokoll mit Implementierung und Infrastruktur

Auch bekannt als: „Das Rad neu erfinden“. Machen wir nicht. Das Rad gibt es schon. Dieser Ansatz wäre sehr aufwändig und würde sich schwer etablieren.

Verwendung bestehender Protokolle

Bedingung ist, dass das Protokoll offen und leicht erweiterbar ist. Hier halten wir nur XMPP für sinnvoll. Der Vorteil dieser Lösung ist, dass genau die gewünschten Features implementiert werden können und keine Kompromisse notwendig sind. Voraussichtlich wird bereits bestehende Infrastruktur verwendet werden können.

Erweiterung von Wave

Wave hat bereits die meisten Features, welche wir uns wünschen. Verschlüsselung fehlt aber und es existieren keine guten Clients.

Der Plan

Wir evaluieren die letzten beiden Lösungsansätze und implementieren dann die sinnvollste Lösung. Dazu müssen wir zunächst XMPP und das Google Wave Federation Protocol verstehen.

Auf jeden Fall werden wir einen Client schreiben, der im Vergleich zu bestehenden Clients besser bedienbar ist und unsere beschriebenen Anforderungen erfüllt. Für Legacy-Clients ist eine (teilweise) Umsetzung der Features, beispielsweise durch Plugins, denkbar.

Die Unzufriedenheit mit vorhandenen Kommunikationsmöglichkeiten und die Idee diese zu verbessern schlummert schon seit einiger Zeit in uns. Hiermit möchten wir die Sache ins Rollen bringen. Stay tuned!

–nico, phil, matou

[0] http://www.heise.de/newsticker/meldung/Unternehmen-will-Mitarbeitern-die-E-Mail-abgewoehnen-1184596.html
[1] http://www.cypherpunks.ca/otr/
[2] http://wave.google.com/
[3] http://www.waveprotocol.org/

Mit dem VPN verbunden

Entgegen der Aussage von verantwortlichen Personen am Rechenzentrum der Universität Ulm ist es auch ohne Cisco-VPN Client möglich ins Universitäts-VPN zu gelangen – und das mit etwas Vorarbeit  recht komfortabel. In der folgenden Anleitung zeigen wir Dir Schritt für Schritt, wie Du das mit der aktuellen Ubuntu Version 9.10 komfortabel einrichtest.

Einleitung

Ziel dieses Projekts ist es, dass wir nutzerfreundlich und GUI-orientiert über den Gnome-Networkmanager ins Netz der Universität Ulm kommen, egal ob wir schon im WLAN vor Ort sind oder gerade Zuhause sitzen und mal wieder nicht an Dateien kommen, die nur über das Uninetz erreichbar sind.
Befinden wir uns gerade schon in der Universität, haben wir hiermit den Vorteil, auf die KIZ-Anmeldemaske beim Verbinden verzichten zu können. Zudem ist unser gesamter WLAN-Traffic auch gleich noch verschlüsselt.

Installation

Wir befinden uns in unserem Homeverzeichnis und erstellen uns ein temporäres Verzeichnis vpnc. Da die Anmeldung am VPN der Uni Ulm mittels hybrider Authentifizierung funktioniert, müssen wir selbst etwas am Quellcode modifizieren. Zuerst holen wir uns also den Quellcode und lösen eventuelle Abhängigkeiten auf.

cd vpnc
apt-get source vpnc
sudo apt-get build-dep vpnc

Möglicherweise werden wir darauf hingewiesen das Paket dpkg-dev zu installieren. Zusätzlich benötigen wir noch dieses Paket:

sudo apt-get install libssl-dev

Wir wechseln nun in das Verzeichnis ~/vpnc/vpnc-0.5.3 und öffnen die Makefile mit einem Editor unserer Wahl und entfernen die Raute vor diesen Zeilen und speichern die Datei.

#OPENSSL_GPL_VIOLATION = -DOPENSSL_GPL_VIOLATION
#OPENSSLLIBS = -lcrypto

VPN konfigurieren im Network-Manager-Applet

Jetzt noch ins Unterverzeichnis debian wechseln um die Datei changelog zu modifizieren. Damit wir unser frisch modifiziertes Werk bequem über den Paketmanager verwalten können müssen wir einen neuen Eintrag in diese Datei oben einfügen, am besten mit einer hohen Nummer. In unserem Fall sieht das so aus:
vpnc (ioexeption-ssl-2010.0.5.3-1-2010) unstable; urgency=low

* added ssl support for hybrid authentication on private network
-- Achim Strauss Mon, 15 Dec 2010 17:52:20 -0800

und dann das ganze Speichern.

Ein jungfräuliches Ubuntu hat vor dem nächsten Schritt gerne noch diese Pakete installiert

sudo apt-get install debhelper libgcrypt11-dev dpatch

Jetzt sind wir bereit das ganze aus dem Verzeichnis vpnc-0.5.3 heraus mit folgendem Befehl zu kompilieren:

fakeroot dpkg-buildpackage -b -uc

Am Ende des Prozesses sollte in ~/vpnc ein komfortabel zu installierendes Debian-Package mit Namen ioexeption-ssl-2010.0.5.3-1-2010_i386.deb stehen. Installiere dieses Paket und teste die erfolgreiche Installation mittels

vpnc --version

Die korrekte Installation erkennst du an der Ausgabe von

Built with openssl (certificate) support. Be aware of the license implications.

Prinzipiell sind wir nun bereit uns mit einem VPN zu verbinden, es fehlt aber noch an einem Plugin für den Networkmanager. Dieses bekommen wir, indem wir das folgende Repository zu unserer /etc/apt/sources.list hinzufügen.

deb http://ppa.launchpad.net/sroecker/ppa/ubuntu karmic main

Danach einfach noch diese Schritte ausführen:

sudo apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 588AC16B
sudo apt-get update
sudo apt-get install network-manager-vpnc

Der erste Befehl sagt aus, dass wir dem oben genannten Repository in Zukunft vertrauen wollen. Dieser Schritt ist nicht zwingend notwendig, schützt uns aber vor zukünftigen Warnmeldungen. Die beiden anderen Schritte sind jedoch essentiell für die Installation des Plugins.

Eingabemaske für Einstellungen des VPN

Konfiguration

Nun richten wir uns noch ein verstecktes Verzeichnis in unserem Homeverzeichnis ein ~/.vpnc . Hierein speichern wir das KIZ Zertifikat, sowie dieses Verbindungsprofil (aus dem Uninetz).

Über das Network-Manager-Applet können wir nun über VPN-Verbindung ->VPN-konfigurieren -> importieren im Verzeichnis ~/.vpnc das heruntergeladene Verbindungsprofil wählen. Die meisten Felder sind durch diese Vorgabe bereits ausgefüllt, der Rest ist wie auf diesem Screenshot mit den eigenen KIZ-Userdaten zu befüllen. Außerdem unter CA-File  die Zertifikatsdatei (KIZ-CA.crt) ebenfalls aus ~/.vpnc wählen.

Nutzung

Ab sofort kannst du dich mit wenigen Klicks über das Network-Manager-Applet → VPN-Verbindungen → <VPN-Name> in das VPN einwählen. Deine Passwörter werden nun auch bequem über den Gnome-Schlüsselbund verwaltet.

Eingerichtetes VPN auswählen