Ihren Schlüssel bitte

Als ich las, dass es nach Ansicht von David Cameron keine Kommunikation geben dürfe, die von der Regierung nicht einsehbar sei, hielt ich es für eine schlechte Idee eines konservativen britischen Politikers. Heute muss ich jedoch folgenden Satz auf Zeit-Online verdauen:

»Die Behörden in Europa wollen einen Nachschlüssel für jede digitale Tür, die es in der EU gibt.«

Und die deutsche Regierung, die sich noch vor kurzem mit den Federn des Datenschutzes schmücken wollte, sei eifrig dabei Forderungen nach besagtem Nachschlüssel zu unterstützen.

Bis auf Weiteres ist es demnach die beste Idee, vertrauliche Informationen, und wo möglich alle anderen Unterhaltungen, direkt auf dem eigenen Gerät so zu verschlüsseln dass sie nur durch Empfänger_in entschlüsselt werden kann:

»Diesen Baustein [verschlüsselte Kommunikation] wollen die europäischen Regierungen nun durchlöchern und damit weniger tragfähig machen. Umso wichtiger wird die sogenannte Ende-zu-Ende-Verschlüsselung, also das Sichern der Nachricht auf dem eigenen Gerät mit Hilfe von Programmen wie Pretty Good Privacy. Die Pläne der EU greifen nur die Verschlüsselung bei den Providern an, sichert jeder Nutzer selbst, ist das nicht ohne Weiteres zu knacken.«

Wie die eigene E-Mail-Kommunikation verschlüsselt werden kann, erläuterte ich kürzlich in dem Artikel ›E-Mails verschlüsseln‹.

Sicher kommunizieren

Auf die Secure Messaging Scorecard der EFF wurde ich durch einen Tweet von Matthias Pabst aufmerksam. Darin wurde auf die Einschätzung der EFF hingewiesen, dass iMessage und FaceTime sicher seien. Da mir eine sichere Kommunikation wichtig ist, und ich die genannten Dienste aus dem Hause Apple gerne nutze, folgte ich dem Link, und gelangte kurz darauf zur Secure Messaging Scorecard.

sicher vernetzt

Die Electronic Frontier Foundation hat sich zum Ziel gesetzt Bürgerrechte im digitalen Zeitalter zu verteidigen. Die Secure Messaging Scorecard ist das Ergebnis einer groß angelegten Untersuchung von Diensten und Anwendungen mit denen wir tagtäglich kommunizieren. Untersucht wurde anhand von sieben Kriterien:

  1. Ist die Kommunikation während der Übertragung verschlüsselt?
  2. Ist die Kommunikation durch einen Schlüssel geschützt, auf den der Anbieter keinen Zugriff hat?
  3. Ist es möglich die Identität des Gegenübers unabhängig zu identifizieren?
  4. Sind die Nachrichten auch dann noch sicher wenn der Schlüssel geklaut wurde?
  5. Ist der Code öffentlich, so dass er überprüft werden kann?
  6. Ist die Verschlüsselungsmethode nachvollziehbar dokumentiert?
  7. Wurde die Sicherheit von einer unabhängigen Stelle überprüft?

Welche Kriterien auf die Dienste und Anwendungen zutreffen, die ich und mein Umfeld regelmäßig verwenden habe ich hier mal kurz aus der Scorecard zusammenkopiert:

Auswahl aus der Secure Messaging Scorecard der EFF, Update 11-10-2014

Wie die EFF heute (10.11.2014) bekannt gab, verliert Skype den Haken in der zweiten Spalte, da es momentan nicht ausgeschlossen werden kann, dass Microsoft sich Zugang zu den Konversationen der Nutzerinnen und Nutzer verschafft.


Bildnachweis:

  1. Das Foto wurde von Martin Gommel aufgenommen.
  2. Die Auswahl der Kommunikationstools habe ich aus der Secure Messaging Scorecard der EFF zusammengestellt und verwende sie hier unter der Creative Commons Lizenz.

Mit Gmail verschlüsselt kommunizieren

