Archiv nach Kategorien: Mac OS X

Mac OS X absichern – Teil 1

Kurzzusammenfassung: Ein neu gekaufter Apple Computer ist schnell und einfach eingerichtet – Einschalten, Name und Passwort vergeben, fertig. Was vielen Anwendern dabei nicht bewusst ist: Nach dieser Standard-Inbetriebnahme ist der Mac keinesfalls sicher konfiguriert! Des Weiteren sollten einige grundsätzliche Regeln im Umgang mit dem Rechner beachtet werden. All dies werde ich in einer mehrteiligen Serie besprechen.

Auf folgendes möchte ich eingangs jedoch deutlich hinweisen: Ich bin weder ein Sicherheitsexperte noch forsche ich in diesem Bereich. Durch meine praktischen Erfahrungen als freier System Administrator entstand die Idee, dieses komplexe Thema auch für weniger versierte Anwender möglichst nachvollziehbar aufzubereiten. Als Quellen dienten mir dabei u.a. die Mac OS X Security Configuration Guides von Apple, die Sicherheitsempfehlungen der NSA sowie diverse Fachliteratur der Verlage O’Reilly, Addison-Wesley/Pearson, APress, Wiley PublishingSyngress, No Starch Press, Peach Pit Press, Que Publishing, McGraw-Hill und Galileo Press.

Der erste Teil dieser Serie beschäftigt sich mit der Trennung von Benutzer-Accounts unter Mac OS X.

1. Standard-Benutzer versus Administrator-Account

Mac OS X ist ein UNIX-basiertes Betriebssystem und somit ein Mehrbenutzersystem, bei dem es eine strenge Trennung von Zugriffsmöglichkeiten innerhalb des Systems gibt. Unter Mac OS 9 und seinen Vorgängern war für einen Benutzer im Prinzip alles erlaubt – dadurch war es z.B. möglich, eine “Sicherheitskopie” des Systemordners an einen anderen Platz der Festplatte zu verschieben und bei Bedarf auf diesen zurückzugreifen. Die Umstellung auf Mac OS X führte (nicht nur aus diesem Grund) zu einigem Frust und Ärger unter alteingesessenen Mac-Nutzern, denn solche weitgehenden Rechte waren durch dank UNIX passé.

Mac OS X unterscheidet grob zwischen Gast-Benutzern, Standard-Benutzern, Systemverwaltern (Administratoren) und dem Superuser (root). Die größten Einschränkungen gelten dabei für den Gast-Benutzer, dieser soll aber nicht Thema dieses Artikels sein. Dem Standard-Benutzer ist es nicht erlaubt, Änderungen am System vorzunehmen oder Software außerhalb seines Benutzerordners zu installieren. Auch werden von ihm gestartete Programme nur mit seinen Nutzerrechten ausgeführt. Benutzer mit administrativen Rechten besitzen dagegen weitergehende Rechte – sie dürfen systemweite Einstellungen vornehmen, Software im Programme-Ordner installieren und verfügen außerdem über Schreibzugriff auf diverse Verzeichnisse, auf die ein Standard-Benutzer nicht schreibend zugreifen darf. Ein nutzbares Root-Benutzerkonto, das dauerhaft über die Berechtigungen des Superusers verfügt, gibt es nach einer Standard-Systeminstallation von Mac OS X nicht. Zwar gibt es einen Benutzer „root“, dieser ist jedoch nicht aktiviert. Allerdings existiert der Befehl sudo (siehe weiter unten), mit Hilfe dessen ein Administrator root-Rechte erlangen kann. Davon abgesehen wurden wiederholt Lücken im System entdeckt (so genannte privilege escalations), die es einer von einem Administrator ausgeführten Software ermöglichten, Root-Rechte und damit die volle Kontrolle über das System zu erlangen. Auch Malware-Entwickler haben nicht erst seit gestern Mac OS X im Visier , wie auch ein aktueller Bericht von F-Secure bei heise online zeigt.

Grundsätzlich gilt auch bei Mac OS X: Ein Standard-Benutzer ist einem Benutzer mit administrativen Rechten für die alltägliche Arbeit vorzuziehen.

Der erste eingerichtete Benutzer unter Mac OS X besitzt diese so genannten “administrativen Rechte”, es handelt sich also um einen Administrator-Account. Dadurch ist dieser Benutzer auch automatisch Mitglied in der “sudoers list” und kann (nach Eingabe seines Administrator-Passwortes) per sudo root-Rechte erlangen, womit er zeitweilig zum Superuser wird.

Für die ständige Nutzung des Rechners sollte man also aus Sicherheitsgründen einen Standard-Benutzer anlegen. Die Arbeitsqualität verringert sich dadurch kaum – bei nötigen Programm- oder Systemaktualisierungen kann man sich jederzeit weiterhin als administrativer Benutzer mit dem entsprechenden Admin-Passwort identifizieren.

Arbeitet man mit einem Standard-Benutzer, muss man sich als Administrator identifizieren, um z.B. Apples Softwareaktualisierung ausführen zu können.

Solch ein Standard-Benutzer ohne administrative Rechte ist aus Sicherheitsgründen kein Mitglied der “sudo-Liste”. Der Befehl sudo (kurz für substitute user do) steht dem Standard-Benutzer also nicht zur Verfügung, was zur Folge hat, dass er auf diesem Wege keine root-Rechte erlangen kann.

