Mehr Sicherheit fuer die eigenen Daten – Komfort mit Firefox Sync + Masterpasswort

Dieses ist der vierte Teil einer Serie von Blogeintraegen, die sich als Reaktion auf die NSA Affaere um den Kontext Sicherheit fuer die eigenen Daten und Verschluesselung drehen.

Links zu den ersten drei Artikeln befinden sich am Ende des Blogposts. Im diesem vierten Teil moechte ich auf das Thema Komfort im Webbrowser eingehen und dabei auf meinen frueheren Artikel zum selbst gehosteten Firefox Sync verweisen.

Es gibt eine ganze Menge an Webbrowsern dort draussen, das sind zum Beispiel Google Chrome, Apple Safari, Microsoft Internet Explorer oder halt auch Mozilla Firefox. Ich bevorzuge den letzten weil er erstens OpenSource ist, zweitens gut unter Linux laeuft und drittens mich nicht versucht in irgendwelche Services zu zwingen. Ich nehme dabei bewusst in Kauf, dass die Performance der JavaScript Engine nicht so gut ist, wie zum Beispiel verglichen mit der von Google Chrome. Auf Annehmlichkeiten wie synchronisierte Lesezeichen oder Chronik moechte ich aber dennoch nicht verzichten. Ich persoenlich synchronisiere damit Daten zwischen drei Geraeten, davon ein Mobiltelefon.

Aus diesem Grund habe ich bereits vor laengerer Zeit mir einen selbst gehosteten Firefox Sync Server installiert. Dort ist alles in meiner Hand, auf meinen Servern, ich kann verschluesseln, und meine Passwoerter schwirren wenn ueberhaupt dann gesichert durchs Netz.

Im Prinzip ist bei mir alles noch genauso, wie ich es in der Anleitung damals beschrieben habe. Der einzige Unterschied ist der Apache vHost, der nun ueber SSL geht:

<VirtualHost *:443>
        ServerName ffsync.example.org
        ServerAdmin webmaster@example.org
        DocumentRoot /opt/ffsync/server-full
 
        SSLEngine on
        SSLCertificateFile /path/to/ffsync.example.org.crt
        SSLCertificateKeyFile /path/to/example.org.key
 
                Order deny,allow
                Allow from all
 
        WSGIProcessGroup ffsync
        WSGIDaemonProcess ffsync user=ffsync group=ffsync processes=2 threads=25
        WSGIPassAuthorization On
        WSGIScriptAlias / /opt/ffsync/server-full/sync.wsgi
 
        CustomLog /var/log/apache2/ffsync_access.log combined
        ErrorLog /var/log/apache2/ffsync_error.log
</VirtualHost>

Weiter habe ich in der etc/sync.conf die URL des fallback node auf https:// abgeaendert.

Ganz wichtig dabei ist natuerlich: WENN Passwoerter im Webbrowser abgespeichert werden, DANN MUSS ein Masterpasswort gesetzt sein. Das gilt fuer Mozilla Firefox genauso wie fuer Mozilla Thunderbird. Wenn KEIN Masterpasswort gesetzt ist, kann JEDER der Zugriff auf den laufenden Webbrowser oder das laufende Thunderbird hat mit fuenf Klicks ALLE gespeicherten Passwoerter einsehen. Diese fuenf Klicks sind:

  1. Firefox
  2. Einstellungen
  3. Sicherheit
  4. Gespeicherte Passwoerter
  5. Passwoerter anzeigen

An der gleichen Stelle kann man uebrigens auch das Masterpasswort setzen. In Thunderbird ist es auch Einstellungen -> Sicherheit -> Passwoerter…

Vorherige Blogposts:

  • Der erste Teil war fuer mich das Aufraeumen, einen Ueberblick zu bekommen sowie Strukturen zu schaffen, auf denen ich aufbauen kann.
  • Der zweite Teil bestand darin einen Ort zu schaffen, in dem ich Keys und Passwoerter sicher aufbewahren und gleichzeitig alles in ein vernuenftiges Backup schieben kann.
  • Der dritte Teil bezog sich auf das erzeugen von Zertifikaten und Einrichten von verschluesselten Verbindungen zu Apache vHosts.

Vista und Macintosh Probleme mit DHCP-Server

Mal eben zum festhalten… Es gab in hier in Goettingen in verschiedenen Wohnheimen (z.B. C-Weg und Kolosseum) Probleme mit neu aufgesetzen Routern. Der DHCP-Server vergab IP-Adressen, die dann Vista oder Macintosh Clients nicht mehr annahmen. Bei diesen Clients entwickelte sich eine DHCPDISCOVER – DHCPOFFER Kommunikation, zu einem DHCPREQUEST kam es nicht mehr. Workaround war in den Wohnheimen fuer eine kuerzere oder laengere Zeit, bei all diesen Clients dann die IP fest von Hand einzutragen. Bei einem DHCP-Server eine doch sehr unschoene Loesung.

Erst hab ich ein bisschen im Netz gesucht und gedacht es wuerde an dem bekannten Broadcast-Problem liegen (MS-Knowledgebase Artikel). Wars aber nich. Nach einigem Konfigurationsdateien lesen war dann der Fehler lokalisiert. Es lag an dem:

 server-identifier hostname;

in der /etc/dhcp3/dhcpd.conf (bzw. in den Wohnheimen in der entsprechenden .skel Datei des eingesetzten netconfig-Skripts). Das einmal geaendert in

 server-identifier 123.123.123.123;

machte alle vorher aufgetretenen Probleme obsolet. Und nu fuer die Suchmaschinen-Welt:

Debian Etch. Ubuntu, DHCP, DHCP-Server, Vista, Macintosh, Apple, OS X, dhcpd.conf, kein DHCPREQUEST, nimmt IP nicht an, Broadcast

Neue Appel Produkte?

Appel hat supertolle Marktzahlen praesentiert und angekuendigt in den naechsten Monaten tolle neue Produkte zu veroeffentlichen. Nur was ist jetzt die Frage. Was wird es tolles neues geben und welche Zielgruppe denn? Inspiriert aus einigen Foren:

iShmogg: Ein grell pulsierend leuchtendes, apfelfoermiges Geraet, dessen einziger erkennbarer Sinn darin besteht, offen an der Kleidung getragen zu werden. Aus designgruenden wurde auf Interaktionsschnittstellen jeglicher Art verzichtet. Der Einstiegspreis soll bei 59USD bzw. 59EUR liegen. Wer gerne ein Modell haette incl. Akkulademoeglichkeit dessen, ist aber leider zum 4h Modell gezwungen. Der iShmogg 4h soll fuer 129USD bzw. 129EUR auf den Markt kommen.
Ausgestattet sind Apples neuen Geraete mit WLAN, das aber nur mit Apples neuen kostenpflichtigen iSpots funktioniert. Mit dabei ist 1 Monat kostenlose Nutzung von iVZ, dem neuen Communityportal nur fuer echte Hippster und andere Shmoggs die hier endlich unter sich sein koennen… Als Zielgruppe fuer die neuen iShmoggs nennt Apple sogenannte iDiots.

[08:08] <prego> chinaski: was denkst du ueber apple produkte?
[08:08] <chinaski> tja Apple ist doch nur was fuer Kinder reicher Eltern