Gestern erschien im Google Online Security Blog ein Artikel zu verschlüsselter E-Mail-Kommunikation. Unter dem Namen End-To-End veröffentlicht Google eine Chrome Erweiterung, die verschlüsselte Kommunikation auch für diejenigen möglich macht, die ihre Mails über die Weboberfläche von Gmail nutzen.

Mir gefällt dieser Ansatz, da Google damit verschlüsselte Kommunikation aus der Nerd-Ecke befreit und es mit dieser Chrome-Erweiterung leicht möglich sein wird verschlüsselte E-Mails zu empfangen und versenden.

Bisher ist diese Erweiterung noch nicht im Chrome Web Store, da die Entwickler ihr noch etwas Zeit und Aufmerksam widmen wollen. End-to-End setzt auf OpenPGP, was ich sehr gut finde, da es sich hierbei um ein offenes Datenformat handelt.

Kürzlich habe ich hier bereits über verschlüsselte E-Mail-Kommunikation geschrieben, und werde dieses Thema weiter im Auge behalten.

Bildschirmfotos mit dem Firefox

Mit dem Firefox lassen sich schnell Bildschirmfotos von Webseiten erstellen. Die Konsole des Firefox bietet eine sehr praktische Funktion, mit der schnell und einfach Bildschirmfotos von kompletten Webseiten erstellt werden können.

Bildschirmfoto mit dem FirefoxMit der Option --chrome wird die aktuelle Browseransicht festgehalten

Über die Tastenkombination Shift+F2 lässt sich die Konsole einblenden. Gibt man dort Folgendes ein und bestätigt die Eingabe, wird ein Bildschirmfoto mit dem Namen ›test-foto.png‹ der kompletten Webseite erstellt:

screenshot test-foto --fullpage

Über help screenshot kann ein Hilfemenü aufgerufen werden, dass die unterschiedlichen Möglichkeiten erläutert.

Diese Funktion ist aus meiner Sicht dann sehr hilfreich, wenn Bildschirmfotos einer kompletten Webseite und nicht nur des dargestellten Ausschnitts in einer bestimmten Fensterbreite benötigt werden.

Update 03.11.2018

Ab Version 62 des Firefox ist diese Funktion Teil der Web-Konsole in den Entwickler-Werkzeugen. Die Syntax hat sich leicht geändert:

:screenshot test-foto --fullpage

Weitere Infos dazu in diesem Artikel in den Firefox Nightly News, und natürlich in der Hilfe der Entwickler-Werkzeuge.

Archiv erstellen und verschlüsseln

zip-Archiv

Immer wieder möchte ich einer Kundin oder einem Kunden ein Archiv mit Dateien zu einem Projekt zur Verfügung stellen. Meist handelt es sich dabei um Dateien die sich nicht frei im Internet herumtreiben sollten. Aus diesem Grund bevorzuge ich es – immer mehr – Archive zu erstellen die durch ein Passwort geschützt sind. Dies kann einerseits mit Programmen wie »Rucksack« erreicht werden. Doch wer einmal auf den Geschmack gekommen ist das Terminal seines Rechners zu benutzen, kann einen solchen Vorgang sehr einfach ohne ein weiteres Programm durchführen.

Folgender Befehl erstellt ein Archiv aus den Dateien eines Ordners und schützt es mit einem Passwort:

$ zip -erj Pfad-zum-zip-Archiv Pfad-des-Ordners-der-gepackt-werden-soll
  • e steht für encrypt – das Archiv wird verschlüsselt, und kann nur durch Eingabe des Passworts entpackt werden
  • r steht für recurse-paths – alle Dateien des Ordners sollen zu einem Archiv hinzugefügt werden
  • j steht für junk-paths – der Pfad zum Ordner wird nicht gespeichert

Im Terminal sieht der gesamte Vorgang so aus:
Zip-Archiv im Terminal erstellen

-erj ~/Desktop/ordner.zip ~/Desktop/ordner

Der Befehl meines Beispiels enthält die eben beschriebenen Variablen und erstellen auf dem Schreibtisch ein Archiv das alle Dateien des Ordners »ordner« enthält der sich ebenfalls auf dem Schreibtisch befindet.

Das Passwort mit dem das Archiv geschützt werden soll muss zweimal eingegeben werden, und wird im Terminal nicht sichtbar wiedergegeben.