Superuser-Rechte kann der Standard-Benutzer auf diesem Wege nicht mehr erlangen.

Dies in Kombination mit der zwingend erforderlichen Identifikation bei administrativen Zugriffen bedeutet in der Praxis ein erhöhtes Maß an Sicherheit.

Der erste eingerichtete Benutzer (welcher zwingend einen Admin-Account erhält) sollte also nur für die Verwaltung des Systems genutzt werden, während ein zweiter Benutzer-Account angelegt wird, den man dann für die alltäglichen Aufgaben nutzen kann. Erfreulicherweise sind zusätzlich angelegte Benutzer voreingestellt nur Standard-Accounts (die Option “Der Benutzer darf diesen Computer verwalten” ist dabei deaktiviert).

Auch wenn man die Ersteinrichtung schon hinter sich hat und all die persönlichen Daten nun in einem Admin-Account liegen, lässt sich diese Nutzertrennung noch nachträglich konfigurieren. Dazu legt man einfach einen zweiten Benutzer-Account an, wählt für diesen aber explizit aus, dass er ebenfalls ein Administrator sein soll. Dann meldet man den bisherigen Benutzer vom System ab (Apfel+Shift+Q) und landet so im Anmeldedialog von Mac OS X. Dort meldet man sich mit dem neu angelegten Admin-Account am System an und öffnet Systemeinstellungen/Benutzer. Hier kann man nun dem alten Admin-Account die administrativen Rechte entziehen, indem man ihn markiert und dann die Option “Der Benutzer darf diesen Computer verwalten” deaktiviert – aus dem Admin-Account wird so ein Standard-Account.

Der Benutzer-Account für die tägliche Arbeit sollte ein Standard- statt Admin-Account sein.

Anmerkung: Unter früheren Versionen von Mac OS X konnte das Problem auftauchen, dass bei solchen nachträglichen Änderungen auch die Benutzer-IDs angepasst werden mussten. Meiner Erfahrung nach ist das bei 10.6 Snow Leopard und 10.7 Lion nicht mehr notwendig. Soll heißen, es ist kein Problem, wenn ein ehemaliger Admin-Account die Benutzer-ID 501 behält und ein neuer Admin-Account die Benutzer-ID 502 bekommt. Wer sich auf diese Aussage nicht verlassen möchte, für den gibt es die Möglichkeit, mit einem Rechtsklick auf den jeweiligen Benutzer in den Systemeinstellungen die “erweiterten Optionen” zu öffnen. Dort kann man die Benutzer-ID entsprechend anpassen (wobei dadurch unter Umständen weitere “Operationen am offenen Herzen” nötig sind).

WARNUNG: Das anpassen der User-ID ist nur für fortgeschrittene Anwender ratsam, nicht umsonst warnt auch Apple ausdrücklich davor!

Das ändern der Benutzer-ID oder auch das anpassen des Benutzerordners ist mit Vorsicht zu genießen …

Auch Programmierer, die z.B. mit Apples Entwicklungsumgebung XCode Programme für Mac OS X oder iOS entwickeln, benötigen für ihre tägliche Arbeit keine administrativen Rechte. Sie können ihrem Standard-Benutzeraccount für die Entwicklung wichtige, die Sicherheit des Systems aber nicht beeinträchtigende, Gruppen wie z.B. _developer hinzufügen.

sudo dscl . append /Groups/_developer GroupMembership <username>

Fazit: Zwar muss man sich mit einem Standard-Benutzer öfter als gewohnt als Administrator identifizieren, um Änderungen am System vornehmen zu können oder Programme zu aktualisieren. Bösartigen Programmen erschwert dies jedoch ebenfalls erheblich die Arbeit, da sie (außer im eigenen Benutzerordner) ohne Angabe eines Passwortes kaum Schaden anrichten können.

Identifizierungsaufforderung für das Kopieren einer speziellen Firefox-Version für PPC-Macs in den Programme-Ordner unter Mac OS X 10.5 Leopard.

Achtet man also zukünftig darauf, an welcher Stelle man zur Identifizierung mit administrativen Rechten aufgefordert wird, ist das eigene System schon um einiges besser geschützt.

Hinweis: Natürlich kann man sich im eigenen Benutzerverzeichnis auch einen eigenen Programme-Ordner anlegen, bei dessen Nutzung man sich dann nicht extra identifizieren muss (da man ja Schreibrechte für seinen eigenen Nutzerordner und dessen Unterordner hat). Am besten nennt man diesen Ordner “Applications”, dann bekommt er zum einen das entsprechend passende Ordner-Symbol und davon abgesehen kann man ihn so auch besser vom Programme-Ordner auf der obersten Verzeichnisebene der Festplatte unterscheiden (beispielsweise als zusätzlicher Ordner in der Seitenleiste eines Finderfensters).

Selbstverständlich muss auch ein Betriebssystem wie Mac OS X auf dem aktuellen Stand gehalten werden, um entdeckte Sicherheitslücken zeitnah zu schließen. Im kommenden zweiten Teil werde ich mich deshalb der Aktualisierung des Systems sowie weit verbreiteter Programme und Erweiterungen widmen.

E-Mail-Verschlüsselung unter Mac OS X

