Treo 650: Von den Toten auferstanden

2004 erschien der Treo 650 in den USA. Seitdem hat sich viel geändert: Palm gibt es nicht mehr, Technologien haben sich weiterentwickelt, mit welchen das Gerät nicht umgehen kann.

So hat z.B. der eingebaute Browser massive Probleme mit aktuellen, per TLS gesicherten Webseiten. Was mit einem aktuellen Smartphone ohne Probleme funktioniert, wirft auf dem Treo viele Fehlermeldungen oder die Webseite kann überhaupt nicht aufgerufen werden. Der Grund dafür sind aktuelle TLS-Implementationen, welche auf PalmOS nicht verfügbar sind. So wurde kürzlich SSLv3 in der Linux-Bibliothek OpenSSL deaktiviert – das Protokoll mit dem der Treo noch klar kommen würde. Weiterhin sind Hash- und Verschlüsselungsalgorithmen mit der Zeit geschwächt oder gebrochen worden, sodass viele Webseiten diese Verfahren über TLS nicht mehr anbieten. Dies betrifft die vom Treo beherrschten Standards SHA-1, MD5, 3DES und RC4. Hinzukommt, dass eine Überprüfung des TLS-Zertifikats nicht mehr durchgeführt werden kann. Mittlerweile sind viele neue Root-CAs entstanden (die dem Treo unbekannt und deshalb abgelehnt werden) bzw es haben sich auch im Zertifikatssystem Technologien verändert. Diese Veränderungen haben zur Folge, dass der Treo 650 zwar ins Internet gelangt, Webseiten aber nur sehr eingeschränkt nutzbar ist.

Beim E-Mail Abruf sieht es nicht viel besser aus. Auch hier machen aktuelle Technologien Schwierigkeiten. Einzig der bewusste Verzicht auf Verschlüsselung kann, wenn der Provider es unterstützt, zum Erfolg führen. Allerdings ist diese “Lösung” stark mit Vorsicht zu genießen, da man so mindestens seinen E-mail Verkehr im Klartext durch das Internet schickt. Die Zugangsdaten müssen nicht zwangsweise unverschlüsselt übertragen werden. Je nach Anbieter und verwendeter Mail-Software kann das CRAM-MD5-Verfahren zur Absicherung des Passwortes genutzt werden. Noch gilt das Verfahren als nicht gebrochen und wird beispielsweise von Snappermail Enterprise unterstützt.

Doch wie kann man dem Treo noch etwas mehr “Internet beibrigen”? Dazu muss auf die vorhandenen Möglichkeiten aufgesetzt und passende Infrastruktur (eigener vServer/Server oder Webspace) vorhanden sein. Am einfachsten ist der Zugriff auf das Internet per Browser. Statt sich direkt mit dem Palm-Browser zu der Webseite zu verbinden, wird ein Web-Proxy (installiert auf einem Webspace oder vServer/Server) wie z.B. Glype zwischengeschaltet. Der Proxy ruft die Webseite ab und leitet sie an den Palm weiter. Der Proxy selbst muss dazu über eine ungesicherte HTTP-Verbindung oder über eine unterstützte TLS-Verbindung vom Palm aus aufgerufen werden. Dabei sollte man beachten, das der Datenverkehr zwischen Palm und Proxy unverschlüsselt erfolgt, d.h. man sollte es tunlichst vermeiden, sensible Daten über diesen Weg auszutauschen.

Der E-Mail-Abruf gestaltet sich deutlich komplizierter und kann nicht so einfach reaktiviert werden, wenn E-Mail-Anbieter wie GMX, GMail, web.de etc genutzt werden. Nur bei einer self-hosted-Lösung ist dies umsetzbar.
Noch bis vor ein paar Monaten konnte ich mit nginx einen E-Mail Proxy betreiben, welcher die von PalmOS bzw. Snappermail beherrschten Protokolle unterstützte. Da diese Verfahren seit dem Update durch OpenSSL global deaktiviert wurden, funktionierte auch diese Lösung nicht mehr. Die aktuelle Lösung basiert auf einem VPN-Tunnel, welcher vom Treo zum Server aufgebaut wird. Hier kommen zwei VPN-Protokolle in Frage: PPTP und IPSec. Für beide Varianten existieren VPN-Clients für PalmOS: Movian VPN für IPSec und Mergic VPN für PPTP. PPTP ist dabei die schwächere Wahl, da das Protokoll als gebrochen gilt. Ich habe mich trotzdem für PPTP entschieden, da die Einrichtung am Server zunächst einfacher und unkomplizierter war und es dann doch nicht ganz trivial ist, die Verbindung anzugreifen was zumindest Script-Kiddies da Leben erschweren sollte. Sollte die VPN-Verbindung gebrochen werden, sind die Zugangsdaten noch immer per CRAM-MD5 gesichert. Vielleicht versuche ich mich demnächst noch an einer IPSec-Verbindung, welche noch als sicher und ungebrochen gilt.
Der Mailabruf im Mail-Client erfolgt dann nicht über die normale Adresse des Mailservers, sondern über die interne IP der VPN-Verbindung. Der Haken an der Sache ist, dass diese Art von VPN-Verbindung von Netzwerkgeräten unterstützt werden muss. Dies ist gerade in Heimnetzen manchmal nicht der Fall. So habe ich es (noch) nicht hinbekommen, einen PPTP-Tunnel durch den Bluetooth-Access-Point blue2net zu tunneln. GRE-Pakete, welche für PPTP essentiell sind, werden nicht durchgeleitet.

