Sichere E-Mail-Kommunikation in Zeiten von NSA- und GCHQ-Überwachung

In den letzten Wochen ist mir eine gewisse Unsicherheit aufgefallen, was E-Mail-Kommunikation angeht. Die Regel — zumindest bis vor ein paar Monaten — war es, dass der Transportweg von E-Mails nicht durchgängig verschlüsselt gewesen ist und Geheimdienste leichtes Spiel hatten und noch immer weitgehend haben, E-Mail-Kommunikation umfassend abzuhören und Nutzerprofile zu erstellen. Das gleiche gilt übrigens für Kriminelle, wobei die Grenze zwischen beiden Gruppen mittlerweise unklar ist:

  • Kollegen, Dienstleister, befreundete Unternehmen und Unternehmer drücken sich nicht mehr klar in E-Mails aus oder verzichten eher mal darauf, eine E-Mail zu schreiben.
  • Der Steuerberater schickt vertrauliche Informationen nicht mehr einfach so per E-Mail, was an sich schon mal gut ist und Medienkompetenz ausstrahlt.
  • Hotelrechnungen lässt man sich inzwischen ungern per Mail zustellen, weil man nicht weiß, wie sicher der Transportweg ist — und Hotelrechnungen dürften mit einiger Sicherheit zu den interessanteren Informationen für Geheimdienste zählen.

Was kann man tun, um der Unsicherheit entgegenzuwirken?

Grundsätzlich halte ich nichts von den politischen Bestrebungen, ein “deutsches” oder “europäisches” Mailserver-Kommunikationsnetz aufzuziehen, das “einheimische” oder gar “deutsche” Verschlüsselungsalgorithmen verwendet. Ich denke, in der IT-Branche ist es Konsens, dass diese Forderungen a) Unsinn sind und gegen den freien Geist des Internets verstoßen und b) die Forderung nach Entwicklung “eigener” Verschlüsselungsalgorithmen kaum umsetzbar (weil sehr teuer und langwierig) ist und es bereits sichere Algorithmen und Protokolle gibt, beispielsweise AES und TLS 1.2.

Man muss die vorhandenen sicheren Systeme und Programme nur mal einsetzen, richtig und konsequent.

Praktische Lösungen

Seit Jahrzehnten gibt es PGP (und die freie Umsetzung GPG). Das Programm verschlüsselt den Inhalt von E-Mails. Vorteile:

  • Die Software ist jahrelang im Einsatz und gilt als sicher
  • Ist verfügbar für alle Systeme
  • Freie Open-Source-Software

Es gibt aber auch Nachteile:

  • Das dem System zugrunde liegende Public-Key-Konzept ist zwar eigentlich einfach, aber für Laien dennoch nicht auf Anhieb verständlich
  • Die Benutzerfreundlichkeit von PGP/GPG-Programmen ist oft nicht besonders hoch, daher hat das System bislang keine hohe Verbreitung gefunden.
  • Metadaten wie Absender, Empfänger und Betreff werden nicht verschlüsselt. Das ermöglicht Abhörern noch immer, umfassende Kommunikationsprofile zu erstellen.

Die Gegenargumente möchte ich nicht als Grund verstanden wissen, auf PGP/GPG zu verzichten.

PGP/GPG sollte man sicherlich verwenden, insbesondere wenn es um Geheimnisträger wie Rechtsanwälte, Journalisten und Steuerberater geht.

Wichtiger finde ich dennoch, nicht nur den Inhalt von E-Mails zu verschlüsseln, sondern den Transportweg an sich. Der ist in drei Teile gegliedert:

  1. Der Weg vom Rechner des Absenders zu seinem Mailserver
  2. Der Weg vom Mailserver des Absenders zum Mailserver des Empfängers
  3. Der Weg vom Mailserver des Empfängers zum Rechner des Empfängers.

Bislang konnte man auf dem Weg zwischen Mailserver und Empfänger schon recht gut einstellen, ob und wie verschlüsselt wird. Zwischen Mailservern hingegen hat das mal geklappt und mal nicht. Empfänger und Absender haben in der Regel nicht erfahren, ob die Kommunikation verschlüsselt war oder nicht — das war quasi ein Glücksspiel. Mit dem Unterschied, dass man hinterher nicht erfahren hat, ob man gewonnen oder verloren hatte.

Die Situation verbessert sich langsam, zumindest in Deutschland — immerhin:

Mittlerweile gibt es deutsche Unternehmen, die explizit sichere Maildienste anbieten (ohne Gewähr oder Anspruch auf Vollständigkeit):

Besonderheit bei mailbox.org: Der Dienst wird von Heinlein Support GmbH betrieben. Das Unternehmen ist lange am Markt und genießt in der IT-Branche einen exzellenten Ruf (ich bekomme übrigens kein Geld für diese Empfehlung und auch keine sonstigen direkten Vorteile).