Kurzzusammenfassung: GPGTools ist ein Installationspaket für Mac OS X, mit dessen Hilfe E-Mails und Dateien ver- und entschlüsselt werden können. Ziel ist es, eine einfache Möglichkeit bereitzustellen, die OpenPGP-Software auf Apple Computern verwenden zu können. Die GPGTools selbst sowie die darin enthaltenen Softwarepakete sind freie Software und quelloffen.

Wozu Daten verschlüsseln?

Sollen per E-Mail sensible Daten ausgetauscht werden (beispielsweise Zugangs-Passwörter), empfiehlt es sich, diese Informationen nicht mit einer normalen E-Mail zu kommunizieren. Auch eine sichere Verbindung zum E-Mail-Server über TLS/SSL (z.B. per POP3S/IMAPS/SMTPS) bietet keine 100%ige Sicherheit. Etwas mehr Sicherheit gewinnt man durch passwortgeschützte, verschlüsselte Disk Images, in denen die sensiblen Daten hinterlegt sind. Zusätzlichen Schutz bietet ein so genanntes asymmetrisches Kryptographiesystem. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) widmete sich im IT-Grundschutz-Katalog dem Thema GnuPG und PGP.

GnuPG (GNU Privacy Guard) ist ein freies Kryptographiesystem, welches zum ver- und entschlüsseln von Daten sowie zum erzeugen und prüfen elektronischer Signaturen genutzt werden kann. Es wurde als Ersatz für das mittlerweile kommerzielle PGP entwickelt und kann unter GNU/Linux, Mac OS X und diversen anderen unixoiden Betriebssystemen (z.B. OpenBSD) als auch unter Microsoft Windows betrieben werden. ¹

verschlüsselte DMGs

Eine sehr einfache Variante ist also, mit Hilfe des Festplatten-Dienstprogramm ein “passwortgeschütztes Disk Image” zu erzeugen und die geheimen Informationen in diesem DMG zu hinterlegen. Nur wenn der Kommunikationspartner das nötige Passwort kennt, kommt er nun an diese Informationen heran. ²

Festplatten-Dienstprogramm Limitierung

Nachteil dieser DMGs ist, dass sie mindestens 10,5 MB groß sind und die Verschlüsselung maximal 256Bit-AES unterstützt. Außerdem können passwortgeschützte Disk Images aus Mac OS X nicht unter anderen Betriebssystemen (beispielsweise Linux oder Windows) genutzt werden.

verschlüsselte TrueCrypt File Container

Alternativ bietet sich als kleinster gemeinsamer Nenner der Einsatz von TrueCrypt an. Seit Version 7.1 wird auch Mac OS X 10.7 Lion vollständig unterstützt. Allerdings wird bei der Installation von TrueCrypt auch MacFUSE installiert, welches sich tief im System einnistet (u.a. mit einer Kernel Extension) und für das es schon sehr lange keine Aktualisierungen mehr gab.

Ein TrueCrypt-Image hat die Endung *.tc und kann mit wesentlich mehr Verschlüsselungsalgorithmen als auch stärkeren Hash-Algorithmen codiert werden. Ein weiterer Vorteil ist, dass TrueCrypt-Images nur 292 KB groß sein müssen (wobei dann auf dem angemeldeten Image nur 8 KB zur Verfügung stehen). Als Filesystem sollte FAT ausgewählt werden, da Mac OS Extended (HFS+) unter Linux und Windows nur mit Hilfe zusätzlicher Tools benutzt werden kann. ³

TrueCrypt 7.1 unter Mac OS X

Zu beachten ist außerdem, dass in Text-Dateien Umlaute und Sonderzeichen wie das ß verloren gehen können, zumindest war dies hier bei einem kurzen Test der Fall …

OpenPGP, GnuPG und die GPGTools für Mac OS X

Wenn man etwas Aufwand nicht scheut, kann man auf den OpenPGP-Standard zurückgreifen, mit Hilfe dessen man den gesamten E-Mail-Verkehr verschlüsseln kann. Dank der GPGTools (basierend auf GnuPG) ist die Installation und Einrichtung mittlerweile recht einfach. E-Mails können so nicht nur verschlüsselt, sondern zusätzlich auch signiert werden, so dass eine Manipulation der darin enthaltenen Daten sofort auffallen würde.

Installation der GPGTools

Das aktuelle Installations-Image findet man hier:

https://github.com/downloads/GPGTools/GPGTools/GPGTools-20111127.dmg

Aktualisierung (22. Dezemeber 2011, 17:55 Uhr): Wie sich gerade zeigte, bricht dieser Installer unter 10.5.8 Leopard mit einer Fehlermeldung ab. Sollte dies schon geschehen sein, als erstes den Uninstaller benutzen, um die gescheiterte Installation wieder sauber vom System zu entfernen. Mit dem folgenden Installer tritt dieses Problem dann nicht mehr auf:

https://github.com/downloads/GPGTools/GPGTools/GPGTools-20111219.dmg

GPGTools Meta-Package + Uninstaller

Die GPGTools installieren auf Wunsch ein PlugIn-Bundle für Apple Mail (in ~/Library/Mail/Bundles) als auch die Erweiterung “Enigmail” für Mozilla Thunderbird (in ~/Library/Thunderbird/Profiles/…). Letzteres nutze ich bei meiner Installation nicht.