Meistens stelle ich einen Ordner von Dateien zusammen bevor ich ein Archiv erzeuge, dies ist jedoch nicht obligatorisch, es lassen sich auch verschiedene Dateien zu einem Archiv zusammenfügen. Standardmäßig bleibt der Pfad des Ordners im Archiv erhalten, was ich jedoch nicht möchte, weshalb es mir wichtig war mit j den Pfad nicht mit zu speichern und lediglich den Inhalt des Ordners in meinem Archiv zu behalten.

Sollen die im Ordner enthaltene Struktur erhalten bleiben, verzichte ich auf das j, wechsle vor dem Archivierungsvorgang in den Ordner in dem sich der Ordner befindet. Liegt ordner auf meinem Schreibtisch, wechsle ich mit cd ~/Desktop dorthin, und verwende dann:

$ zip -er ordner.zip ordner

Klickt die Empfängerin schließlich auf das Archiv wird sie aufgefordert das Passwort einzugeben um am die Daten zu gelangen.

Das Passwort eingeben

Nach Eingabe des Passworts entpackt sich das Archiv wie gewohnt und die Daten stehen der Person zur Verfügung, die über das Passwort verfügt.


Eine ausführliche Beschreibung der Funktionen finden sich auf den Seiten des Mac OS X Handbuchs.

E-Mails verschlüsseln

Irgendwo habe ich kürzlich gehört, dass die Kommunikation über E-Mail ungefähr so privat ist wie eine Unterhaltung in einem vollbesetzten Bus. E-Mails fühlen sich – oder sollte man hier besser in der Vergangenheitsform schreiben – fühlten sich so sicher an wie ein Brief, während sie unverschlüsselt eher einer Postkarte glichen. Die aktuellen Vorkommnisse und die bisher sture Haltung unserer Regierenden etwas Klarheit in die gezielte Bespitzelung zu bringen, motivierten mich dazu im Urlaub etwas mehr über verschlüsselte Kommunikation nachzudenken. Ein Ergebnis dieses Nachdenkens ist die Kommunikation mit verschlüsselten E-Mails.

Kommunizieren zwei Personen über verschlüsselte E-Mails miteinander, findet die Verschlüsselung und das Entschlüsseln mit den jeweils eigenen Schlüsseln der Personen auf deren Gerät, also nicht auf irgendeinem Server, statt. Um so miteinander kommunizieren zu können bedarf es eines Schlüssels. Es gibt zwei gängige Schlüssel OpenPGP und S/MIME.

Beiden Methoden habe ich nun getestet, und mich dann dafür entschieden hauptsächlich S/MIME zu verwenden, da diese Verschlüsselungsmethode etwas einfacher im Zusammenspiel von Mac-Mail und der Mail-App auf den iOS-Geräten zu verwenden ist. Hat man einmal die Zertifikate installiert und aktiviert, lassen sich die Nachrichten bequem im jeweiligen Programm lesen, schreiben, verschlüsseln und entziffern. Und da ich gerne sowohl auf dem Rechner als auch auf den mobilen Geräten in der Lage sein will verschlüsselt zu kommunizieren erscheint mir S/MIME momentan als passendere Möglichkeit.

Wie geht das eigentlich?

Wie man an einen Schlüssel kommt und das Ganze dann auf den Geräten mit dem Apfel einrichtet erfährst Du in diesem guten Artikel von Sebastian Düvel auf t3n.de, er beschreibt darin detailliert wo ein S/MIME-Schlüssel zu bekommen ist, und wie die Mail-Programme auf dem Mac und den iOS-Geräten einzurichten sind um verschlüsselte Nachrichten empfangen und versenden zu können.

Kleiner Tipp

Mit den GPGtools ist es möglich die Standard-Methode zur Verschlüsselung/Signierung auszuwählen. Soll in Mac-Mail standardmäßig nicht mit OpenPGP sondern S/MIME verschlüsselt werden, kann dies über folgende Zeile im Terminal eingestellt werden:

defaults write org.gpgtools.gpgmail DefaultSecurityMethod -int 2

Quelle: GPGMail 2 hidden settings

Verschlüsselt mit mir kommunizieren

