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

Web-Browser und -Server… was reden die da eigentlich??? Server-Sockets mit nc

Wer sich mit Webservern und -browsern beschäftigt, wird irgendwann an den Punkt kommen, wo man einfach mal wissen will, „Was zur Hölle der Browser und der Server da genau bereden“

Tools wie wget helfen einem zwar, zu überprüfen, ob ein Server eine Datei wirklich ausliefert, aber viele Funktionen werden im HTTP-Header ausgehandelt und die Server reagieren dabei speziell auf die unterschiedlichen, browserspezifischen Anfragen.

Wenn es also so aussieht, als würde der Server einem Firefox andere Daten schicken, als einem Chrome, möchte man sicherlich wissen, ob es wirklich so ist und wie sich die Kommunikation generell unterscheidet.

Hier kann ein Trick helfen, über den ich kürzlich gestolpert bin. Er beruht auf dem Befehl nc (netcat), der in vielen Konstellationen hilfreich sein kann.

nc (netcat)

nc öffnet entweder eine Verbindung zu einem Server-Port (z.b. dem HTTP-Port (80) eines Webservers) und verhält sich dabei sehr ähnlich zu telnet.
Im Gegensatz zu telnet kann nc jedoch auch selbst einen Socket öffnen und auf eingehende Anfragen antworten. Hierfür wird der Switch -l verwendet.

Egal, in welcher Richtung die Kommunikation aufgebaut wird, verbindet nc immer die Standard-Eingabe (stdin) mit dem Kommunikationspartner.
Wird der Befehl also einfach so verwendet, können Sie direkt mit der Tastatur eingeben, was dem Kommunikationspartner gesendet werden soll.
Startet man auf einem Rechner ein lauschenden Server-Socket auf Port 54321:

# nc -l 54321

… kann man sich von einem anderen Rechner aus damit verbinden:

# nc hostname.des.servers 54321

Nun hat man eine Verbindung, die man zum Chatten verwenden kann.

Auf dem üblichen Weg lassen sich per Pipe auch die Ausgaben anderer Befehle über diese Leitung zu übertragen, statt die Tastatur Eingabe zu verbinden.
Startet man den Server z.B. so:

# ls -l | nc -l 54321

… bekommt man beim Verbinden mit dem Socket das aktuelle Verzeichnis, in dem der Server gestartet wurde angezeigt. Danach schließt sich die Verbindung und sowohl Server- als auch Client-Prozesse werden gestoppt.

Sehen was der Browser sendet:

So ist nc also schon nützlich: Man kann einen Server-Socket öffnen und im Webbrowser dessen Adresse eingeben. Im obigen Beispiel also http://localhost:54321/. Zwar wird im Browser so nicht unbedingt etwas sinnvolles angezeigt, weil unser nc-Server kein HTTP spricht, aber auf der Konsole können wir nun sehen, welche Anfrage genau der Browser an unseren Server geschickt hat:

GET / HTTP/1.1
Host: localhost:54321
Connecdern: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.109 Safari/537.36 Vivaldi/1.0.403.20
Accept-Encoding: gzip, deflate, sdch
Accept-Language: de-DE,de;q=0.8,en-US;q=0.6,en;q=0.4
Cookie: _pk_id.2478.1fff=bda69bf5b5894886.1457526065.1.1457526065.1457526065.

Dies ist nun aber nur eine einzelne Anfrage und wir können nicht die Antwort des Servers sehen, der uns eigentlich interessiert.

Umleiten einer Verbindung

Hier kommt nun eine weitere praktische Zutat ins Spiel: Named Pipes. Während wir mit dem Pipe-Symbol (Senkrechter Strich: |) nur die Ausgabe eines Programms mit der Eingabe des direkt folgenden Programms verbinden können, werden Named Pipes im Filesystem abgelegt und können auf diese Weise angesprochen. Diese Pipes werden mit dem Befehl mkfifo angelegt, sie verhalten sich dabei weitgehend wie Dateien.

Named Pipes können wir nun dazu verwenden, zwei nc-Prozesse miteinander zu verbinden: Einen, der auf Verbindungen vom Browser wartet, einen der eine Verbindung zu einem Webserver herstellt:

Anlegen der Named Pipe (der Name und Pfad können frei gewählt werden):

# mkfifo /tmp/proxyfifo

Zwei nc-Prozesse starten und verbinden

# nc -l -p 54321 </tmp/proxyfifo | nc server.domain.de 80 >/tmp/proxyfifo

Löschen der Pipe:

#rm /tmp/proxyfifo

Statt http://server.domain.de geben wir nun im Browser ein: http://localhost:54321.

Der Browser zeigt uns nun die Webseite des Servers an. Da unsere nc-Prozesse aber nur jeweils eine Verbindung aufbauen und sich danach beenden, werden wahrscheinlich Bilder und CSS-Dateien nicht vollständig geladen. Beherrschen Browser und Webserver beide „Keep-Alive“ werden jedoch durchaus mehrere Ressourcen übertragen bevor die Verbindung beendet wird – nur halt nicht alle.