Des Weiteren werden entweder MacGPG 1.4.11-6 (eine Universal Binary für PowerPC- und intel-Macs) oder besser gleich MacGPG 2.0.17-9 (nur für intel-Macs) installiert, der Zielpfad ist: /usr/local

Außerdem wird das GPG  Schlüsselbund (GPG Keychain Access) zur komfortablen Verwaltung der Keys im Programme-Ordner installiert.

Die GPGServices für  zusätzliche Dienste im Kontext-Menü des Finders landen in: /Library/Services

Die GPGPreferences werden nach ~/Library/PreferencePanes/ kopiert und stehen somit über die Systemeinstellungen zur Verfügung. In dem Zusammenhang sollte auch GPGTools Autofix installiert werden, welches dann über die GPGPreferences erreichbar ist (mehr dazu weiter unten in diesem Artikel).

Den Public OpenPGP Key muss man nicht mit installieren, er ist aber vorausgewählt und stört natürlich auch nicht.

Die Installations-Optionen der GPGTools

Generierung des eigenen Schlüsselpaares

Nach erfolgreicher Installation der GPGTools öffnet sich automatisch das GPG  Schlüsselbund und fordert auf, ein neues Schlüsselpaar zu erstellen. Als erstes wählt man einen Namen sowie die E-Mail-Adresse. Bei beiden trage ich protected@macon.cc ein. In den erweiterten Optionen kann man die Verschlüsselungsart einstellen (hier empfiehlt sich das voreingestellte RSA und RSA), die Schlüssellänge (bis zu 4096 Bit) und ob es ein Ablaufdatum für die Gültigkeit des Schlüsselpaares geben soll (ein Verfallsdatum erhöht die Sicherheit, ist aber nicht zwingend notwendig).

Einstellungen zur Erzeugung des Schlüsselpaares

Ein Klick auf “Schlüssel erstellen” fordert 2x ein Passwort an, selbstverständlich sollte dieses sorgsam gewählt werden und sehr sicher sein (im Idealfall mindestens 21 Zeichen lang mit Groß- und Kleinschreibung, Ziffern und Sonderzeichen).

Die Schlüsselgenerierung benötigt etwas Zeit (auf einem intel Core2Duo ca. eine Minute, auf einem PowerPC G5 sogar mehr als 5 Minuten). Um diesen Prozess zu unterstützen, sollte man während dessen andere Programme benutzen und in ihnen wie gewohnt arbeiten (Maus bewegen, Text tippen etc.), da dies bessere Werte im Zufallsgenerator erzeugt. Mit dem vergebenen Passwort wird man zukünftig Mails ver- und entschlüsseln.

Achtung: Aus Sicherheitsgründen ist es nicht zu empfehlen, dieses Passwort dauerhaft im Schlüsselbund von Mac OS X zu speichern.

Import und Export öffentlicher Schlüssel (public keys)

Nach erfolgreicher Schlüsselgenerierung kann man den öffentlichen Schlüssel (public key) exportieren.

Und erneut ist Aufmerksamkeit gefragt: Denn dabei ist darauf zu achten, dass keinesfalls das Häkchen bei “Geheime Schlüssel exportieren” gesetzt ist, denn so würde zusätzlich der so genannte “private key” exportiert werden.

Dieser “private key” darf auf keinen Fall in die falschen Hände geraten! Den Schlüssel also inkl. geheimen Schlüssel zu exportieren, ist zwar sinnvoll, um ihn an einem sicheren Ort zusätzlich zu speichern (Stichwort: Backup) bzw. um ihn auf einem Zweitrechner importieren und nutzen zu können. Aber niemals sollte dieser online versendet werden oder für andere Benutzer zugänglich sein.

Um die beiden Schlüsselarten besser unterscheiden zu können, kann man beim exportieren sinnvolle Namen verwenden, beispielsweise “schluessel-oeffentlich.asc” und “schluessel-oeffentlich+GEHEIM.asc”. Zur Sicherheit könnte man dann diesen wichtigen geheimen Schlüssel (private key) “schluessel-oeffentlich+GEHEIM.asc” auf einem passwortgeschützten Disk Image sichern (siehe Anfang dieses Artikels).

Tipp: Öffnet man die *.asc Schlüssel mit einem Text Editor, steht dort beim öffentlichen Schlüssel am Anfang:

—–BEGIN PGP PUBLIC KEY BLOCK—–
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)

Danach folgen jede Menge kryptische Zeichen und beendet wird die Datei mit der Zeile:

—–END PGP PUBLIC KEY BLOCK—–

Im Gegensatz dazu findet sich im geheimen Schlüssel zusätzlich folgende Information:

—–BEGIN PGP PRIVATE KEY BLOCK—–
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)

Wieder gefolgt von Zeichensalat und der letzten Zeile:

—–END PGP PRIVATE KEY BLOCK—–

Damit man mit Kommunikationspartnern Mails verschlüsselt und signiert austauschen kann, benötigt man deren öffentliche Schlüssel. Und natürlich benötigen diese wiederum den eigenen öffentlichen Schlüssel. Man könnte sich diese öffentlichen Schlüssel also gegenseitig per Mail senden oder auch direkt per USB-Stick austauschen.

Eine nette Option ist, den eigenen Schlüssel auf einem Schlüsselserver zu veröffentlichen. In den GPGPreferences (zu finden in den Systemeinstellungen) ist dafür der öffentliche OpenPGP-Server hkp://keys.gnupg.net des GnuPG-Projektes eingetragen, aber auch andere sind auswählbar.

