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. ;)

HTTP-BASIC-AUTH nach Umleitung auf HTTPS

Eine HTTP-BASIC-AUTH-Authentifizierung sollte man nicht unverschlüsselt durchs Netz jagen. Doof ist es, wenn die Umleitung per .htaccess erst nach der Authentifizierung greift, da die erste Anfrage über HTTP läuft, von der Authentifizierung abgefangen wird und erst danach umgeleitet wird.
Eine Möglichkeit dies zu umgehen sieht so aus:

SetEnvIf %{SERVER_PORT} ^80$ IS_NON_SSL

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

AuthUserFile /pfad/zur/.htpasswd
AuthName "HTTP-BASIC-AUTH über TLS"
AuthType Basic
require valid-user
Allow from env=IS_NON_SSL

via http://stackoverflow.com/questions/10267102/apache-htaccess-redirect-to-https-before-asking-for-user-authentication

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

Let’s encrypt!

Seit einiger Zeit bietet “Let’s encrypt” seine SSL-Zertifikate in einer geschlossenen Beta-Phase an.
Die CA möchte schnell und einfach Zertifikate für jeden anbieten. Dies geschieht über ein Tool, welches über die Shell ausgeführt wird. Es kümmert sich um die Erstellung des Private-Keys, des CSR, die Validierung der Domain und die Erzeugung des Zertifikates.
“Let’s encrypt” wird direkt aus den GIT-Repos heruntergeladen und ausgeführt. Dabei werden z.T. noch benötigte Pakete nachinstalliert.
Zertifikate werden anschließend über
systemctl stop httpd
cd letsencrypt
./letsencrypt-auto --agree-dev-preview --rsa-key-size 4096 --server https://acme-v01.api.letsencrypt
.org/directory certonly
systemctl start httpd

angefragt. Dabei wird über Port 80 des Servers kommuniziert, was ich etwas unschön finde, da man vorher einen laufenden Webserver beenden muss.
Die Zertifikate sind nur 90 Tage lang gültig, danach müssen sie erneuert werden. Dies kann automatisch über einen Cronjob geschehen, ein weiteres Eingreifen durch den Benutzer ist nicht mehr nötig.
./letsencrypt-auto --agree-dev-preview --renew-by-default --server https://acme-
v01.api.letsencrypt.org/directory -d johnassel.de -d www.johnassel.de certonly
erneuert schon vorhandene Zertifikate. Auch hier muss ein laufender Webserver für den Vorgang beendet werden.
Leider kann man “Let’s encrypt” nicht schon vorhandene CSRs signieren lassen. Diese Schritte übernimmt die Software. Mir wäre es lieber, wenn ich Key und CSR selbst generieren könnte, einen Einfluss kann man aktuell auf die Länge des Schlüssels wohl noch nicht haben.
Auch bietet “Let’s encrypt” die Möglichkeit, direkt die Konfiguration von Apache etc für die generierten Schlüssel und Zertifikate anzupassen. Irgendwie habe ich dabei Bauchschmerzen, wenn eine Software versucht meine Konfiguration anzupassen.
Mit entsprechenden Scripten sollte es aber kein Problem sein, den Vorgang der Zertifikaterstellung so zu scripten, dass “Let’s encrypt” nicht noch in der Konfiguration rumwurschteln muss.

SUN iLOM, Remote Console und veraltete Verschlüsselungsprotokolle

Eine Remote Console am Server ist gut und schön, wenn sie denn erreichbar ist. SUNs Remote Console unter iLOM wird, zumindest in den älteren Versionen, über Java angesprochen, die Verbindung ist mit SSLv3 gesichert. SSLv3 ist unsicher und sollte daher nicht verwendet werden. Neuere Java JREs bieten SSLv3 nicht mehr an, die Verbindung zur Remote Console schlägt daher mit “No appropriate protocol (protocol is disabled or cipher suites are inappropriate)” fehl.
Und jetzt?
Das Protokoll kann über den Parameter
jdk.tls.disabledAlgorithms=SSLv3
in der java.security des JREs (bei mir wars /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.65-4.b17.fc23.x86_64/jre/lib/security/java.security) reaktiviert werden, damit funktioniert auch die Remote Console wieder.

DD-WRT 19xxx+OpenVPN = Meeeeeeh!

Bis gestern lief DD-WRT auf dem Linksys E2000 noch auf Build 14929. Da diese schon etwas älter war (März 2011 oder so), ging es gestern ans Upgrade auf Version 19519.
Neuere DD-WRT Builds müssen nicht mehr speziell für den E2000 angepasst werden, die neuen -nv60k.bin Versionen funktionieren auch. Allerdings kann nicht einfach auf eine solche Version aktualisiert werden. Hier muss ein Umweg über eine E2000-Mini-Build gegangen werden. Erst dann lässt sich die Firmware auf nv60k flashen. Während frühere Big-Builds (die ich bis jetzt immer installiert hatte) noch gut mit dem E2000 zusammenspielten, sind jetzige Versionen wirklich “Big”, d.h. sie sind zu groß und passen nicht mehr in den Speicher des Routers (8MB) m(
Da für meine Zwecke die OpenVPN Version reicht (Alternativ funktioniert auch “Mega”) und diese klein genug ist, fiel meine Wahl auf diese (dd-wrt.v24-19519_NEWD-2_K2.6_openvpn-nv60k.bin). Nach der Installation musste nur noch die Konfiguration und Start-Scripte wiederhergestellt werden. Zuerst schien auch alles zu funktionieren, bis ich die OpenVPN Verbindung testete. Diese wollte gar nicht erst starten, sondern warf immer wieder Fehler wie “BIO read tls_read_plaintext error: error:1408F119:lib”. Nach kurzer Suche entpuppte sich dies als Bug in der Implementierung der TLS-Verschlüsselung, welcher schon seit einigen Versionen mitgeschleift wurde. Zum Glück gibt es einen Workaround, welcher OpenVPN wieder lauffähig macht. Dazu reichte es, die Verschlüsselungsmethode in der Konfigurationsdatei des Servers mit “tls-cipher DES-CBC3-SHA” festzulegen. Ein Übersicht, welche Algorithmen funktionieren und welche nicht, gibt es hier:
http://svn.dd-wrt.com:8000/ticket/2536#comment:27
Damit konnten auch die Androiden problemlos verbinden.