Dies ist bis jetzt noch wenig sinnvoll, aber da die Verbindung nun durch unsere Hände geleitet wird, können wir uns einklinken, und mitlesen, was die beiden Gesprächspartner miteinander austauschen.

Belauschen der Verbindung:

# mkfifo /tmp/proxyfifo
# nc -l -p 8080 </tmp/proxyfifo | tee /dev/stderr | nc server.domain.de 8480 | tee /dev/stderr >/tmp/proxyfifo
# rm /tmp/proxyfifo

Der Einfachheit halber werden hier beide Kommunikationsrichtungen per tee zusätzlich auf der Standard-Fehlerausgabe (stderr) ausgegeben, was zum Mitlesen ausreicht.

In manchen Fällen möchte man darüber hinaus in die Kommunikation Eingreifen und die übertragenen Daten „on-the-fly“ manipulieren, auch dies ist mit diesem Ansatz möglich.

Da der Browser im obigen Beispiel glaubt mit „localhost“ zu kommunizieren, überträgt er in seinem HTTP-Request einen falschen Host, dies könnte man beispielsweise mit sed korrigieren wollen:

# mkfifo /tmp/proxyfifo
# nc -l -p 8080 </tmp/proxyfifo | sed -u "s/Host: localhost:8080/Host: rrzk.uni-koeln.de/g" | tee /dev/stderr | nc rrzk.uni-koeln.de 80
# rm /tmp/proxyfifo

Mit diesem Beispiel kann man die Webseite des RRZK über den Aufruf http://localhost:8080 laden und sich anschauen welche Daten ausgetauscht werden. (Wie erwähnt wird die Seite so nicht vollständig geladen).

Aufräumen:

Damit keine Bruchstücke liegenbleiben sollte man eine Named Pipe immer wieder neu anlegen und nach dem Aufruf direkt löschen.

Andere Anwendungsgebiete:

nc kann hier mit jeder Art TCP/IP-Verbindung umgehen, es ist also nicht auf Webkommunikation begrenzt. Besonders bei Anwendungen mit dauerhaft gehaltenen Verbindungen kann nc hier sein volles Potenzial ausspielen. Dies kann besonders Interessant sein bei:

  • Mail-Servern
  • Chat-Servern
  • Spiele-Servern
  • generell allem, bei dem man eine Serveradresse angeben muss

Sie können so rausfinden, welches Protokoll Ihr Netzwerkdrucker spricht und ob eine angeblich verschlüsselte Verbindung wirklich verschlüsselt ist (nc zeigt Binärdaten, wie verschlüsselte oder komprimierte Verbindungen und Dateiinhalte natürlich nur in Form von Datenmüll an).

Fazit:

Mit nc lassen sich auf viele Weisen Daten sammeln, die einem bei der Fehlersuche und -analyse hilfreich sein können.
Obige Beispiele sind nur ein erster Ansatz, sicherlich gibt es noch raffiniertere Kombinationen. Schreiben Sie gerne Ihre eignen Tricks zu diesem Thema in die Kommentare.

Die Zwickmühle beim Betreiben von verschlüsselten Netzdiensten aus Betreibersicht

Angesichts der Schwachstellen rund um bestimmte Verschlüsselungsarten (Poodle und Logjam waren die bekanntesten in letzter Zeit) hat man es als Betreiber schwer, die „optimale“ Konfiguration für Netzdienste zu finden, die verschlüsselte Kommunikation anbieten. Auf der einen Seite möchte man nach Möglichkeit Benutzer mit älteren Geräten, die noch nicht die neuesten Verfahren implementiert haben, nicht völlig von der Nutzung ausschließen, auf der anderen Seite gelten bestimmte Verfahren inzwischen als so unsicher, dass man diese als Serverbetreiber auf gar keinen Fall mehr anbieten möchte, um Nutzer nicht in trügerischer Sicherheit zu wägen.

Das gilt insbesondere dann, wenn als Szenario droht, dass ein Angreifer sich in die Verbindung zwischen Server und Client einklinken kann und dann dafür sorgt, dass die beiden eigentlichen Kommunikationspartner sich auf eine Primitiv-Verschlüsselung einlassen, weil der Angreifer vortäuscht, der jeweils andere Partner würde keine starke Verschlüsselung unterstützen („Downgrade-Attack“). In einem solchen Fall braucht der Angreifer dann nur noch die Primitiv-Verschlüsselung zu knacken anstelle der starken Verschlüsselung, die die beiden Kommpunikationspartner im Normalfall untereinander vereinbart hätten.

Webserver und andere Dienste