Um also seinen Schlüssel zu veröffentlichen, markiert man im GPG Schlüsselbund den eigenen Schlüssel und wählt dann im Menüpunkt “Schlüssel” den Eintrag “An Schlüsselserver senden”. Mit “Nach Schlüssel suchen …” kann man so auch die Schlüssel der Kommunikationspartner finden, wenn diese ihren bereits veröffentlicht haben.

Die Schlüssel-IDs und SHA1-Fingerabdrücke dienen dabei als zusätzliche Identifikationsmöglichkeiten, um die Authentizität des Schlüssels durch den Kommunikationspartner bestätigen zu lassen.

Meinen öffentlichen Schlüssel (public key) kann man sich bei Interesse hier herunterladen:

http://www.macon.cc/downloads/OpenPGP/85BB6482-public-key.asc

Schlüssel-ID: 4A89881685BB6482
Fingerabdruck: D14F ABA8 8593 1A4D 7CC4 EF09 4A89 8816 85BB 6482
OpenPGP exported ASCII key

Einstellungen von GPGMail in Apple Mail

In Apple Mail sollte nun unter “Einstellungen” ein neuer Menüpunkt “GPGMail” hinzugekommen sein. In seltenen Fällen kann es leider vorkommen, dass der besagte Menüpunkt nicht angezeigt wird. Taucht dieses Problem auf hilft folgendes:

  1. Apple Mail beenden.
  2. Das Terminal öffnen und folgende Befehle eingeben (jeweils mit ENTER bestätigen):
  3. defaults write com.apple.mail EnableBundles -bool yes
  4. defaults write com.apple.mail BundleCompatibility -int 3
  5. Das Terminal verlassen: exit
  6. Apple Mail erneut starten. Der Menüpunkt “GPGMail” erscheint nun wie gewünscht.

Wie schon weiter oben erwähnt, sollte man die Option “Passphrase im Schlüsselbund speichern” nicht aktivieren. Außerdem sollte “Schlüssel des entsprechenden Emailkontos verwenden” aktiviert sein, damit die richtigen Schlüssel sowohl für die eigenen Adressen als auch die der Empfänger gewählt werden.

GPGMail Einstellungen – Schlüssel unter 10.6.8 Snow Leopard

Beim Unterpunkt “Verfassen” kann man “Generell alle Nachrichten verschlüsseln” aktivieren. Dies wirkt sich nur auf die E-Mail-Adressen aus, für die auch ein Schlüsselpaar vorhanden ist, stört also nicht bei weiteren E-Mail-Konten, welche man ohne Verschlüsselung wie gewohnt nutzen möchte. Die Option “Generell alle Nachrichten beim Verschlüsseln auch signieren” ist ebenfalls sinnvoll und sollte aktiviert werden. Des Weiteren ist die Option “Immer auch mit eigenem Schlüssel verschlüsseln” wichtig, sonst könnte man verschlüsselt gesendete E-Mails nicht mehr öffnen und lesen, da sie ja für einen Anderen verschlüsselt wurden. Wenn die Adressaten keine allzu betagten E-Mail-Programme einsetzen, ist es ratsam, zusätzlich die Option “OpenPGP/MIME benutzen” zu aktivieren, denn so werden zum Beispiel auch die Anhänge in einer E-Mail verschlüsselt.

GPGMail Einstellungen – Verfassen unter 10.6.8 Snow Leopard

Anmerkung: Leider sind all diese erwähnten Einstellungen, die unter 10.6.8 Snow Leopard möglich sind, bei mir nicht unter 10.7.2 Lion verfügbar (lediglich die Einstellmöglichkeit für ”OpenPGP/MIME benutzen” steht zur Verfügung). Entweder liegt das am “noch Alpha”-Status des Mail-PlugIns für Lion, oder aber diese Optionen sind einfach verschwunden? Das verschlüsselte und signierte senden und empfangen funktioniert jedoch problemlos.

Aktualisierung (18. Dezemeber 2011, 11:30 Uhr): Die Frage hat sich mittlerweile geklärt. Es liegt zum einen, wie schon vermutet, am noch frühen Alpha-Status der Lion-Version. Gleichzeitig wurde die Oberfläche von GPGMail willentlich vereinfacht, um die Hemmschwelle für Einsteiger zu verringern.

Limitierungen von GPGMail 2.0a4 unter 10.7.2 Lion

Die erste verschlüsselte und signierte E-Mail

Um loslegen zu können, sind nun noch zwei Voraussetzungen zu prüfen: Zum einen sollte man die öffentlichen Schlüssel seiner Kommunikationspartner erfolgreich in das GPG Schlüsselbund importiert haben. Außerdem sollten alle Kommunikationspartner den eigenen öffentlichen Schlüssel in ihr GPG Schlüsselbund importiert haben.

Schreibt man nun eine neue E-Mail, erscheint im Mail-Fenster eine zusätzliche Zeile “OpenPGP”, in der man die Verschlüsselung und Signierung einfach  an oder aus schalten kann (unter 10.7 nur noch mit kleinen Icons ersichtlich).

Verfassen einer E-Mail unter 10.6.8 Snow Leopard