Angeboten wird neben Dateisynchronisierung die Möglichkeit, abgestuft auf die Art und Weise Einfluss zu nehmen, wie Mailserver untereinander kommunizieren dürfen (“egal”, “verschlüsselt”, “nachvollziehbar verschlüsselt”, “verschlüsselte Kommunikation nur mit bekannt sicheren Mailservern”, bei mailbox.org genannt “aus”, “encrypt”, “verify”, “secure”).

Erzwingt man Verschlüsselung und stößt der mailbox.org-Mailserver auf eine Gegenstelle, die die Sicherheitsanforderungen nicht erfüllt, schlägt die Kommunikation fehl und man bekommt eine Meldung darüber. Das ist so gewollt und stellt sicher, dass Daten nur verschlüsselt übertragen werden. Würde das jeder Mensch und jeder Mailserver so machen, hätten Geheimdienste und Kriminelle es sehr schwer, a) den Inhalt der Daten abzuhören und b) Kommunikationsprofile zu erstellen.

Ich empfehle daher allen meinen Kollegen, Geschäftspartnern und -freunden, sich einen sicheren Mail-Dienstleister zu suchen, zu nutzen, und ein hohes Datenschutzniveau einzustellen.

Schließlich wollen wir alle die Vorteile der E-Mail-Kommunikation weiterhin nutzen und uns nicht aus Angst vor Geheimdiensten und Kriminellen zurückziehen.

Weiterhin empfehle ich den Einsatz von PGP/GPG, mein öffentlicher Schüssel ist auf sks-keyservers.net zu finden.

Ich bin gerne kostenlos dabei behilflich, Euch/Ihnen bei der Einrichtung von PGP/GPG zu helfen, schließlich habe ich selbst Interesse daran, sicher zu kommunizieren.

PS: Was ist mit DE-Mail?

Es gibt dort bislang keine durchgehende Verschlüsselung. Kriminelle werden es mit DE-Mail sicherlich viel schwerer haben als im “freien Netz”, aber Geheimdienste hätten technisch noch immer eine Möglichkeit, auf den Inhalt und die Metadaten  zuzugreifen. Außerdem halte ich es für aussichtslos und Unsinn, mit nationalen Insellösungen globale Probleme lösen zu wollen.

Do we even need SSL?

“Do we even need SSL?” — In almost every project where hosting of some kind is involved this question comes up.

While SSL clearly can be improved it is the most easy way of secure transfer between web servers and web surfers.

In which cases is SSL expendable?

IMHO, encrypted data transfer via SSL is expendable when no private data or login credentials are being transmitted between the web server and you or visitors. That merely applies to static web sites only consisting of HTML, CSS, Javascript, images and nothing else.

In all other cases at least certain parts of a web site or web application should be transmitted via SSL only. The most common example is WordPress. Administrative access to WordPress should always be encrypted. There is a quite obvious reason: Imagine yourself in a Starbuck’s or any other place where you can freely access the Internet. You most probably are happy to have access — this is not the time to worry about other people eavesdropping on wifi connections.

The New York Post (via Bruce Schneier) has a nice blog post on this topic (the author meets a security consultant in Wi-Fi coffee shop for a live “hacking” demo):

He turned his laptop around to reveal all of this:

* Every copy of every e-mail message I sent *and* received.

* A list of the Web sites I visited.

* Even, incredibly, the graphics that had appeared on the Web sites I had visited.

None of this took any particular effort, hacker skill or fancy software. Anyone could do it. You could do it.

All Jon needed was a “packet sniffing” program; such software is free and widely available. (He used a Mac program called Eavesdrop.) It sniffs the airwaves and displays whatever data it finds being transmitted in the public hot spot.

I do not consider this even “hacking” as you only have to start a program that dumps wifi traffic. There are a bit more complicated ways that enable you to eavesdrop even on encrypted wifi traffic but that’s another story.

Security evangelist Bruce Schneier encrypts all of his web server’s transfer — so do I. A basic level of security can be obtained just by buying a SSL certificate and installing it/letting someone install it for you. Most web hosting services provide some way of protecting your web site traffic. If you only want to secure your administrative sections of your website and do not care for the extra bit of hassle that is involved with self-signed certificates you can get the security for free.

I do not say everyone should but you should at least let your web server encrypt sensitive data transfer such as administrative logins.

Randomly select a MySQL record

This is a reminder to myself as I have this problem every now and then. I thought I share this with you.

Ok the problem is to random(ish)ly select a record from a MySQL database in an efficient way without any scripting or programming. There are several more or less simple ways described everywhere on the web, one being

SELECT * FROM table_name ORDER BY RAND() DESC LIMIT 1;

