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

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

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!

Ich grabe einen Tunnel

Befindet man sich in unsicheren Netzwerken (öffentliche Netzwerke, z.B. an einer Uni, öffentliche WLANs…) so muss man ziemlich aufpassen, da man nie wirklich weiß, ob sich nicht doch jemand mit bösen Absichten im Netz befindet. So ein Man-in-the-middle Angriff mit ARP-Spoofing ist mit den richtigen Tools schnell und unbemerkt durchgeführt. So kann man den Traffic von allen Rechnern im Netz scannen und interessantes wie Passwörter herausfiltern. Selbst SSL-Verbindungen sind angreifbar. Zwar gibt es deutliche Anzeichen für Angriffe, wie z.B. gemeldete, fehlerhafte Zertifikate durch den Browser o.ä., allerdings werden diese von den meisten Nutzern blind abgenickt. Ein schwerer Fehler, denn dann ist auch die eigentlich sichere SSL-Verbindung gekapert und kann mitgelesen werden. Oder die SSL-Verbindung wird auf dem Weg zum Zielrechner einfach komplett entfernt, die Warnung wegen eines falschen Zertifikats entfällt. Nur wer aufmerksam ist wird vielleicht merken, dass er die eigentlich per SSL geschützte Seite über eine normale HTTP-Verbindung aufruft.
Ein relativ wirksames Mittel gegen solche Manipulationen ist die Tunnelung des Traffics zu einem vertrauenswürdigen Netz. Dies kann beispielsweise ein Server im Internet oder gar das eigene Heimnetzwerk sein. Doch wie bekommt man seine Daten sicher aus dem unsicheren Netz heraus? Dafür bietet sich ein VPN-Tunnel an, welcher Datenverbindungen verschlüsseln und auch umleiten kann. Im Prinzip kann man sich ein VPN wie ein eigenes, kleines sicheres Netzwerk vorstellen, welches über andere, unsichere, Netzwerke aufgespannt ist. Gut, die Konstellation heißt vielleicht nicht umsonst Virtual Private Network ;-) Mitglieder in diesem virtuellen Netzwerk können sich untereinander sehen, als würden sie sich in einem physikalischen Netzwerk befinden.
Um ein VPN als sicheren Tunnel gegen dubiose Netzwerke zu nutzen, muss zunächst ein Endpunkt (also da, über welche Internetverbindung man schließlich ins Internet gehen will, z.B. im Heimnetzwerk) mit VPN-Server verfügbar sein. Hierfür bietet sich OpenVPN an, da es relativ einfach zu konfigurieren ist (als beispielsweise IPSec) und eine hohe Sicherheit bietet (von einem PPTP-VPN sieht man besser ab).
Ist OpenVPN installiert geht es an die Konfiguration. Dazu stellt man im Ordner /etc/openvpn/ (Unter Linux, unter Windows sind die Pfade anders) eine Konfigurationsdatei server.conf o.ä..
Diese sieht wie folgt aus:

mode server #Starte OpenVPN als Server
tls-server
script-security 2
server 192.168.23.0 255.255.255.0 #Definiert VPN-Adressbereich
persist-key
persist-tun
user openvpn
group openvpn
push "route 192.168.23.0 255.255.255.0" #Setzt Route zum angegeben Netz am Client
route 192.168.23.0 255.255.255.0
push "redirect gateway def1" #Leitet Traffic zum Server
client-to-client #Clients im VPN-Netzwerk können sich untereinander sehen
float
dev tun
proto udp
port 1194
keepalive 10 300
dh /etc/openvpn/easy-rsa/keys/dh1024.pem 
ca /etc/openvpn/easy-rsa/keys/ca.crt #Pfade zu den TLS-Zertifikaten
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
verb 4

Als nächstes müssen Zertifikate erzeugt werden – wie das geht steht hier: http://wiki.openvpn.eu/index.php/Erzeugen_einer_PKI_mit_EasyRSA

Damit der Server den ankommenden Traffic auch weiterleiten kann, muss noch ein bisschen am System geschraubt werden. Zunächst muss über eine iptables-Regel die Weiterleitung aus dem VPN-Netz an das Standardinterface erlaubt werden:
iptables -t nat -A POSTROUTING -s 192.168.23.0/24 -o eth0 -j MASQUERADE
Als nächstes wird die Weiterleitung von Datenpaketen mit echo "1" > /proc/sys/net/ipv4/ip_forward aktiviert. Diese Einstellunen sind allerdings nicht persistent, bei einem Neustart werden die Einträge wieder zurückgesetzt. Damit ein Reboot überlebt wird, muss net.ipv4.ip_forward=1 in der Datei /etc/sysctl.conf gesetzt sein. Alternativ können die Befehle auch in bei Systemstart z.b. über rc.local aktiviert werden (das ist aber irgendwie nicht so schön ;-)).
Wann nach oben verlinkter Anleitung alle Zertifikate generiert wurden, können diese an den Clients eingerichtet werden. Unter Linux geht dies bequem über den Netzwerkmanager, wie es unter Windows aussieht, keine Ahnung – das habe ich noch nicht probiert ;-)
Unter Android kann die Verbindung auch genutzt werden.
Dazu ist eine Konfigurationsdatei erforderlich, bei mir sieht sie wie folgt aus:

