Selbstsigniertes Zertifikat erstellen und bei Nginx einbinden

Für verschlüsselte HTTP Verbindungen benötigt man ein Zertifikat. Dieses kann man sich von einer Zertifizierungsstelle (Certificate Authority, CA) ausstellen lassen. Der Haken an der Sache ist das dies Geld kostet (CACert und StartCom mal außen vor gelassen). Eine Alternative hierzu wäre es das Zertifikat selbst zu erstellen. Bei Diensten die man nur für einen kleinen Nutzerkreis z.B. für die Familie hostet, ist es auch vertretbar die Zertifikatswarnung im Browser über sich ergehen zu lassen. Für die Zertifikate wird ein Ordner erstellt und in diesen gewechselt:

mkdir /etc/nginx/ssl
cd /etc/nginx/ssl

Nun werden das Zertifikat und der Certificate Signing Request erstellt:

openssl genrsa -out example.key 2048
openssl req -new -key example.key -out example.csr

Bei der Erstellung des Certificate Signing Request müssen einige Daten angegeben werden:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Mecklenburg-Vorpommern
Locality Name (eg, city) []:Neubrandenburg 
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Example Inc
Organizational Unit Name (eg, section) []:Skunk works
Common Name (e.g. server FQDN or YOUR name) []:example.org
Email Address []:

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Nun muss das Zertifikat noch signiert werden, bevor wir es verwenden können:

openssl x509 -req -days 730 -in example.csr -signkey example.key -out example.crt

In diesem Fall ist das Zertifikat 730 Tage, also zwei Jahre gültig. Da die Signierung nun abgeschlossen ist, kann das Zertifikat in Nginx eingebunden werden. Dazu öffnen wir die Datei „/etc/nginx/sites-available/example“, wobei „example“ hier natürlich für die entsprechende Konfigurationsdatei steht. Dort sollte die SSL Konfiguration vorgenommen werden:

server {
        listen 443 ssl;

        root /var/www/example/root;
        index index.html index.htm;
 
        server_name .example.org;

        ssl_certificate /etc/nginx/ssl/example.crt;
        ssl_certificate_key /etc/nginx/ssl/example.key;
}

Nach dem Aktualisieren der Konfiguration mittels:

service nginx restart

ist die verschlüsselte Verbindung für die eingerichtete Seite aktiv und kann genutzt werden.

Weitere Informationen gibt es unter:
http://nginx.org/en/docs/http/configuring_https_servers.html

Outbank wieder benutzbar

Vor einigen Tagen kam die Version 2.0 der Anwendung Outbank heraus. Dabei handelt es sich um eine Banking Software für Mac OS X und iOS. Allerdings hatte sich in die Version ein schwerer Fehler eingeschlichen. So wurde das Passwort welches zu lokalen Verschlüsselung der Daten benutzt wird, im Klartext in die „system.log“ geschrieben, was dann im Beispiel so aussieht:

Jan 17 09:17:03 delphi.localdomain OutBank[537]: Open Store:Core Data key:123456->abcdefghijklmnopqrstuvwxyzABCDEF

Neben diesem Problemen hatte die erste Version dank iCloud Synchronisierung auch mit Problemen wie doppelten Umsätzen und ähnlichem zu kämpfen. Problematisch an dem Fehler im Log ist auch das Mac OS X von Zeit zu Zeit das ganze archiviert und es so dazu kommen kann, das dieses Passwort an mehreren Stellen zu finden ist. Das gleiche trifft auch auf die Kombination mit Backupsystemen wie Time Machine zu. Um nach dem Update auf Outbank die entsprechenden Logeinträge zu entfernen wird von „stoeger it“ folgende Zeile empfohlen welche man im Terminal ausführen sollte:

sudo -i -- 'cd /var/log && grep -vE "OutBank\[" system.log > system.log.clean && mv system.log.clean system.log && if [[ -f system.log.0.bz2 ]]; then for a in system.log.*.bz2; do bunzip2 $a && grep -vE "OutBank\[" ${a%.*} > ${a%.*}.clean && mv ${a%.*}.clean ${a%.*} && bzip2 ${a%.*} ; done; fi; rm -f /var/log/asl/*.asl'

Witzig sind in diesem Zusammenhang Aussagen von Tobias Stöger aus der Zeitschrift SFT (Spiele | Filme | Technik) wo er auf die Frage ob Outbank sicher ist unter anderem wie folgt antwortet:

Der Artikel bezog sich mal wieder auf das unsichere Android-OS. […] Hinzu kommen noch unsere Sicherheitsmaßnahmen, wie automatische Passwortsperre oder verschlüsselte Datenbank.

Das war dann wohl ein Fall von pauschaler Aussage zum falschen Zeitpunkt. Natürlich stellt sich die Frage warum (wenn auch nur für Debugzwecke) Passwörter überhaupt im Klartext gespeichert werden. Auch war keine Auskunft zu erhalten ob die neue Version von Outbank die Bereinigung der Dateien selber vornimmt. Zur Sicherheit sollte man dies also auf alle Fälle manuell nachholen und anschließend das entsprechende Passwort ändern.

Weitere Informationen gibt es unter:
http://www.outbank.de/outbank-os-x-mac-sicherheitshinweis-zu-version-2-0-0/
http://www.heise.de/mac-and-i/meldung/Outbank-2-mit-Passwort-Leck-1786837.html

Dropbox + EncFS + Spotlight unter OS X

Vor einiger Zeit schrieb ich einen Artikel darüber wie man ein verschlüsseltes Verzeichnis in der der Dropbox mittels „Fuse4X“ und „EncFS“ unter Mac OS X Lion mountet. Der Wehrmutstropfen an meiner Methode war allerdings das Spotlight nicht funktionierte. Das hängt wohl damit zusammen das Spotlight standardmäßig nicht auf die mit Fuse eingehängten Systeme zugreifen kann.