Klickt man auf “Senden” erscheint die Passwort-Abfrage, in der man das entsprechende OpenPGP-Schlüsselpaar-Passwort einträgt und mit “OK” bestätigt (“Anzeigen” sowie “Im Schlüsselbund sichern” sollte natürlich auch hier deaktiviert bleiben).

Passwort-Abfrage vor dem Versenden

Was beim Einsatz der GPGTools zu beachten ist

Bei der täglichen Arbeit mit verschlüsselten und signierten E-Mails zeigte sich, dass Mails in reiner Textform kompatibler sind. Nicht selten kam es vor, dass Mails mit formatiertem Text sich nicht korrekt ver- oder entschlüsseln ließen. In einer reinen Mac-Umgebung mit identischen Mail-Programmen oder sogar Versionen taucht dieses Problem naturgemäß weniger häufig bis gar nicht auf. Sobald Kommunikationspartner aber auch Windows oder Linux und entsprechend andere E-Mail-Programme nutzen (Microsoft Outlook zum Beispiel oder Claws Mail), ist es ratsam, pure Textmails ohne Formatierungsmöglichkeiten zu nutzen.

Des Weiteren sollte bedacht werden, dass die Option BCC (Blindkopie) bei verschlüsselten E-Mails einen Fallstrick birgt: Wird eine verschlüsselte E-Mail an mehrere Empfänger gleichzeitig geschickt, werden automatisch alle öffentlichen Schlüssel der Adressaten mitgesendet! BCC ist in dem Fall also nutzlos und sollte nicht verwendet werden, wenn die Empfänger nichts von den jeweils anderen Empfängern wissen sollen. Es hilft also nur, die E-Mails an jeden geplanten BCC-Empfänger einzeln zu schicken.

Und noch eine Information dürfte von Interesse sein: OpenPGP verschlüsselt den gesamten Text einer E-Mail und bei aktivierter “OpenPGP/MIME”-Option auch die Anhänge. Die Kopfzeilen bleiben jedoch im Klartext erhalten: Adressaten, Absender, Betreff sowie alle beteiligten Server. Das heißt, die Mail-Kommunikation selbst bleibt nachvollziehbar (Transportdaten). Und natürlich ist auch ersichtlich, dass es sich um verschlüsselte Daten handelt.

Vorsicht ist außerdem geboten bei System-Aktualisierungen. So könnte ein Update auf ein kommendes 10.7.3, 10.7.4 etc. das Mail-PlugIn außer Gefecht setzen, so dass bis auf Weiteres keine Mails mehr direkt im Mail-Programm ver- und entschlüsselt werden können. Abhilfe schaffen in solchen Fällen eventuell die GPGPreferences in den Systemeinstellungen. Dort gibt es unter dem Reiter “About” die Option “Fix GPGTools”.

“Fix GPGTools” ist eine Option in den GPGPreferences

Dabei werden u.a. zwei IDs angepasst, mit deren Hilfe Apple versucht, die Kompatibilität von Mail-PlugIns zu gewährleisten. Sollte dies nicht helfen, muss man ein entsprechendes Update der GPGTools abwarten.

Eine Notlösung in solchen Fällen ist, sich eine verschlüsselte Mail im Quelltext anzeigen zu lassen (Apple Mail/Darstellung/E-Mail/Reine Datei), dann alles von

—–BEGIN PGP MESSAGE—–

bis

—–END PGP MESSAGE—–

zu markieren und in einer *.txt-Datei zu speichern. Diese kann man dann mit Hilfe des Kontext-Menüs im Finder umwandeln lassen (Rechtsklick auf die *.txt-Datei, Dienste, OpenPGP: Decrypt). Darauf hin erscheint die Passwortabfrage, so wie man es auch aus Apple Mail gewohnt ist. Man gibt also die entsprechende Passphrase ein und die nun entschlüsselte Datei wird gespeichert und kann somit im Klartext geöffnet werden.

OpenPGP und iOS

Für iOS-Geräte existieren derzeit vier Lösungen für die Nutzung von OpenPGP. Mobile OpenPGP steckt dabei noch in einer frühen experimentellen Alpha-Phase, Ziel ist es mit Hilfe von JavaScript OpenPGP direkt in einem WebKit-basierten Browser nutzen zu können.

Im iOS-AppStore gibt es außerdem die drei kommerziellen Anwendungen SecuMail (39,99 €), oPenGP (2,99 € bzw. als Lite-Version kostenfrei zum testen) sowie seit kurzem iPGMail (1,59 €).

Das Zertifikat-basierte S/MIME-Verfahren

Diese konkurrierende Lösung ist eher für größere Firmen und Behörden geeignet, man benötigt zur Nutzung ein X.509-basiertes Zertifikat. Zwar kann man als Privatperson kostenfreie X.509-Zertifikate erhalten (z.B. von CAcert). Das Problem ist jedoch, dass CAcert in vielen E-Mail-Clients und Web-Browsern noch nicht in der Zertifikatsdatenbank als vertrauenswürdige Zertifizierungsstelle eingetragen ist oder von einer dort eingetragenen Root CA zertifiziert wurde. Ein Benutzer, der eine Verbindung zu einem Server mit CAcert-Zertifikat aufbaut, wird daher eine Meldung erhalten, dass die Herkunft des Zertifikates nicht überprüft werden konnte.