Weiter verkompliziert wird die Lage dadurch, dass Angriffsszenarien bei verschiedenen Netzdiensten unterschiedlich zu beurteilen sind. So sind Angriffe, die darauf beruhen, dass einer der Kommunikationspartner unfreiwillig dazu gebracht werden kann, häufig Datenpakete mit annähernd gleichem Inhalt zu senden, bei Webseiten bis zu einem gewissen Grad realistisch. Schafft es der Angreifer, das Opfer auf eine Webseite unter seiner Kontrolle zu locken, so sind automatisierte Datenabrufe durch eingebetteten Skriptcode denkbar, ohne dass es direkt auffällt. Bei anderen Diensten, beispielsweise E-Mail mit einem Mailclient, gibt es hingegen kein ernstzunehmendes Szenario, wie ein Angreifer von außerhalb den Computer des Opfers automatisiert dazu bringen kann, selbständig mit gewisser Regelmäßigkeit gleichartige Datenpakete zu verschicken. Das ist umso mehr eine Besonderheit des Webs gegenüber anderen Netzdiensten, weil das Angriffsziel „Session-Cookie“ auch nur im WWW-Bereich wirklich existiert.

Alte Software überall

Als wäre dieses Spannungsfeld nicht schon vertrackt genug, kann als weitere Schwierigkeitsstufe noch dazukommen, dass man nicht nur bei den fremden Kommunikationspartnern nicht die neuesten Verschlüsselungsverfahren voraussetzen kann, sondern dass man auch als Anbieter nicht all das nutzen kann, was theoretisch verfügbar ist. So steht am RRZK für den Betrieb von Webservern i.d.R. als Betriebsystem Red Hat Enterprise Linux 6 (RHEL6) zur Verfügung. Dieses bringt aber nicht die jeweils neuesten Programmversionen mit, sondern im Regelfall diejenigen Versionen, die bei Erscheinen des Betriebssystems aktuell waren, jedoch natürlich um in der Zwischenzeit bekanntgewordene Sicherheitslücken bereinigt.

Für RHEL6 bedeutet das ganz konkret, dass nur die Funktionen von openssl 1.0.1 zur Verfügung stehen (anstelle von openssl 1.0.2) sowie der Apache-Webserver aus der 2.2er Versionslinie (anstatt 2.4). Damit sind einige der Empfehlungen für Serverbereiter, wie Sie beispielsweise von den Entdeckern des Logjam-Problems gegeben werden, nicht umsetzbar. Das Definieren individueller sog. Diffie-Hellman-Parameter etwa ist erst mit den neuesten Versionen des Apache-Webservers (ab 2.4.8) möglich.

Empfehlung für Apache 2.2 unter RHEL6

Um nun unter RHEL6 einen Apache-Webserver zu betreiben, der Webseiten ausschließlich verschlüsselt (per https) ausliefert, und das unter den gegebenen Umständen mit einem als möglichst sicher geltenden Kompromiss, kann man folgende Einstellungen in der allgemeinen Apache-Konfiguration verwenden:


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

Das ist zunächst einmal wenig spektakulär und kaum anders als das, was von den Logjam-Entdeckern empfohlen wird. In der Praxis läuft es darauf hinaus, dass die hier vorgeschlagene Konfiguration keine Präferenz für AES-128-Verschlüsselung enthält, so dass von den meisten heutigen Clients eine AES-256-Verschlüsselung verwendet werden wird. Ob man in dem gegebenen Kontext (Abruf von Webseiten) nun AES-128 oder AES-256 den Vorzug geben sollte ist für mich nicht zu beurteilen und wird in der Praxis wohl auch kaum eine Rolle spielen. Die theoretische Angreifbarkeit von AES-256 gegenüber AES-128 (hier ein alter und bekannter Blogartikel von Bruce Schneider dazu) bezieht sich auf mögliche Related-Key-Angriffe und ist in dieser Frage von untergeordneter Bedeutung.

Lässt man die oben genannte Einstellung SSLHonorCipherOrder hingegen auf dem Standardwert off, statt sie wie empfohlen auf on zu setzen, so ändert sich in der Praxis bei den meisten Browsern wenig. Durch das Setzen von SSLHonorCipherOrder on sorgt man de facto nur dafür, dass Benutzer mancher Versionen des Internet Explorers unter Windows 7 zu ihrem Glück gezwungen werden und auch bei ihnen eine Verbindung mit Forward Secrecy aufgebaut wird. Auf die Belange von Nutzern, die auch heute noch die extrem veraltete und per se unsichere Kombination von Internet Explorer 6 und Windows XP einsetzen, wird hier keine Rücksicht mehr genommen. Diese früher nicht ganz kleine Gruppe an Webseitenbesuchern machte in der Vergangenheit viele faule Kompromisse notwendig.

Dem Browser den Weg zur Verschlüsselung weisen

Legt man Wert darauf, in dem beliebten SSL-Servertest von Qualys besonders gut abzuschneiden, ist SSLHonorCipherOrder on unbedingt notwendig. Jedoch reicht das Setzen dieser und der anderen allgemeinen Verschlüsselungseinstellungen nicht aus. Für ein gutes Testergebnis muss man auch dafür sorgen, dass Besucher ausschließlich verschlüsselt mit dem Server kommunizieren. Solange unverschlüsselte Kommunikation im Web der Normalfall ist, sind dazu noch ein paar weitere Anstrengungen in der Apache-Konfiguration notwendig.