Über meine übliche Adresse daniel@depone.de kann verschlüsselt kommuniziert werden. Gerne kannst Du mich entweder mit einer S/MIME oder OpenPGP signierten E-Mail anschreiben, dann können wir die Schlüssel austauschen und fortan verschlüsselt kommunizieren. Meinen öffentlichen OpenPGP-Schlüssel findest Du hier.

Vertrauen und Grundrechte

In seiner Kolumne auf SPON verdeutlicht Sascha Lobo eindrücklich, dass es bei #PRISM und Ähnlichem um weit mehr geht als die bewusste "Abhörung" der Bevölkerung. Es geht um die Grundrechte.

Es geht bei diesem Grundrechte-Skandal nicht um konservative oder progressive Einstellungen und auch nicht mehr um die Abwägung zwischen Sicherheit und Freiheit. Die ausufernde Spionagemaschinerie ist keine Krise des Internets, sondern eine Krise der Demokratie, die sich am Internet entzündet hat.

Sascha Lobo, Wer lesen kann, kann auch schreiben.

Wie der Titel schon deutlich macht ist der Weg von Lesen zum Schreiben, also vom "Abhören" zur Manipulation der Daten nicht weit. Zieht man die technischen Möglichkeiten alle Bewegungen im Wohnraum per WLAN aufzuzeichnen, was an WiSee deutlich wird, mit ein, verstummt wahrscheinlich auch das Letzte "ich habe nichts zu verbergen".

Ich wünsche mir eine Verwandlung des Misstrauens der Mächtigen, in ein vertrauensvolles Miteinander. Dafür aber brauchen wir wohl eine andere Gesellschaft, und auf dem Weg dorthin klarere Reglementierungen und Transparenz dessen was Regierungen und ihre (Geheim-)Dienste dürfen.

Hinter den Kulissen

Für die meisten Nutzerinnen und Nutzer von Webseiten arbeiten die ›Rendering Engines‹ der Browser unbemerkt. Sie kümmern sich hinter den Kulissen darum, dass die Webseite im Browser der Wahl sauber angezeigt wird und ordentlich benutzt werden kann.

Im Februar sorgte eine Information aus der CSS-Arbeitsgruppe des W3C für einige Aufmerksamkeit. Daniel Glazmann führte in seinem bekannten Blogeintrag aus, dass einige Browserentwickler überlegten das -webkit-Prefix einzuführen, da es eine (zu) große Anzahl von Webseiten gab, die sich nicht um die Prefixe anderer Browser scherten und lediglich für -webkit- entwickelten. Mit der Ankündigung von Opera zukünftig auch auf WebKit zu setzen schien dieser Trend noch weiter unterstützt zu werden.

Gestern veröffentlichte allerdings das Entwickler-Team von Chrome, dem hauseigenen Browser von Google, einen Blogeintrag, in dem sie darüber sprachen, in Zukunft eine neue Rendering-Engine einzusetzen. Diese Engine hört auf den Namen ›Blink‹ und verfolgt folgende Mission: »To improve the open web through technical innovation and good citizenship«.

Bei Blink handelt es sich um einen WebKit-Fork, weshalb in naher Zukunft nicht mit großen Abweichungen von WebKit zu rechnen sein wird, was sich im Laufe der Zeit jedoch ändern könnte.

Im eben erwähnten Blogeintrag des Chrome-Entwicklerteams heißt es:

»… we believe that having multiple rendering engines—similar to having multiple browsers—will spur innovation and over time improve the health of the entire open web ecosystem.«

Quelle: The Chromium Blog – Blink: A rendering engine for the Chromium project

The Verge bringt noch folgenden Aspekt ins Spiel:

»Most interesting of all is what this could mean for Google — it currently is trying to gain traction with Chrome OS, which of course is based almost entirely on the Chrome browser. A more powerful rendering engine could mean more powerful and useful apps within Chrome OS.«

Quelle: The Verge, Google forks WebKit with new Blink rendering engine for Chrome

Auch wenn sich zunächst „gefühlt“ nicht viel ändern wird, könnte diese Entscheidung dazu führen, dass die befürchtete Konzentration auf -webkit- nicht weitergehen wird, und somit Webseiten bewusst plattform- und browserübergreifend entwickelt werden.