remote $Adresse-zum-VPN-Server 1194
client 
dev tun
proto udp
resolv-retry infinite 
nobind 
persist-key 
persist-tun 
float 
tls-client
ca $Zertifikat-der-CA
cert $Zertifikat
key $Key
Screenshot_2013-07-14-10-22-17
OpenVPN für Android, Routing

Diese wird in “OpenVPN für Android” importiert. Unter “Routing” muss dann noch das Häkchen zur Weiterleitung des Traffics über die VPN-Verbindung gesetzt werden (siehe Screenshot links).
Ob der Tunnel funktioniert kann über Webseiten wie http://browserspy.dk/ip.php überprüft werden. Dazu besucht man die Webseite einmal mit aktivierten und einmal mit deaktiviertem VPN. Sind beide IPs unterschiedlich, so funktioniert der Tunnel und der Traffic wird darüber weitergeleitet. Angriffe von den darunter liegenden Netzwerken sind somit nicht mehr möglich. Als nettes Nebenfeature ist dort auch nur noch die VPN-Verbindung sichtbar, alles andere ist unsichtbar.

Alles unter Kontrolle

Mittlerweile muss ja alles irgendwo in der Cloud liegen. Kalender, Kontakte und Mails bei Google, Bilder bei Flickr/Picasa, Dateien bei Dropbox/Box/SkyDrive und so weiter… Es ist ja ganz praktisch, alles immer und überall verfügbar zu haben. Doch was ist, wenn es Anbieter xyz nicht mehr gibt, sein Geschäftsmodell ändert oder man einfach Bedenken hat, seinen ganzen Kram irgendwelchen Diensten anzuvertrauen? Gerade die ersten beiden Punkten waren für mich ausschlaggebend, so viel wie möglich selbst in die Hand zu nehmen.
Auslöser dafür war Google mit der Einstellung des Google Readers. Nur weil der RSS-Reader (vermutlich) kein Geld eingebracht hat und für Google überflüssig erschien, wurde er kurzerhand eingestampft. Im Prinzip kann dies auch mit allen anderen Diensten passieren – wobei das schon der Worst-Case ist. Seit dem habe ich versucht, so viel wie möglich von irgendwelchen externen Anbietern wegzubekommen und selbst zu hosten.

Mails
Angefangen hat es mit E-Mails. Die Einrichtung eines Mailservers war eigentlich das schwierigste – bis das Ding gemacht hatte, was ich wollte hat es schon etwas gedauert. Doch es hat sich auf jeden Fall gelohnt. Keine Beschränkungen mehr, dass man z.B. nur x Filter oder y Unterordner einrichten darf. Auch speichertechnisch war es ein gewaltiger Fortschritt. Die Mailbox war plötzlich so groß was die Festplatte des Servers hergab. Ein weiterer Vorteil: Irgendwelche Anbieter konnten jetzt nicht mehr in den Mails rumschnüffeln – und vor allem war sie werbefrei!

RSS
Als nächstes habe ich einen Ersatz für den Google Reader gesucht. Meine Wahl viel hier sehr schnell auf TinyTinyRSS (TT-RSS). Für TT-RSS reicht es, einen Webserver mit PHP Unterstützung zu haben. Im Prinzip sollte es also auch auf einem simplen Webspace laufen. Ein wichtiges Entscheidungskriterium war für mich die Android-Unterstützung. Und die hat TT-RSS in Form einer Android-App. Neben der offiziellen App gibt es auch diverse Alternativen.