Webseitenbesucher, die – aus welchem Grund auch immer – eine unverschlüsselte Verbindung zum Server aufbauen möchten, müssen also von diesem Vorhaben abgehalten werden. Verwendet man dazu virtuelle Hosts in der Apache-Konfiguration, so kann man die Besucher, die keine Verschlüsselung verwenden, per


<VirtualHost *:80>
  RedirectMatch permanent (.*) https://meinhostname.uni-koeln.de$1
</VirtualHost>

umlenken. Für Named Virtual Hosts wäre hier natürlich noch eine weitergehende Konfiguration nötig. Gezeigt werden soll anhand dieses Konfigurationsschnipsels eigentlich nur, dass man die Besucher am besten mit einer dauerhaften Umleitung (permanent) auf die verschlüsselte Version der Website lenkt.

https und nur https, in guten wie in schlechten Zeiten

Als Kür sendet man dann noch die Information an die Browser der Webseitenbesucher, es in Zukunft gar nicht erst über eine unverschlüsselte Verbindung zu probieren, sondern ausschließlich per https mit dem Server zu kommunizieren:


<VirtualHost *:443>
  # hier stehen normalerweise Einstellungen wie ServerName, DocumentRoot etc.
  
  # vvv Einschalten von HSTS aka HTTP Strict Transport Security, RFC 6797
  Header always set Strict-Transport-Security: max-age=31536000
  # ^^^ Strict Transport Security, funktioniert mit Apache 2.2.15
</VirtualHost>

In diesem Beispiel wird der abrufende Browser instruiert, dass die Information, mit diesem Server nur verschlüsselt zu kommunizieren, ca. ein Jahr lang (31536000 Sekunden) gültig ist. Dies kann man zum Glück auch schon mit dem bei RHEL6 mitgelieferten Webserver Apache 2.2.15 so einstellen.

Mit den auf diese Weise optimierten Einstellungen erhält der Webserver dann von dem erwähnten SSL-Test die Bestnote A+ attestiert, vorausgesetzt die übrigen Einstellungen (zum Zertifikat und der Kette der Zwischenzertifizierungsstellen etc.) sind ebenfalls in Ordnung. Diese Einstellungen sind aber nicht spezifisch für RHEL6, daher soll hier darauf nicht weiter eingegangen werden.

Streaming auf AppleTV über Subnetzgrenzen hinweg

airplay_appletvMit dem Update auf Softwareversion 6.1 bekam das AppleTV in Verbindung mit iOS 7.1 und höher ein neues Feature: AirPlay Discovery via Bluetooth. Dies ermöglicht nun viel einfacher die Verbindung zwischen AppleTV und AirPlay-Klienten, wenn sich diese nicht im selben IP-Subnetz befinden. Einrichtungen mit vielen IT-Anwendern sind gezwungen, einzelnen Abteilungen oder Arbeitsgruppen eigene getrennte IP-Subnetze zuzuordnen. Oft wird dem WLAN-Netz auch ein eigener IP-Bereich zugewiesen. Befindet sich das AppleTV dann netztechnisch im IP-Bereich einer Arbeitsgruppe, müssen die Klienten einige Barrieren überwinden.

Haben beide Geräte Bluetooth aktiviert und die aktuelle Softwareversion installiert, wird auf dem iPad/iPod/iPhone das AppleTV angezeigt. Unter Umständen ist jedoch keine Kommunikation zwischen den Klienten möglich. AirPlay erfordert, dass vom AppleTV eine neue TCP/UDP-Session zum Endgerät aufgebaut werden kann, obwohl die ursprüngliche Session vom Endgerät initiiert wurde.

Damit schließt AirPlay Umgebungen aus, die NAT mittels Port-Addresstranslation durchführen. Diese Hürde kann man jedoch durch Aufbau einer VPN-Verbindung überwinden. Verteilt das VPN-Gateway jedem Endgerät eine eigene IP, kann so doch AirPlay eingesetzt werden.

Nun müssen gegebenenfalls noch Freigaben eingerichtet werden, wenn die Subnetze durch eigene Firewalls abgesichert sind. Leider verwendet AirPlay dynamische Ports, so dass ganze Bereiche freigegeben werden müssen. Dabei verläuft die Kommunikation von hohen Ports (49152 – 65535) zu hohen Ports.

Folgende Freigaben sollten eingerichtet werden:Firewallregeln

Je nach Firewall-Typ müssen auch die Rückantworten zu den fünf Freigaben eingetragen werden, also Quellnetz/-port und Zielnetz/-port vertauscht.

Mit diesen Freigaben sollte AirPlay funktionieren. Wir konnten mit den gewählten Einstellungen Videos, Musik und den Bildschirminhalt erfolgreich auf das AppleTV streamen.

Projekt Mepevea – D’r Zoch kütt!

