Konflikt mit libutf8proc: /usr/lib/libutf8proc.so.2

Ich habe mich entschlossen, die ab und zu auftretenden Probleme mit Arch Linux zu dokumentieren — für mich selbst hauptsächlich. Bei der hohen Update-Frequenz und den Rolling-Updates treten halt anders als bei Ubuntu oder Debian häufiger mal Hindernisse auf. Auf gehts:

Bei einem System-Update mit sudo pacman -Syu tritt gerade das Problem auf, dass das Update nicht durchläuft wegen eines Konflikts:

Fehler: Konnte den Vorgang nicht durchführen (In Konflikt stehende Dateien)
libutf8proc: /usr/lib/libutf8proc.so.2 existiert im Dateisystem

Die Lösung ist auf archlinux.org beschrieben. Einfach überschreiben:

sudo pacman -Syu --overwrite usr/lib/libutf8proc.so.2

Das wars.

Mein Gesicht im Internet

Rene
Seit Jahren achte ich darauf, dass mein Gesicht nicht im Internet zu finden ist — nicht auf Fotos jedenfalls.

Manch einer fragt sich, warum ich das tue. Ob ich mich vielleicht für wichtiger als andere halte? Nein, natürlich bin ich nicht wichtiger als andere. Es ist auch keine neue Marotte von mir oder eine Mode — ich handhabe Fotos und Videos von mir seit Jahren so.

Vielmehr befürchte ich, dass mein Gesicht missbraucht werden kann, beispielsweise bei CatFishing. Außerdem: Wenn es einmal zu einem GAU gekommen ist, ist es sehr schwer und teuer bis unmöglich, wieder Herr der Lage zu werden.

Ich habe einfach mal eine Liste zusammengestellt mit Informationen, die hoffentlich meinen Standpunkt erklären helfen:

Ich hoffe daher auf Verständnis, dass ich unter keinen Umständen mein Gesicht auf Fotos oder Videos im Internet oder Intranet sehen möchte.

How to unlock a dm-crypt-encrypted second harddisk with a static key

Let’s assume you have a device that boots from an encrypted SSD and also has a encrypted spinning disk for storage. Further let’s assume that you unlock the system disk and the spinning disk with a dedicated password each boot.

At least that’s my current situation. I have grown tired of entering two 20+ chars password each time my notebook boots so I have decided to unlock the spinning disk using a static key from the encrypted system disk. That’s certainly not the holy grail of IT security but anyway. Security and ease of use must go hand in hand in my opinion.

Also note: Do the following steps on your own risk.

Let’s go: Save the password as the static key (NOTE: do not do this if you encrypt a NEW disk or partition. Instead, generate a much more secure (ie. longer) static key as described in the Arch wiki — the following mini how-to is just for easy “retrofitting” existing encrypted disks with static key unlocking).

sudo touch /etc/luks_static_key
sudo chown root:root /etc/luks_static_key
sudo chmod 0400 /etc/luks_static_key
sudo $EDITOR /etc/luks_static_key # enter the password and save

Change the encrypted disk’s entry in /etc/crypttab like so (your line might vary a bit) from

name_of_dmcrypt_device UUID=the_uuid none luks

to
name_of_dmcrypt_device UUID=the_uuid /etc/luks_static_key

For the last step you will need to give the name of the encrypted partition. Find out what the name is using lsblk. The output might look like this:
NAME              MAJ:MIN RM SIZE    RO   TYPE  MOUNTPOINT
sda               8:0     0  931,5G  0    disk
|--sda1           8:1     0  931,5G  0    part
   |--crypt_dev 254:4     0  931,5G  0    crypt /mnt/crypt_dev

The encrypted partition in this case is /dev/sda1. Now use cryptsetup to make the static key file known:
cryptsetup luksAddKey /dev/sda1 /etc/luks_static_key # enter the password of the device

Boom. During the next boot sequence you should only be asked for the system disk password. The spinning disk will be unlocked using the static key file from the system disk.

Did this mini how-to help you in any way or do you have suggestions? Leave a comment.

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.