Kostenfreie Zertifikate mit einer reduzierten Gültigkeitsdauer von 3 Monaten gibt es von Comodo InstantSSL. Der Vorteil gegenüber CAcert-Zertifikaten wäre, dass diese auch in den Zertifikatsdatenbanken gängiger Software als vertrauenswürdig gelistet sind.

Ein Jahr lang gültige kostenfreie Zertifikate, die ebenfalls in den Zertifikatsdatenbanken als vertrauenswürdig gelistet sind, werden von Start SSL als “StartSSL Free” und von TC Trustcenter als “TC Internet ID” angeboten.

Seit Version 5 von iOS wird S/MIME auch direkt in Mail auf iPhone, iPad und iPod unterstützt.

Meiner Meinung nach ist der Einsatz von S/MIME jedoch nur sinnvoll, wenn man sich für kostenpflichtige Zertifikate entscheidet, deren Gültigkeit nicht auf 3 Monate oder maximal 1 Jahr beschränkt ist. Davon abgesehen schockten auch die in diesem Sommer entdeckten Probleme mit diversen Zertifizierungsstellen …

Deshalb scheint mir eine OpenPGP-basierte Lösung attraktiver zu sein.

Fazit

Es gibt zwar nach wie vor einige kleinere Probleme mit den GPGTools, insgesamt funktioniert die beschriebene Lösung aber stabil und zuverlässig. Wer aus seinen E-Mail-Postkarten zukünftig E-Mail-Briefe machen möchte, sollte es auf einen Versuch ankommen lassen. Löblicherweise gehört zu den GPGTools auch ein Uninstaller, so dass man alle Komponenten bei Problemen wieder sauber vom System entfernen kann.

Übrigens: Eine deutschsprachige Version des GPGTools wiki ist in Vorbereitung. Eine weitere ausgezeichnete Informationsquelle wäre der GPGTools support (auch hier bekommt man Fragen im Zweifelsfall auf deutsch beantwortet). Zu guter Letzt sei noch auf diese sehr informative und interessante Seite verwiesen, dort erfährt man u.a. Wissenswertes zur Geschichte von PGP, GnuPG und Co.

¹ Für die Nutzung von OpenPGP unter Windows bietet sich der Einsatz von GPG4Win an.

² Um Brute-Force-Attacken zu erschweren, sollte selbstverständlich ein sicheres, langes Passwort benutzt werden.

³ Es sei denn, Mac OS Extended (HFS+) wird direkt in TrueCrypt unterstützt – dann böte sich dies natürlich als Alternative zu FAT an. Leider habe ich momentan keinen Rechner zur Hand, mit dem ich dies testen könnte.

John Siracusa nimmt Mac OS X unter die Lupe

Schon seit den ersten Versionen von Mac OS X (Developer Preview 2, Developer Preview 3, Developer Preview 4, Public Beta, 10.0, 10.1, 10.2, 10.3, 10.4, 10.5) ist John Siracusa ein Garant für qualitativ hochwertige Reviews zum Thema Mac OS X.
Ars Technica veröffentlichte nun seinen neuesten Beitrag: Den wohl netzweit bisher umfangreichsten Artikel zu Mac OS X 10.6 Snow Leopard. Lesenswert!

Update: Pünktlich zur heutigen Veröffentlichung von Mac OS X 10.7 Lion hat Ars Technica wieder einen sehr ausführlichen Artikel dazu veröffentlicht.

Webseiten im Internet Explorer 6 testen – Teil 2

Heute testete ich eine weitere Möglichkeit, welche im ersten Moment recht komplex erscheint, letztlich aber einfach einzurichten ist.

Die Rede ist von ies4osx in Kombination mit X11 sowie Darwine.

Da X11 von Apple nur stiefmütterlich gepflegt wird (Version 2.1.6 vs. Version 2.4.0) und auch das offizielle Darwine der aktuellen Wine-Entwicklung etwas hinterherhinkt (Version 0.9.27 vs. Version 1.0.1), empfielt es sich, folgende Quellen zu benutzen:

1. Beim XQuartz Projekt erhalten wir X11:

X11-2.4.0.dmg (69,9 MB)

X11

2. Auf der Webseite von Mike Kronenberg finden wir eine vorkompilierte aktuelle Version von Darwine (inkl. Freetype und TRiX):

Darwine-x86-1.0.1.dmg (27,2 MB)

Darwine

Sind X11 und Darwine installiert, ist es an der Zeit, sich ies4osx zu installieren: ies4osx-3_0_1.zip (581 KB)

ies4osx

Der Installer ist im Prinzip selbsterklärend.

ies4osx_installer

Auf dem Schreibtisch findet sich nun der Internet Explorer 6, welcher in X11 startet.

Internet_Explorer_6_X11_small

Das Rendering der Seiten entspricht leider nicht zu 100% dem, was man im Internet Explorer 6 unter einem “echten” Windows zu sehen bekommt. Für einen kurzen Test und die Vermeidung der gröbsten Schnitzer bei der HTML- und CSS-Entwicklung ist es aber sicher ausreichend.

Als wirklich problematisch erweist sich die Einbindung des Internet Explorer 7. Hier hat man nicht nur mit Rendering-Problemen zu kämpfen, sondern mit ungewöhnlich hoher CPU-Last bis hin zu Abstürzen.

Für einen sauberen und zuverlässigen Test sind meiner Erfahrung nach VMware Fusion + Windows XP + Multiple IE das beste Gespann.