Als umweltbewusster oder zumindest geiziger Mitarbeiter des Öffentlichen Dienstes verzichtet man in der Regel bei längerer Anfahrt zum Arbeitsplatz auf den privaten PKW und nimmt freudig am öffentlichen Personennahverkehr (ÖPNV) teil. Sprich: Die Deutsche Bahn (und in Köln auch die KVB) ist unser Freund! Gerüchteweise sind die bereitgestellten Verkehrsmittel nicht immer dann vor Ort, wenn man es laut Fahrplan erwarten könnte. Damit man die daraus resultierende Wartezeit nicht am Bahnsteig, sondern am Frühstückstisch bzw. im bequemen Bürosessel verbringen kann, sind aktuelle Informationen über die Verspätungen unerlässlich.

Nun hat sich in der Vergangenheit der Service der DB dahingehend deutlich verbessert. So sind die Verspätungsinformationen inzwischen minutengenau und in Realzeit sowohl im Web als auch mittels der App „DB Navigator“ abrufbar. Der o.g. Mitarbeiter des Ö.D. ist allerdings nicht nur geizig (jaja, und umweltbewusst), sondern auch klickfaul und noch dazu ein Spielkind. So kam ich auf die Idee, sowohl in meinem trauten Heim als auch im Büro mittels ohnehin vorhandener Technik einen (für mich) optimalen Anzeigebildschirm zu basteln.

Dieser sollte nicht nur die aktuellen Verspätungen meiner Zugverbindungen, sondern auch weitere interessante Informationen anzeigen, genauer gesagt: Aktuelle Nachrichten, Wettervorhersage und (zuhause) zusätzlich das Kamerabild einer per WLAN verbundenen IP-Kamera. Als Hardware kamen ein günstiger und dank Notebook-Anschaffung ohnehin kaum noch gebrauchter PC-Bildschirm sowie zeitgemäß ein Raspberry Pi zum Einsatz. Das System sollte in jedem Fall ohne weitere Peripherie, speziell ohne Maus und Tastatur, auskommen. Softwareseitig setzte ich daher auf Google Chrome im Kiosk-Modus. Mittels der Erweiterung „Easy Auto Refresh“ kann man dafür sorgen, dass Chrome die angezeigte Seite automatisch einmal pro Minute neu lädt. Das Kamerabild läuft ohnehin im Streaming-Mode.

Der graphische Desktop des Raspi musste so eingestellt werden, dass er sich nicht automatisch abschaltet. Die Kontrolle über die Anzeige sollte ausschließlich per Ein/Aus-Knopf des Monitors ablaufen. Dies erreicht man über die eine Einstellung in LightDM.

Da ich mir die Installation und Konfiguration eines Webservers sparen wollte, verwende ich eine einfache lokale HTML-Seite auf dem Raspi. Die beiden gewünschten Elemente „Aktuelle Nachrichten“ und „Wettervorhersage“ sind sehr leicht über passende Widgets realisierbar. Ich habe hierzu die Angebote von wetterdienst.de und rp-online genutzt, es gibt jedoch zahlreiche weitere Anbieter.

mepevea

Richtig interessant wurde es dann bei der Einbindung der Verspätungsanzeige. Wie ich feststellen musste, bietet die Bahn leider keine geeignete API zu diesem Zweck. Mir blieb nichts anderes übrig als die entsprechende Webseite zu parsen. Diese Erkenntnis war die Geburtsstunde von Projekt „Mepevea“ (MEin PErsönlicher VErspätungsAnzeiger).

Wie erwähnt wollte ich auf die Installation und den Betrieb eines Webservers verzichten. Die Anzeige soll ja ohnehin nur für mich persönlich laufen. Daher musste ich die eigentliche Logik nebst Parser in ein Pythonskript packen, welches per Cronjob aufgerufen wird (ja, ich arbeite unter Linux und ignoriere Windows seit Jahren – die Portierung sollte aber kein großes Problem darstellen). Als Basismodul für den Parser dient natürlich „BeautifulSoup“, darüber hinaus werden urllib zum Abruf der Seite und einige weitere Module benötigt. Der Start lautet also:

#!/usr/bin/python
# -*- coding: utf-8 -*-
import bs4, urllib2, time, fileinput, sys, urllib

„fileinput“ verwende ich, um später den <div>-Block im HTML durch die korrekten Daten auszutauschen, z.B.:

for line in fileinput.FileInput("/home/pi/anzeige/bahnlinks.html",inplace=1):
if line.startswith('<div id="bahn">'):
   line = text
   sys.stdout.write(line)

Natürlich macht es Sinn, abhängig vom Wochentag und der Tageszeit die Anzeige zu variieren (Hinfahrt, Rückfahrt, Abend/Wochenende), also z.B.:

timestamp = time.localtime(time.time())
if timestamp[6] > 4:
   textlist.append("<b>Bahnanzeige erst am Montag wieder! Schönes Wochenende!</b>")

Hier wird schon klar: Individuelle Anpassung ist unerlässlich und ich kann die Beispiele nur anreißen. Keine Sorge: Am Ende werde ich als „großes Beispiel“ mein komplettes Skript bereitstellen.

Zentrales Element des Skriptes ist die Parserfunktion. Sie erhält als Parameter die URL der Bahn (dazu später) und jagt sie durch BeautifulSoup:

def parser(url):
   page = urllib2.urlopen(url).read()
   soup = bs4.BeautifulSoup(page)