Favicon

Jonathan T. Neal geht in seinem Blog der Frage nach wie eine Webseite am Besten mit einem Favicon versorgt wird. Hier geht’s zu seinem Artikel ›Understanding the Favicon‹.

Bevor wir uns den technischen Fragen nähern, hier eine kurze Definition des Begriffes ›favicon‹ aus der Wikipedia:

Ein Favicon (kurz für favorite icon, engl. für Favoriten-Symbol) ist ein kleines, 16×16 oder 32×32 Pixel großes Icon, Symbol oder Logo, das unter anderem in der Adresszeile eines Browsers links von der URL angezeigt wird und meist dazu dient, die zugehörige Website auf wiedererkennbare Weise zu kennzeichnen.

Quelle: Wikipedia: Favicon

Ursprünglich war das Favicon für die Ausgabe in Browsern vorgesehen, mittlerweile kommt es jedoch auch auf den Startbildschirmen von Smartphones und unter Windows 8 häufig vor, was die Frage nach Größe und Möglichkeiten der Einbindung aufwirft.

Es bietet sich daher an, ein Favicon in unterschiedlichen Größen anzubieten. Mittlerweile halte ich die Verwendung von „klassischen“ Favicons in 32×32 Pixeln und für den Einsatz auf Startbildschirmen 144×144 Pixel oder 241×241 Pixel für sinnvoll. Das wären dann 4 Dateien:

  • 32×32 Pixel – png und ico (klassische Favicons)
  • 144×144 Pixel – png (transparenter Hintergrund, für Windows 8)
  • 241×241 Pixel – png (Apple-Touch-Icon)

Diese Icons sollten laut des eingangs erwähnten Artikels folgendermaßen eingebunden werden:


<link rel="apple-touch-icon" href="path/to/touchicon.png">
<link rel="icon" href="path/to/favicon.png">
<!--[if IE]><link rel="shortcut icon" href="path/to/favicon.ico"><![endif]-->
<!-- or, set /favicon.ico for IE10 win -->
<meta name="msapplication-TileColor" content="#D83434">
<meta name="msapplication-TileImage" content="path/to/tileicon.png">
    

Da der IE10 keine Conditional Comments mehr annimmt, sollte zusätzlich zu diesen Angaben ein favicon.ico im Root-Verzeichnis der Webseite liegen. Auf den Startbildschirmen der iOS-Geräte gibt es die Möglichkeit die Icons entweder mit Überlagerungen darstellen zu lassen, oder durch den Zusatz -precomposed unverändert.

Weitere Artikel zum Thema:

Tools

Demonstration im Internet

Seit etwas mehr als einer Woche finden sich auf Twitter Nachrichten, die mit dem Hashtag #aufschrei versehen wurde. Mit diesem Hashtag sollen der alltägliche Sexismus und Übergriffe gegen Frauen auf unterschiedlichsten Ebenen sichtbar gemacht werden. In seiner Kolumne »Mensch-Maschine« hat Sascha Lobo etwas zur Bedeutung von Hashtags auf die öffentliche Meinungsbildung geschrieben, und sie mit der Bedeutung von Demonstrationen verglichen:

Die sozialen Medien sind die digitale Straße, und dort können Hashtags zu Internetdemonstrationen werden. Wie bei ihren nicht-digitalen Vorbildern wird durch die schiere Größe der digitalen Versammlung sichtbar, was den Leuten wichtig ist, aber unterpubliziert erscheint.

Quelle: Sascha Lobo – Die Mensch-Maschine: #digitaleöffentlichkeit – S.P.O.N.

Die öffentliche Sichtbarkeit dieses Filtermechanismus spricht aus meiner Sicht für das Medium Twitter, gerade im Vergleich mit Facebook oder Google+. Twitter scheint mir für eine solche Art der Kommunikation weitaus besser geeignet zu sein, als die auf Pinnwände und Ähnliches konzentrierte Netzwerke.

Mit diesem Eintrag möchte ich nur kurz auf die technische Seite dieses Hashtags hinweisen, inhaltlich habe ich mich hier kurz darauf bezogen.