Webseiten im Internet Explorer 6 testen

Leider sind Webentwickler bei bestimmten Projekten nach wie vor darauf angewiesen, Ihre Seiten auch unter dem veralteten Microsoft Internet Explorer 6 zu testen. Da die Entwicklung des Internet Explorer für Mac OS X schon mit der Version 5.1.7 eingestellt wurde, kommt man in diesem Fall nicht um Windows herum. Seit in den Apple-Rechnern intel-Prozessoren arbeiten, lässt sich das Betriebssystem aus dem Hause Microsoft jedoch in annehmbarer Geschwindigkeit nutzen (VirtualPC wie auch GuestPC auf PPC-Macs waren bzw. sind im praktischen Arbeitsalltag leider kaum zu gebrauchen).

Für “Windows auf dem Mac” bieten sich verschiedene Möglichkeiten an: Entweder richtet man sich mit Hilfe von Apples BootCamp eine Windows-Partition parallel zur Mac OS X Partition ein oder aber man nutzt eine Virtualisierungslösung wie z.B. VMware Fusion, Parallels Desktop oder VirtualBox von Sun. Das auf WINE basierende CrossOverX verzichtet komplett auf Windows, unterstützt den IE6 bisher aber nur unzureichend. Hier sorgen vor allem fehlende Windows-Schriften für diverse Rendering-Probleme.

Da eine Lösung per Bootcamp-Partition einen umständlichen Neustart in Windows erfordert und die beiden führenden Virtualisierungslösungen VMware Fusion und Parallels Desktop kommerzielle und damit kostenpflichtige Lösungen sind, werde ich mich in diesem Artikel auf das frei erhältliche VirtualBox konzentrieren. Mit einem bei Microsoft erhältlichen VirtualPC-Festplattenabbild lässt sich sogar die Anschaffung einer Windows-Lizenz vermeiden.

Sun_VirtualBox_small

Zuallererst läd man sich hier die Datei “IE6-XPSP3.exe” herunter:

Um die .exe-Datei extrahieren zu können, installieren wir uns das Kommandozeilentool RAR.

Aus dem extrahierten Archiv kopieren wir uns die beiden Kommandozeilenbefehle rar sowie unrar in unser bin-Verzeichnis (Administrator-Identifizierung erforderlich).

CLI rar & unrar

bin ist einer der vielen unsichtbaren Ordner von Mac OS X, wir erreichen diesen aber bequem über das Finder-Menü “Gehe zu/Gehe zum Ordner …”.

Gehe zum Ordner

Ein “unrar e” per Terminal und die Datei “IE6-XPSP3.exe” per drag’n'drop eingefügt entpackt uns nun die Datei (dies dauert ca. eine Minute).

unrar_e_dateipfad

In unserem Benutzerverzeichnis finden wir nun die Datei “XP SP3 with IE6 2009-Apr.vhd”, dies ist das von uns benötigte Festplattenabbild, welches erfreulicherweise automatisch von VirtualBox akzeptiert wird – Konvertierungsorgien, wie noch in älteren Versionen nötig, gehören somit der Vergangenheit an.

Beim Einbinden dieses Images in die VirtualBox läuft dennoch nicht alles so sauber ab wie bei den kommerziellen Mitbewerbern. U.a. muss man, auch wenn man die mitgelieferten “Gasterweiterungen” installiert hat, den Ethernettreiber manuell installieren. Diesen findet man glücklicherweise auf den Seiten von AMD:

http://www.amd.com/us-en/assets/content_type/utilities/V4.51.zip

Auch der freigegebene “Gemeinsame Ordner” wird leider nicht so komfortabel in die virtuelle Maschine integriert, wie man das vielleicht von VMware oder Parallels gewohnt ist.

Erst der manuelle Weg über “My Network Places”, “Add A Network Place”, “Choose Another Network Location”, “Browse”, “Entire Network” und schließlich “VirtualBox Shared Folders” führt hier zum Ziel.

Ist der “WinXP_SignedDriver” aber einmal installiert, kann man endlich auch den Internet Explorer 6 zum Testen der eigenen Webseiten nutzen.

IE6 Test Rendering

Die kleinen Ungereimtheiten enden hier aber noch nicht: Auch mit den USB-Treibern gibt es leider Probleme, so dass z.B. ein USB-Stick nicht eingebunden wird. Auch das von VirtualBox verlangte “Service Pack 3″-Image konnte diese Probleme nur teilweise beheben. Ja, selbst der Ton funktioniert hier bisher nicht aufgrund fehlender Audiotreiber.

Summa summarum ist VirtualBox eine interessante, weil komplett kostenfreie Variante, den Internet Explorer 6 unter Mac OS X für Testzwecke zu nutzen.

Die wenigsten Probleme und den besten Support hat man meiner Erfahrung nach bei VMware. 29,90 € berappen Schüler, Studenten, Lehrer und Dozenten, alle anderen zahlen 49,90 €. Eine 30-Tage-Demoversion ist ebenfalls verfügbar.

Bleibt lediglich abzuwarten, ob Microsoft erneut neue VPC-Images online stellt (so wie schon einmal im April 2009 geschehen), denn das aktuelle Image läuft Ende August 2009 ab.

Was mich interessiert: Wie testet Ihr Eure Webseiten auf IE6-Kompatibilität?