Man möge mir an dieser Stelle glauben, dass wir die spannenden Inhalte erhalten, wenn wir nach den Keywords, genauer gesagt den <td>-Klassen „overview timelink“ und „overview tprt“ suchen:


zeilen = soup.find_all('td', {"class" : "overview timelink"})
verspaetungen = soup.find_all('td', {"class" : "overview tprt"})

Schon hier erkannt man, wo das größte Problem unserer schönen Bastelei liegt: Sollte die Bahn die Klassennamen aus irgendwelchen Gründen ändern, funktioniert natürlich nichts mehr. Das gleiche gilt für die URLs und die HTML-Struktur. Genau aus diesem Grund gibt es ja i.d.R. kapselnde APIs, aber die stehen hier wie gesagt nicht zur Verfügung.

Standardmäßig erhält man von der Bahn die nächsten drei Züge ab dem definierten Zeitpunkt. Ich habe die finale Version noch so erweitert, dass man dies variieren kann, aber das würde hier zu weit führen. Ebenso müsste ich nun eigentlich auf die Details von BeautifulSoup eingehen, um den folgenden Codeblock zu erläutern. Aber auch dies möchte ich mir sparen und auf die gute Online-Dokumentation des Moduls verweisen. Unsere Verbindungen sowie die aktuellen Verspätungen erhalten wir so:


parsedtext = ''
zaehler = 0
for zeile in zeilen:
   for zelle in zeile.children:
      parsedtext += zelle.contents[0]
   parsedtext += '<span style="color: red;">'
   for verspaetung in verspaetungen[zaehler].children:
      if str(verspaetungen[zaehler]).count("okmsg") > 1 or str(verspaetungen[zaehler]).count("red") > 1:
         parsedtext += verspaetung.contents[0]
         break
   parsedtext += '</span>'
   zaehler += 1

Ich bin mir zu 99% sicher, dass dies nicht die eleganteste Version ist, um die Informationen zu erhalten und aufzubereiten. Aber sie funktioniert. Wer das Ganze kürzer, schöner und verständlicher hinbekommt, ohne dass die Funktionalität leidet, möge sich bei mir melden.

Kommen wir nun zu den benötigten URLs. In einer ersten Version hatte ich pro Zug eine URL auf Basis des Bahntools „query2.exe“ verwendet, die auch deutlich einfacher zu parsen war (Anmerkung: Bitte von der Endung „.exe“ nicht täuschen lassen: Es handelt sich um einen Webservice, nicht um ein lokales Programm.). Leider musste ich feststellen, dass die Bahn bei jeder (geplanten) Mini-Fahrplanänderung die URL komplett verändert. Auf Dauer war das also leider keine Lösung. Stattdessen verwende ich nun die „Vorstufe“ namens „query.exe“. Diese hat klar definierte und – hoffentlich – dauerhaft beständige Parameter. Als Parameter benötigen wir den Code des Startbahnhofs, den Code des Zielbahnhofs und die Startzeit.

Während die Startzeit natürlich jedem selbst überlassen bleibt und einfach in der Form hh:mm verwendet wird, muss man sich die Codes (sog. IBNR) der Bahnhöfe einmalig heraussuchen. Dies geht zum Glück sehr einfach mittels einer Onlinesuche.

Lautet die IBNR des Startbahnhofs bspw. 8000208, die des Zielbahnhofs 8000133 und die gewünschte Startzeit ist 17:00 Uhr, lautet die gesuchte URL:

http://reiseauskunft.bahn.de/bin/query.exe/dox?S=8000208&Z=8000133&time=17:00&start=1

Damit lässt sich nun für jede beliebige Verbindung und Kombination von Tageszeiten ein passender Anzeiger (eben ein „Mepevea“) bauen.

Für weitere Ideen, Verbesserungsvorschläge etc. bin ich jederzeit dankbar. Und wenn jemand die Bahn überreden könnte, doch mal eine entsprechende API bereitzustellen, das wäre ein Traum. 😉

Wie versprochen: Den vollständigen Text des Skriptes sowie eine Beispiel-HTML-Seite findet man unter http://dl.distinguish.de/mepevea.zip

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:

  1. Gut auf die Backup-Codes aufpassen.
  2. 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.

Die Qual der (Format-)Wahl: Online File Conversion Tools

So ein Pech! Da besucht einen ein Freund, Familienmitglied o.ä. und hat die Fotos seiner letzten Urlaubsreise in einer schönen Präsentation auf dem USB-Stick dabei, und als man die Datei auf seinem eigenen PC öffnen will, stellt man fest, dass es sich – „Ach ja! Ich hab das mit irgendsoeinem Programm auf ‘nem Mac erstellt!“ – um eine Datei im Keynote-Format handelt. Windows- und Linux-Betriebssysteme haben also keine Chance die Datei zu öffnen.
Wahlweise verlege man dieses Vorkommnis in den Veranstaltungsraum einer Tagung: Da hat man seinen Vortrag mit dem Programm „Pages“ auf einem Mac erstellt, aber es ist nun kein Mac in der Nähe, mit dem man die Datei öffnen und ausdrucken könnte… nota bene: Beide Formate – das Pages- und das Keynote-Format – können weder mit Powerpoint noch mit Word oder anderen gängigen Office-Programmen (OpenOffice, LibreOffice usw.) geöffnet oder konvertiert werden.