Mit diesen zwei Methoden ist der Treo wieder etwas mehr nutzbar geworden und muss nicht in der Ecke verstauben. ;)

Note to self: selbstsignierte Zertifikate mit OpenSSL

Selbstsignierte Zertifikate mit eigener CA über OpenSSL:

Erstellen des CA-Keys:
openssl genrsa -out ca.key 4096 
openssl req -new -x509 -days 1825 -key ca.key -out ca.crt 

Erstellen und signieren eines CSR:
openssl genrsa -out server.key 4096 
openssl req -new -key server.key -out server.csr 
openssl x509 -req -days 1824 -in server.csr -CA ca.crt -CAkey ca.key -set_serial 01 -out server.crt

Mit Netz und doppeltem Boden – Backup für den vServer

Wer einen eigenen Server betreibt sollte auf jeden Fall eine Backup-Strategie fahren, um im Falle eines Crashes/Angriffes keine wichtigen Daten zu verlieren. Bis jetzt bestand meine Lösung aus einem NFS-Share, welches mein Hoster zur Verfügung stellte, und einem Scrip, welches den kompletten vServer in ein TAR-Archiv schob, komprimierte und verschlüsselte:


#!/bin/sh
mount $ADRESSEDESNFSSHARES /storage/ -t nfs
systemctl stop mariadb
key=`openssl rand 128 -hex`
echo $key > key
path=/storage/`date +"%d-%m-%y"`
mkdir $path
openssl rsautl -encrypt -inkey public.key -pubin -in key -out $path/key.`date +"%d-%m-%y"`.enc
rm key
tar -cO --exclude='/proc' --exclude='/sys' --exclude='/backup' --exclude='/storage' --exclude='buildroot.img' /* | pbzip2 -c | ccrypt -K $key > $path/backup.`date +"%d-%m-%y"`.tar.bz2.cpt
systemctl start mariadb
umount /storage

Was tut dieses Script? Es generiert einen 128 Bit langen Verschlüsselungsschlüssel, welcher mit einem öffentlichen Schlüssel verschlüsselt wird. Der Verschlüsselungsschlüssel wird zur (symmetrischen) Verschlüsselung des komprimierten TAR-Archives genutzt. Beides wird anschließend auf dem NFS-Share gespeichert. Damit das TAR-Archiv nicht zwischengespeichert werden muss, werden alle Vorgänge (Packen, Komprimieren und Verschlüsseln) durch Pipes miteinander verbunden. Der große Nachteil dieser Lösung ist, dass es sehr zeitaufwändig ist, eine einzelne Datei wiederherzustellen. Zuerst muss das Archiv entschlüsselt, dekomprimiert und entpackt werden, was entsprechend dauern kann.
Auf der Suche nach einer besseren Lösung bin ich über duplicity gestolpert. Das Tool bietet die Möglichkeit, verschlüsselte, inkrementelle und einfach wieder herzustellende Sicherungen zu erstellen.


#!/bin/sh
mount $ADRESSEDESNFSSHARES /storage/ -t nfs
#systemctl stop mariadb
PASSPHRASE='GPGSCHLÜSSELHIERREIN'
SIGN_PASSPHRASE='GPGSCHLÜSSELHIERREIN'
export PASSPHRASE
export SIGN_PASSPHRASE
duplicity --exclude /var/tmp --exclude /tmp --exclude /proc --exclude /sys --encrypt-key 987AAD58 --sign-key 987AAD58 -v 8 / file:///storage > /var/log/backup/backup.log
duplicity remove-older-than 3W file:///storage > /var/log/backup/backup_cleanup.log
#systemctl start mariadbi
unset PASSPHRASE
unset SIGN_PASSPHRASE
umount /storage

Die Handhabung ist relativ einfach. Zunächst erstellt man einen GPG-Schlüssel. Anschließend läuft bei mir obiges Script, gesteuert per Cronjob, alle zwei Stunden durch. Über duplicity remove-older-than 3W werden alle Sicherungen, welche älter als 3Wochen sind, gelöscht. Die Wiederherstellung von Dateien erfolgt über duplicity –file-to-restore. Im Moment macht die Lösung einen ganz soliden Eindruck. Hoffentlich tut sie das im richtigen Ernstfall weiterhin.
Ach ja:
Auf jeden Fall die GPG-Schlüssel und den zugehörigen Key extra sichern! Ohne ist das Backup nicht mehr zu entschlüsseln!

Androids Vollverschlüsselung und ein anderes Passwort

Wer unter Android die Vollverschlüsselung aktiviert, muss ein Passwort oder eine PIN festlegen, mit welchem das Gerät wieder entschlüsselt werden kann. Dummerweise wird dieser Schlüssel auch für die Sperrung des Gerätes verwendet, wodurch fast nur schwache Passwörter zum Einsatz kommen. Wer hat schon Lust jedes mal beim Einschalten ein komplexes Kennwort einzugeben? Je kürzer und weniger komplex das Kennwort ist, desto schneller und einfacher lässt sich die Vollverschlüsselung angreifen. Daher liegt es nahe, für beide Szenarien, Verschlüsselung und Displaysperre, verschiedene Kennwörter mit unterschiedlicher Komplexität festzulegen. Leider bietet dies Android nicht von Haus aus an. Wer sein Telefon gerootet hat, kann dies über Umwege trotzdem erreichen. Über die Konsole kann das Passwort der Verschlüsselung mit

vdc cryptfs changepw $neuespasswort

geändert werden. Man muss nur höllisch aufpassen, dass man das neue Passwort korrekt eingibt – eine zweite Abfrage, welche Tippfehler abfängt, gibt es nicht!