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.

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