Die IT-affinen Leser wundern sich nun vielleicht oder halten diese Beispiele für arg konstruiert, aber: Solche Fälle treten (im Supportgeschäft) tatsächlich hin und wieder auf. Der Benutzer hat eine Datei, die er nirgendwo öffnen oder konvertieren kann – er kann sich selbst nicht helfen, weil er nicht weiß, wo und wie. Und so etwas trifft nicht nur Ausnahmsweise-Mac-User, sondern auch die, die vergessen/versäumt haben, die Datei zum Exportieren in ein anderes, gängigeres Austauschformat (PDF etc.) umzuwandeln.

In solchen Fällen, wo der eigene Computer oder der einer helfenden Person in der nächsten Umgebung nicht in der Lage ist, die entsprechende Datei zu konvertieren, können so genannte „Online File Conversion Tools“ helfen (an einer angenehm klingenden, sinnvollen Übersetzung dieser Bezeichnung ins Deutsche möge sich der Leser gern die Zähne ausbeißen). Man muss nicht mehr tun als eine Webseite aufrufen, die die Konversion einer ganzen Reihe verschiedener Formate ermöglicht. Im Folgenden werden einige solcher Onlinedienste vorgestellt:

Zamzar

Wer zum ersten Mal zamzar.com aufruft, wird zunächst von der Fülle der unterstützten Dateiformate erschlagen. Mehr Dateiformate bietet derzeit augenscheinlich kein weiterer entsprechender Dienst. Von Dokumentformaten und Grafiken über Musik und Videos bis hin zu ebook-Formaten, komprimierten Dateien (wie zip und bz2), ja sogar Auto-CAD-Dateien lässt sich dort eine Riesenpalette von Dateiformaten umwandeln.

Online-Dienst zamzar.comWer spontan eine Datei konvertieren will, wird auf der übersichtlichen Seite durch die vier nötigen Schritte geführt: Man lädt seine Datei hoch (es werden alle kompatiblen Dateien bis zu einer Größe von 100 Megabyte angenommen), wählt im zweiten Schritt das entsprechende Zielformat aus, gibt in Schritt drei die E-Mail-Adresse an, zu der die dann konvertierte Datei gesendet wird. Im letzten Schritt muss der Benutzer den Terms of Service zustimmen…
… die es aber in sich haben: Wer denkt, dass seine Dateien in irgendeiner Form verschlüsselt übertragen werden, irrt. Zumindest lässt sich ohne die kostenpflichtige Einrichtung eines Zamzar-Accounts (der einem außerdem bis zu einem Gigabyte Onlinespeicherplatz für seine konvertierten Dateien zur Verfügung stellt) gar nichts verschlüsseln. Nur der „Business-Dataplan“ (einer von drei verschiedenen Accounttypen) mit 49 Dollar/Monat bietet SSL-verschlüsselte Übertragung (128 bit). Die Datei selbst kann aber nicht verschlüsselt werden. Laut den Terms of Service kontrolliert das Unternehmen die konvertierten Dateien nicht auf deren Inhalt. Aber ob und – wenn ja – wie neugierig die Firma Zamzar, die ihre Server in den USA stehen hat, nun wirklich ist, kann man nur mutmaßen.

Youconvertit

Das sich noch im Beta-Stadium befindende Youconvertit unterstützt ebenfalls eine Reihe von Formaten, und auch dort wird dem User die konvertierte Datei per E-Mail zugesandt. Außerdem stellt der Dienst einen gesonderten Bereich zur Konvertierung von Youtube- und anderen Online-Videodiensten bereit. Hierzu muss nur der Link zum gewünschten Video angegeben werden. Nach einem Klick auf „Download it“ wird einige Sekunden später das umgewandelte Video zum Download bereitgestellt. Der User hat Auswahlmöglichkeit zwischen 3GP-Filmen in niedriger Qualität (geeignet für Handys und Smartphones), Flash-Videos in geringer und mittlerer Qualität sowie MP4-Dateien. Auch der WEBM-Standard wird unterstützt.

youconvertit - online file conversionHinweis: In Deutschland aus Lizenz- und Rechtsgründen nicht erreichbare Videos können über die youconvertit-Seite nicht geladen werden.
Im Vergleich mit anderen Video-Convert-Websites ist das Angebot von youconvertit nicht unbedingt herausragend. Im Bereich Video-Download bieten viele andere Dienste – darunter z.B. video2mp3.net oder filsh.net – sehr viel mehr. Das gilt auch für die Menge der anderen unterstützten Dokument-, Grafik- oder Musikformate: youconvertit schneidet eher durchschnittlich ab. Auch gibt es dort keinerlei Verschlüsselungsmöglichkeit – auch nicht nach Bezahlung. Immerhin unterstützen die kostenpflichtigen Premium-Accounts Dateigrößen von bis zu einem Gigabyte.