Kalender und Kontakte
Dann kamen Kalender und Kontaktdaten an die Reihe. Bis dahin hatte ich alles bei Google liegen. Doch warum sollte ich Google all meine Kontakte und Termine offenbaren? Die Auslagerung hier ist etwas schwierig, da auch der Sync mit Android gegeben sein muss. Vorher hatte ich schon mal mit SyncML und eGroupware experimentiert, was aber mehr schlecht als recht lief. Alternativen sind CalDAV/CardDAV oder MS-Exchange. Für die erste Möglichkeit bietet Android keine native Unterstützung und man ist auf externe Tools angewiesen. Für die Umsetzung von MS-Exchange gibt es mehrere Tools – meine Wahl ist dabei auf Tine 2.0 gefallen, einer Open-Source Groupware. (Gut, andere Programme habe ich nicht wirklich getestet, da Tine auf Anhieb funktionierte ;-))
Die Synchronisation mit Android funktioniert ohne Probleme und auch ein WebOS-Gerät habe ich damit im Einsatz. Zudem bietet Tine ein (meiner Meinung nach) schickes Webinterface an, welches eine Desktop-Software durchaus ersetzen kann.
Der große Vorteil von Tine 2.0 ist u.a., dass Repositories für diverse Linux-Distributionen angeboten werden und es so bequem per Paketmanager aktuell gehalten werden kann. Eine manuelle Installation ist aber auch möglich, sodass Tine auch auf einem Webspace lauffähig ist.

Dateien
Wenn man schon mal dabei ist alles mögliche selbst zu hosten, war bei mir der nächste Punkt die Ersetzung von Dropbox, Box und Skydrive. Hierzu bietet sich OwnCloud an. Die PHP-Software bietet neben der Synchronisation von Dateien zwischen mehreren Geräten auch Funktionen Kalender, Aufgaben, Kontakte etc an. Der große Vorteil von OwnCloud ist, dass die Schnittstelle für die Synchronisation auf offenen Standards (WebDAV, CalDAV, CardDAV) aufsetzt. Dadurch ist man nicht unbedingt an die offiziellen Clients (welche es für Windows, Linux, MacOS, Android und iOS gibt) gebunden. Auch wird der Up- und Download nur durch die Anbindung des Servers begrenzt. Bei Dropbox kam es bei mir oft vor, dass ich nicht die volle verfügbare Bandbreite ausnutzen konnte. Weiterhin ist es möglich, beliebig viele Quellverzeichnisse zu synchronisieren. Man ist so nicht auf einen einzelnen Ordner beschränkt. Freigaben für z.B. Freunde, auf welche dann ohne Anmeldung zugegriffen werden kann, sind natürlich auch möglich.

Bilder
Bevor Flickr für die kostenlose Nutzung die Beschränkungen entfernt bzw. stark gelockert hat, war der Dienst für mich eher uninteressant. Alternativen waren entweder gruselig zu benutzen oder verlangten schon für den kleinsten Account Geld. Also hieß es auch hier: selbst hosten!
Meine Wahl viel hierbei auf Coppermine. Das Tool bietet viele Schrauben, an denen man es einstellen und nach seinen Bedürfnissen einrichten kann. Neben öffentlichen Galerien ist es möglich, Alben mit einem Passwort zu schützen, das Design anzupassen wie man es gerne hätte, mit mehreren Benutzern zu arbeiten etc.
Clients für Android gibt es leider nicht, wobei ich den auch nicht wirklich brauche (habe ich auch bei Flickr nie genutzt).

DynDNS
Ein weiterer großer Brocken (neben E-Mails) war die Einrichtung eines eigenen DyDNS-Dienstes. Da dyn.com sein Modell für kostenlose Accounts umgestellt hat, mit dem Ziel einen Richtung Bezahl-Accounts (mit dessen Preisen ich nicht so wirklich einverstanden war) zu drängen, war es Zeit für mich zu wechseln. Irgendwann kam dann die Idee, diesen Dienst selbst umzusetzen (siehe Bastelstunde: Der eigene DynDNS-Dienst), was mit einer mehr oder weniger großen Bastelaktion verbunden war, welche zudem nicht ganz ungefährlich war (wenn man mit dem DNS-Server Mist baut, läuft man Gefahr für die nächsten maximal 24h “offline” zu sein).

So viel wie möglich selbst hosten hat Vorteile und Nachteile. Man hat all seine Daten unter Kontrolle und kann mehr oder weniger machen was man möchte.
Andererseits benötigt man mehr oder wenig gute Kenntnisse darüber, was man macht. Auch steht und fällt alles mit dem Anbieter, bei dem man den Server, vServer oder Webspace gemietet hat. Andererseits hat man die freie Auswahl, bei welchem Anbieter man hosten möchte und kann bei Bedarf wechseln. Natürlich ist es auch möglich, alles auf einem Homeserver bei sich zu Hause unter dem Tisch zu betreiben. Allerdings ist es dann eher schwierig, einen eigenen Mailserver (Mail-Anbieter wie GMX, web.de, Yahoo!, Google… nehmen aus Gründen der Spamvermeidung keine Mails von dynamischen IP-Adressen an) oder DynDNS Dienst zu betreiben. Die anderen Dienste sind aber problemlos nutzbar.