It does the job. Very slowly though, it can take MySQL several seconds or even minutes to complete the query. After fiddling around for some time, I came up with this:

set @randomId=FLOOR(RAND()*(SELECT MAX(pk_field) FROM table));
PREPARE randomStmt FROM "SELECT * FROM table WHERE pk_field > ? LIMIT 1";
EXECUTE randomStmt USING @randomId

… where pk_field is a numeric primary key. Ok the query goes like this:

  1. Get the highest value for pk_field from table_name, multiply with a random number between 0…1, cut off decimals and store in variable randomId.
  2. Prepare a statement where we can insert randomId and retrieve the desired record with.
  3. Take the query, insert randomId and execute.

This runs very fast even with a large dataset. I hear your objections already… :)

“This is stupid. Why didn’t you use “COUNT(pk_field)” to find the end of the number range? Even then this approach would still be stupid BTW.” Because it is slow. I currently have a table with >1.8 million records and COUNT(pk_field) takes >1 seconds to complete. Not good. MAX(pk_field) is good enough in most cases. YMMV though.

“The query is not truly random and prefers records at the end of a large pk_field range gap!” True. That’s what I meant with “YMMV” :) My solution is not truly random and it is biased, especially when there are large gaps in pk_field. It works for me though and is random enough when there are no large pk_field gaps.

How to access Xing profiles via API and PHP

Yesterday I have dabbled in accessing Xing profiles via API. For years people were asking Xing to finally provide an API but they were hesitant because of the strict privacy laws in Germany. Xing has lost users in the last months and other social networks already have APIs so they were forced to provide an API as well. Competition *does* work apparently. :)

Since I don’t have time to make a polished product out of it I thought I share my result with you in the hope you will let me know what you did with it. Let’s go.

The goal is to access a Xing profile (your own for now as you would have to use production keys and have your Xing API app reviewed by Xing in order to access other people’s profiles) and display the profile as raw data for further processing. You can go from there, making the profile information look beautiful, store access tokens and user IDs for subsequent requests and so on.

  • Go to dev.xing.com and register as a Xing developer. Once you have, log in and retrieve your testing OAuth consumer key and consumer secret.
  • Get oauth-php library from Google Code, unpack it and push it on a web server.
  • Grab my Xing client example, unpack it and put it in oauth-php’s client example dir. Edit xing.php and enter your OAuth consumer key and consumer secret and the full callback URL to xing.php.
  • Call xing.php in your web browser. You will get redirected to Xing so that you — as a Xing user — can give your Xing API app permission to access your profile. Once you have given permission, Xing will redirect to the xing.php script which will display raw profile data. If everything went well that is…

Now you have a go. :)

The keys to running a successful WordPress blog — technically speaking

Heise online reports WordPress is going to clean up the plugins dir because plugins “suck” and that — despite this fact — WordPress has become a constant in the web because large blogs such as Smashing Magazine are using it.

How do large WordPress blogs like Smashing Magazine accomplish this when plugins suck so much?

In the past years I have responsible for many WordPress installations, including Smashing Magazine‘s WordPress installations. I think I can tell you the keys that make a blog running WordPress successful or unsuccessful, technically speaking.

It’s the plugins:

  • How many of them are installed – the less the better!
  • Which ones are installed — always look how experienced the plugin’s developer is!
  • How they got chosen — make a security audit, either by yourself if you are competent, or hire someone how is!

In fact there are many, many WordPress plugins out there that have been developed by, let’s say, inexperienced developers. There are *tons* of security issues out there. The more plugins you install, the more security issues you install.

When I take over as a WordPress sysadmin, the first thing I do is throw out all unneeded plugins. Then I update the remaining ones. Then I try to further reduce the amount of plugins, either by implementing features myself or by replacing plugins with more capable/secure ones.

Here’s my last tip: If you cannot find a decent, capable, and secure WordPress plugin that suits your needs, hire a good developer with a security background to create it for you. Obviously you have to make sure not to hire one of the inexperienced developers. Please don’t go collecting plugins like “Oh I take this, and this one as well, this one sounds nice too” — this is not going to work in the long run. A successful WordPress blog is *always* run by competent admins and developers, not by “WordPress plugin collectors”.

Of course there are other factors as well, like always having the most recent versions of them installed, or to have interesting contents, but those are the keys IMHO.

Quick tip for Java/Netbeans users on Linux

If you are using Linux (Ubuntu and Debian in my case) and are being haunted by unresponsive, CPU and memory hogging Java applications you might find this piece of information useful:

  1. Check if you are using OpenJDK by issuing “java -version” in a terminal.
  2. If something with “OpenJDK” comes up, follow instructions (in german, but you get the point) on how to switch to the Java JDK from Oracle.

Netbeans now runs like a breeze now. Enjoy :)