Online Convert

Dieser Dienst stellt die konvertierten Dateien für 24 Stunden zum Download zur Verfügung. Nach dieser Frist – oder nachdem die Datei zehnmal heruntergeladen wurde – wird die Datei automatisch gelöscht und steht nicht mehr zum Download bereit.

online-convertBei online-convert.com gibt es erfreulich viele Parameter, die sich einstellen lassen. Beispielsweise im Bereich Musik-Dateien: So ist bei der Umwandlung in eine MP3-Datei die Bitrate von 8 bis 320 kbps konfigurierbar – wünschenswert wäre, wenn dort auch VBR zur Auswahl stünde.
Interessant: Nach der Konversion wird auf der entsprechenden Webseite ein QR-Code bereitgestellt, der einen Link zur Downloadseite enthält: eine einfache Möglichkeit zur Weitergabe der Datei – natürlich wird man dort (wie auch bei anderen Online Conversion Diensten) darauf hingewiesen, dass man mit dem Teilen der Datei keine Urheber- oder sonstigen Rechte verletzen darf.
Verschlüsselungsmöglichkeit mit 256 bit für Up- und Download erhält man auch dort gegen Geld. Schön ist, dass dort kein besonders teurer Kontrakt abgeschlossen werden muss, sondern der Nutzer mittels eines fünf Dollar teuren „24-Stunden-Passes“ kurzfristige Möglichkeit zur Verschlüsselung hat. Weiterhin ist nach dem Kauf des 24-Stunden-Passes die Grenze der Dateigröße von 100 Megabyte auf 800 MB angehoben.
Interessant ist bei diesem Dienst die Möglichkeit zur Integration der online-convert.com-Dienste in die eigene Webseite. Sogar eine „File converter API“ inklusive Dokumentation steht dort bereit.

Free File Converter

free file converterDer Anbieter des Free File Converter kennt sich der Selbstbeschreibung nach besonders gut mit Nachrichten-Webseiten aus: Er ermöglicht das Konvertieren und den Download von Videos beispielsweise von spiegel.de oder auch von guardian.co.uk. Auch stehen dem Nutzer eine umfangreiche Liste weiterer Formate zur Verfügung. Leider kann man – natürlich bis auf das Ausgabeformat selbst – keinen Einfluss auf Ausgabequalität, Bitrate oder ähnliche Einstellungen nehmen. Auch in sonstiger Hinsicht hat dieser Dienst nicht allzuviel zu bieten – außer, dass er sich die Konversion von Videos dieser Nachrichtenseiten auf die Fahnen schreibt.

Fazit

Wer dringend eine Datei benötigt, sie aber nicht mit den auf seinem Computer installierten Programmen öffnen kann, kann die Online-Konversions-Dienste gezielt nutzen, um die Dateien in ein gewünschtes Format umzuwandeln. Aus Sicht des Datenschutzes gilt aber für sämtliche Dienste das gleiche Problem: Genau wie bei Online-Storage-Diensten wie Dropbox u.ä. weiß der Nutzer nicht, was genau mit seinen Daten geschieht. Die Dateien landen auf – meist in den USA ansässigen – Servern, und was genau nun von Seiten des Anbieters mitgelesen werden kann/wird, kann man nur mutmaßen. Außer Zamzar äußert sich keiner der beschriebenen Dienste über die Sicherheit seiner Daten, und auch Zamzar bleibt bei seinen Angaben in den Terms of Service recht vage. Bis auf den Übertragungsweg ist von Verschlüsselung keine Rede.
Mit anderen Worten: Man muss sich im Klaren sein, dass man seine zu konvertierenden Dateien mit einer Firma teilt. Was mit den Daten passiert, weiß man nicht. Bevor man also seine Steuererklärung oder die letzte Telefonrechnung (samt Einzelverbindungsnachweis) dort in ein anderes Format umwandeln lässt, sollte man sich fragen, ob man nicht doch auf die herkömmliche Art und Weise vorgehen will: „OpenOffice“ ist ein gutes Werkzeugt für die Konversion von Textdateien/Dokumenten – inklusive PDF-Export, das kostenlose „Free Studio“ dient zum umwandeln vieler Arten von Musik- und Videodateien. Und die Freeware „Gimp“ öffnet und speichert eine ganze Reihe von Grafikdateien.
Ein Problem hat man nur, wenn man seine Dokumente z.B. mittels der Mac-Programme „Pages“ und „Keynote“ erstellt hat: Die damit erstellten Dokumente lassen sich ausschließlich aus diesen Programmen heraus exportieren – z.B. als Word-, Powerpoint- oder PDF-Datei.

Ist aber ein solches Programm nicht vorhanden oder hat man keine datenschutztechnischen Bedenken, können Online-Konversions-Dienste eine schnelle und spontane Hilfe sein. Das oben zuerst genannte Zamzar erscheint wegen seiner vielen unterstützten Dateiformate als die beste Wahl.