Dazu sind auch nur einige Änderungen nötig. So muss das alte Skript zum mounten:

echo ultrageheimespasswort | encfs --stdinpass ~/Dropbox/Private ~/DropboxEncrypted

durch dieses ausgetauscht werden:

#!/bin/bash
#Secure EncFS Dropbox mounter by Daniel Widerin
#Edited by seeseekey

SOURCE=~/Dropbox/Private
TARGET=/Volumes/DropboxEncrypted
VOLUME_TITLE=DropboxEncrypted
PASSWORD=ultrageheimespasswort
ENCFS=/usr/local/bin/encfs

mount | grep $TARGET >/dev/null
[[ "$?" -eq "0" ]] && /usr/sbin/diskutil unmount $TARGET

if [ ! -d $TARGET ]; then
 echo "Create new mountpoint $TARGET"
 mkdir $TARGET
 chmod 0700 $TARGET
fi

echo $PASSWORD | $ENCFS $SOURCE $TARGET --stdinpass -ovolname=$VOLUME_TITLE -omodules=iconv -ofrom_code=UTF-8 -oto_code=UTF-8-MAC -oallow_root -olocal -ohard_remove -oauto_xattr -o nolocalcaches

Das neue Skript basiert dabei auf einer Variation eines Skriptes von Daniel Widerin und wurde etwas vereinfacht sowie um Angaben für den Zeichensatz erweitert. Nun kann man sich das ganze noch etwas bequemer machen, indem man das entschlüsselte Verzeichnis gleich beim Login einbindet. Das Skript sollte dabei einen Namen nach dem Schema „encryptDropbox.command“ tragen.

Nachdem dies geschehen ist, findet man in den Einstellungen unter „Benutzer & Gruppen“ -> „Anmeldeobjekte“ den entsprechenden Punkt. Dort wird einfach das entsprechende Skript hinzugefügt und schon wird dieses in Zukunft beim Login geladen.

Weitere Informationen gibt es unter:
https://seeseekey.net/archive/9455
http://fuse4x.github.com/faq.html
http://widerin.org/blog/secure-your-dropbox

Dropbox + EncFS + Mac OS X (Lion)

In meiner Dropbox findet sich ein mittels „EncFS“ verschlüsselter Ordner. Dieser soll natürlich auch unter Mac OS X funktionieren. Im Netz gibt es einige Anleitungen um das ganze zum laufen zu bekommen, allerdings war darunter keine die bei mir funktionierte. Um den EncFS Ordner zu entschlüsseln muss man sich folgende Software herunterladen:

Nach dem Download muss man das ganze installieren und dann benötigt man nur noch ein kleines Skript zum mounten des ganzen. In dieser Skript trägt man folgendes ein:

echo ultrageheimespasswort | encfs --stdinpass ~/Dropbox/Private ~/DropboxEncrypted

Damit kann man das ganze mounten, ohne jedes mal das Passwort eingeben zu müssen. In Verbindung mit dem gemounteten Ordner gibt es leider ein Problem, so ignoriert Spotlight sämtliche Inhalte des entsprechenden Orders.

Weitere Informationen gibt es unter:
http://www.lisanet.de/?p=128
https://seeseekey.net/archive/6102
http://sohleeatsworld.de/?x=entry:entry120505-190714

NB-Town speichert Passwörter im Klartext

In den letzten Tagen kursierten die Passworthashs der Communities Last.fm, eHarmony und LinkedIn durch das Netz. Bei Last.fm waren dies ungesalzene MD5 Hashs die man per Brute Force in relativ kurzer Zeit zurückrechnen kann.

Das Problem ist das sobald man dies „zurückrechnen“ kann, kann man die Passwörter bei anderen Diensten (Mail, Amazon, usw.) ausprobieren und damit Schindluder treiben. In einer perfekten Welt würde zwar jeder für jeden Dienst ein extra Passwort benutzen, aber es ist nun mal keine perfekte Welt.

Noch problematischer wird das ganze wenn man die Passwörter im Klartext (siehe Update) speichert (was man definitiv nicht tun sollte). So gibt es im Norden Deutschlands eine erfolgreiche Community mit knapp 140000 Mitgliedern welche auf den Namen NB-Town hört und unter www.nb-town.de zu finden ist.

Das Problem offenbart sich sobald man einmal die „Passwort vergessen?“ Funktionalität benutzt. Daraufhin bekommt man folgende Mail:

Die Passwort vergessen? Mail

Wie man sieht wird das Passwort im Klartext gespeichert (sonst könnte es die „Passwort vergessen?“ Funktionalität nicht zurücksenden), was bei einer solchen Community fahrlässig ist. Sobald jemand an die Datenbank herankommen so hat er 140000 Passwörter + die passenden Identitäten dazu. Ein anderes Problem bei Passwörtern welche im Klartext gespeichert werden, ist immer das die Betreiber Zugriff auf diese haben und damit (theoretisch) Schindluder betreiben können.

Deshalb gilt, Passwörter immer gehasht (aber nicht mit MD5 ;)) und gesalzen speichern. Einene schönen Artikel dazu gibt es bei Heise unter http://www.heise.de/security/artikel/Passwoerter-unknackbar-speichern-1253931.html.

Update:
Die Passwörter werden in der Datenbank nicht im Klartext gespeichert, sondern AES verschlüsselt. Bei der „Passwort vergessen?“ Funktion wird der Schlüssel in der Query übergeben, so das das Passwort entschlüsselt werden kann. Man müsste als böser Mensch also an den Webserver und den Datenbankserver herankommen und um Zugriff auf die Passwörter zu bekommen.