Informatik aus Versehen

Notiz an mich selber: Wenn ich zwei Repositories mergen will, indem ich Repository A als Unterverzeichnis von Repository B einbinde, dann ist das ein recht trivialer Rewrite-Vorgang, gefolgt von einem Merge ohne gemeinsame Historie. Wenn Gerrit im Spiel ist kommt aber noch ein Commit-Filter hinzu, damit ich die Change-DB anpassen kann: Danach kann man wie gehabt mergen: Das erzeugte File mit den SQLs kann man dann in "gerrit gsql" anwenden.

In einer perfekten Welt würden nach Bekanntwerden einer Sicherheitslücke alle Server innerhalb weniger Stunden gepatched werden. Neue Verschlüsselungsalgorithmen wären nach wenigen Wochen überall verfügbar und Änderungen an unterstützender Infrastruktur wie z.B. die Implementierung von DANE wären in ein paar Monaten durch. Und dann wacht man auf und stellt fest, dass die Welt leider alles andere als perfekt ist. Und so muss ich nun leider, schweren Herzens und verschämt, eine Aussage invalidieren, die ich in diesem Blog-Eintrag getroffen habe. Damals war ich der Meinung, dass es eine gute Idee sei, auf einem Mailserver - bzw. genauer, auf einem Public MX - die Liste der Verschlüsselungsprotokolle und Ciphers einzuschränken, die unterstützt werden. Ich wähnte mich da damals auf der sicheren Seite, wenn selbst Leute wie Jacob Appelbaum Konfigurationen veröffentlichen, die genau das tun. Aber wenn man darüber nachdenkt, dann ist das eigentlich eine schlechte Idee.

Halten wir uns vor Augen, wie der Versand einer Mail in einfachsten Fall funktioniert: Ein Mailserver, der eine Mail ausliefern will, macht einen MX-Lookup auf die Zieldomain, kontaktiert einen der eingetragenen MX-Hosts und liefert dort die Mail ab. Verschlüsselung auf SMTP-Ebene wird dabei durch die STARTTLS-Erweiterung implementiert. Bietet der Ziel-MX diese Erweiterung nicht an, oder kann kein Crypto-Handshake durchgeführt werden, dann wird der einliefernde Mailserver die Mail einfach unverschlüsselt ausliefern. Seiner Natur nach ist STARTTLS also opportunistisch (man spricht oft auch von opportunistic encryption) - wenn es funktioniert, toll, wenn nicht, dann wird einfach unverschlüsselt weitergemacht. Und genau das ist das Problem: Wenn ich meinen Mailserver so konfiguriere, dass nur sehr starke, moderne, "sichere" Verschlüsselungsarten unterstützt werden, dann werden viele ältere Systeme nicht in der Lage sein, einen SSL/TLS-Handshake durchzuführen. Und dann geht die Mail vollkommen unverschlüsselt über die Leitung. Jetzt könnte man natürlich seinen MX so konfigurieren, dass er gar keine Mails mehr ohne STARTTLS annimmt - aber dann kann man es sich auch gleich sparen, überhaupt einen Mailserver zu betreiben. Und das behaupte ich nicht nur, dazu gibt es auch Zahlen: Sowohl Google aus auch Facebook (Achtung: Facebook-Account erforderlich) haben vor kurzem ihre Statistiken bzgl. STARTTLS öffentlich verfügbar gemacht.

Jetzt gibt es ja Seiten wie z.B. STARTTLS.info, und da wird man punktemäßig "abgewatscht", wenn man alte Protokolle unterstützt, schwache oder anonyme Ciphers anbietet oder Zertifikate nutzt, die nicht von einer der großen CAs unterschrieben wurden. Mittlerweile bin ich der Meinung, dass die Jungs da falsch liegen.

• Wenn ein einliefernder Mailserver ein Zertifikat nicht verifizieren kann, dann ist er anfällig(er) gegen eine MITM-Attacke. Soweit, so gut. Aber was ist die Alternative in dem Fall? Ist es wirklich besser, die Mail dann unverschlüsselt zu übertragen? Oder gar die Einlieferung komplett abzubrechen? Wohl kaum. Mailversand über einen öffentlichen MX wird immer (naja, fast, siehe unten) gegen MITM anfällig sein. Warum also sollte man die Zertifikate verifizieren? Und wenn man die Zertifikate nicht verifiziert, warum sollte man dann welche nehmen, die von einer der großen CAs unterschrieben wurden?
• Aus dem gleichen Grund ist es wenig sinnvoll, anonyme Cipher nicht zuzulassen. Wenn man sich sowieso schon nicht gegen MITM absichern kann, warum sollte man sich denn dann überhaupt die Mühe machen, die Gegenstelle dazu zu bewegen, ein Zertifikat vorzulegen?
• Ohne DNSSEC habe ich sowieso nie die Sicherheit, überhaupt mit dem richtigen MX zu sprechen und bin somit immer gegen MITM-Attacken anfällig.
• Im Zuge des SSL/TLS-Handshakes einigen sich beide Seiten auf ein Set aus Protokollen und Ciphers. Normalerweise präsentiert dabei der Server die Liste der von ihm untertstützten Verschlüsselungseinstellungen und der Client wählt dann das von ihm bevorzugte Set aus. Daraus folgt, dass moderne Software (z.B. eben Postfix) sich ohne jegliche Einstellungen auf eine starke Verschlüsselung einigen wird (meine Debian-Postfixe z.B. einigen sich immer auf ECDHE-RSA-AES256-GCM-SHA384, was wenig Wünsche offen lässt). Wenn eine "suboptimale" Wahl statt findet, dann ist es die Aufgabe des Senders, dies anzupassen - und nicht die des Empfängers. Spiele ich hier an Parametern, dann riskiere ich nur, dass die Mail im Klartext übertragen wird.
• Tansportwegverschlüsselung - und mehr ist STARTTLS nicht - ist keine End-to-End-Verschlüsselung.

Natürlich gibt es ein paar Ausnahmen, bei denen es Sinn machen kann, sich mehr Gedanken über Verschlüsselung zu machen und nicht nur zu sagen "irgendeine Verschlüsselung ist besser als gar keine". Im wesentlichen ist dies zum einen, wenn man, z.B. weil Geschäftsbeziehungen bestehen, mit den Postmastern der Gegenstelle eine Vereinbarung über die einzusetzenden Krypto-Algorithmen treffen kann. Dann kann man (in Postfix z.B. über TLS Policy Maps) die ganze Bandbreite an Möglichkeiten ausschöpfen, von der Wahl der Zertifikate über die Protokolle und Ciphers bis hin zum Unterdrücken von unverschlüsselten Übertragungen. Ähnlich sieht es aus, wenn man keinen Public MX, sondern einen Mail Submission Agent (MSA) betreibt, der von Anwendern genutzt wird, um Mails via eMail-Programm einzuliefern. Da hier feststeht, welches der "richtige" Server ist, lohnen sich "vertrauenswürdige" (was auch immer das derzeit heissen will) Zertifikate und eine Feineinstellung der Verschlüsselungs-Algorithmen. Und nicht zuletzt erledigt sich zumindest das Thema "anonyme Ciphers", wenn beide Seiten DANE (und damit DNSSEC) implementieren.

Ich habe leider keine perfekte Antwort darauf, wie wir auf SMTP bezogen Sicherheit und Privatsphäre am effektivsten schützen können - ich denke aber nicht, dass ein Tuning der TLS-Parameter auf einem öffentlichen MX uns weiter bringt. Im Gegenteil, jede Verschlüsselung ist, zumindest in meinen Augen, um ein vielfaches besser als gar nicht zu verschlüsseln. Langfristig hoffe ich, dass wir in den nächsten Jahren eine rasche und flächendeckende Unterstützung für DNSSEC und DANE sehen werden (da träume ich allerdings schon wieder) und somit sowohl das Skalierungs- als auch das CA-Problem lösen können. Und wenn es wirklich sicher sein soll hat man einfach keine andere Wahl, als bei einem Bier die PGP-Keys auszutauschen.

Falls es mal jemand braucht:

Wie gesagt, geht davon aus, dass man das SYSLOGBASE-Pattern angewandt hat, und dass alles nach dem Programm und der PID in ekckigen Klammern im Feld message_remainder zur Verfügung steht.

Bis in die letzte Konsequenz angewendet bedeutet "Infrastructure as Code", dass man in der Lage ist, die eigene Umgebung aus dem Regelwerk, Computing-Resourcen und einem Backup wieder in genau den Zustand zu überführen, den sie haben soll. Und dies soll nicht nur für die Grundkonfiguration einer Maschine gelten, sondern auch für angebotenen Dienste. Im Umkehrschluss bedeutet dies aber natürlich auch, dass man bei der Entwicklung des eigenen Puppet- oder Chef-Regelwerks eine möglichst realistische Grundlage für die Entwicklung verwenden sollte - also am besten "auf der leeren Wiese" anfangen. Die Technik im Jahr 2013 macht uns das ganze recht einfach, in dem sie uns diverse Virtualisierungstechniken abietet, mit denen wir jederzeit neue Server erzeugen und dann für die Entwicklung von Code verwenden können.

Eine Lösung, die sich hier besonders hervor tut, ist Vagrant. Dieses Tool spielt für uns das Frontend zu diversen Virtualisierungstechniken, u.a. VirtualBox, vMware und LXC. Was es so gut macht ist seine Fähigkeit, den Code-Gedanken einen Schritt weiter zu führen als andere Lösungen das tun: Bei Vagrant ist bereits die Erstellung von neuen virtuellen Maschinen programmatisch gelöst, inklusive deren Konfiguration mit Portforwarding, initialem Provisioning mittels Puppet oder Chef sowie der Fähigkeit, Dateien zwischen der VM und dem Gastsystem auszutauschen. Damit das ganze funktioniert, benötigt man mindestes zwei Dinge:

1. Das Vagrantfile. Dieses beschreibt, wie die virtuellen Maschinen aussehen sollen, also z.B. die Anzahl und Art der Netzwerkkarten, den Typ der verwendeten CM-Software etc.
2. Ein Image der zu verwendenen virtuellen Maschine(n).

Diese Abbilder der Maschinen werden auch als base boxes bezeichnet. Ihr Erstellung ist ausführlich dokumentiert, kann allerdings ein recht zeitaufwändiger Prozess sein. Doch auch hierfür gibt es eine automatisierte Lösung, nämlich Veewee. Dieses Tool ist in der Lage, für diverse Virtualisierungs-Provider automatisiert Images zu erstellen, welche dann z.B. eben auch mit Vagrant weiter verwendet werden können. Unter Debian verfügt man, wenn man mehr oder weniger bei der derzeit stabilen Distribution "wheezy" bleiben will, zwar leider nicht über die neueste Version von Vagrant und auch nicht über eine bereits paketierte Version von Veewee, allerdings sind dies IMHO keine allzu großen Einschränkungen: Die mitgelieferte Vagrant-Version funktioniert mit der ebenfalls mitgelieferten Version von VirtualBox einwandfrei, und wer die "Verunreinigung" des eigenen Systems mit Ruby-Gems etc. im Laufe der Installation von Veewee fürchtet, der kann es so halten wie ich und für die Installation z.B. mittels debootstrap eine chroot-Umgebung aufbauen.

Die Installation von Veewee ist relativ einfach:

apt-get install ruby ruby-dev build-essential libxslt1-dev libxml2-dev libzip-ruby1.9.1 zlib1g-dev
gem install fog
gem install veewee

Dummerweise liefert einem das nicht die aktuellste Version von Veewee (da sind die wheezy-Dependencies einfach schon zu alt), was aber kein wirklicher Beinbruch ist, denn alles was wir benötigen, sind aktualisierte Maschinen-Definitionen, und für die reicht es aus, sich Upstream zu klonen und alle Veewee-Aufrufe aus diesem Verzeichnis heraus auszuführen:

git clone https://github.com/jedi4ever/veewee
cd veewee

Nun kann man sich, vollkommen automatisiert, z.B. Images für das jeweils aktuellste CentOS 6 sowie Debian/wheezy bauen lassen und diese danach in eine Vagrant-Base-Box überführen:

veewee vbox define 'wheezy64' 'Debian-7.1.0-amd64-netboot'
veewee vbox build 'wheezy64'
veewee vbox halt wheezy64
vagrant package --base wheezy64 --output wheezy64.box

veewee vbox define 'centos6-64' 'CentOS-6.4-x86_64-minimal'
veewee vbox build 'centos6-64'
veewee vbox halt centos6-64
vagrant package --base centos6-64 --output centos6-64.box

Danach liegen die ".box"-Dateien im veewee-Verzeichnis. Eine Liste der verfügbaren Definitionen erhält man mit dem Kommando veewee vbox templates (und hier sieht man dann auch einen Unterschied, je nachdem, ob man im geklonten Upstream-Verzeichnis ist oder nicht). Der Zusatz "minimal" bzw. "netinstall/netboot" bezieht sich auf das verwendete Installations-Image. Wer sich das ganze übrigens nicht selber antun will findet Boxen, aktuell von heute, für CentOS und wheezy hier.

Ich verabschiede mich zu den Klängen von Liszt, "Rhapsodie über ein Thema von Paganini", Op. 43. Euch ein schönes Wochenende

In meinem $DAYJOB bauen wir derzeit ein zweites Rechenzentrum fertig. Es wäre ganz schön gewesen, wenn man das als Spielwiese für Konzepte hätte benutzen können, aber leider hat das mit der Zeitplanung nicht so ganz hingehauen, weswegen es dann doch eher ein ziemlicher Kraftakt wurde. Das ist recht schade, denn da gibt es ein paar Fragestellungen, die zu lösen recht interessant ist. Wenn man z.B. bisher NFS-Server im Einsatz hat und "auf die Schnelle" nicht die Möglichkeit besteht, die gegen z.B. GlusterFS zu tauschen, dann stellt sie die Frage, wie man im Fall, dass man ein RZ verliert, möglichst problemlos in das andere RZ failovern kann. Je nach Anforderung kann es da sogar noch Bonuspunkte geben, wenn man den Failover automatisiert, aber dabei auf Datenintegrität achtet (es muß aber keine Bonuspunkte geben - jede Firma muß selber wissen, ob ihr der automatische Failover die zusätzliche Technologieschicht z.B. in Form einer Clusterware mit Quorum-Knoten wert ist). Oder auch das Thema DNS - mit den Serverfarmen auf welchem Loadbalancer sollen denn Clients eigentlich sprechen? Und gibt es die Möglichkeit, hier überhaupt Routing-Entscheidungen einfliessen zu lassen? Oder ist das ein typischer Fall für Anycast? Interessante Themen, aber heute soll es um etwas deutlich bodenständigeres gehen, nämlich um Puppet.

Wenn man mehr als einen Puppetmaster haben will, dann tut man das meistens entweder, weil man ein Performance-Problem hat oder weil man eine gewisse Ausfallsicherheit haben will. In unserem Fall war es die Ausfallsicherheit, und zwar besonders im Katastrophenfall. Das zu wissen ist schon mal eine große Hilfe: In unserem Setup geht nicht sofort die Welt unter, wenn ein Puppet-Agent mal nicht mit seinem Master reden kann. Der Agent wird in dem Fall einfach die letzte Katalog-Version aus dem Cache holen und diese, soweit ihm das möglich ist, anwenden. Das gilt, obwohl wir viel mit exportierten Ressourcen arbeiten, denn auch auf Hosts, die besagte Ressourcen einsammeln, stehen diese stets in der jeweils letzten Katalog-Version zur Verfügung. Wären unsere Puppetmaster also nicht verfügbar, so würde dies lediglich unsere Fähigkeit beeinflussen, im Katastrophenfall Änderungen am System durchzuführen. Unser Setup legt also Wert darauf, dass wir im Rahmen des BCM-Prozesses leicht wieder die Fähigkeit gewinnen können, unsere Umgebung zentral zu verwalten, hat aber nicht den Anspruch, vollautomatisch zu sein. Für diesen Preis, den zu zahlen wir bereit sind, erhalten wir ein relativ simples Setup, dass man auch einem Azubi gut näher bringen kann, und das trotzdem die Verteilung der eigentlichen Last - das Kompilieren von Katalogen nämlich - auf mehrere Server erlaubt.

Nachdem ich ja leider den alten Blog-Servern mitsamt Backups verloren hatte habe ich mir mal Gedanken drüber gemacht, ob ich nicht doch noch irgendwie an die meisten alten Blog-Einträge ran komme. Stellt sich raus, dass die RSS-Feeds, die die Blog-Software produziert, alle auf web.archive.org verfügbar waren und dass besagte Blog-Software auch in der Lage ist, die wieder zu importieren. Das macht zwar viele Links kaputt, Formatierungen teilweise auch und natürlich fehlen fast alle alten Bilder, aber besser als nichts. Allerdings gab es da ein kleines Problem: Die RSS-Snapshots sind von verschiedenen Daten, und natürlich überschneiden die sich etwas. Sprich, hätte ich die einfach alle so importiert, dann hätte ich mich danach ein paar Stunden lang durch doppelte Einträge klicken dürfen, und das war mir zu doof. Zum Glück war ich mir ziemlich sicher, dass alle alten Blog-Einträge eindeutige Titel hatten. Also eine recht triviale Lösung: Ich parse alle alten Feeds, berechne aus dem Titel eines Eintrags einen Hash, kopiere den Eintrag unter dem Hash-Namen in ein Verzeichnis (wenn dann der selbe Eintrag ein zweites Mal kommt wird das bestehende File überschrieben) und wenn ich für alle Feeds durch bin, baue ich die Einträge in ein einzelnes RSS-File ein.

Als ich jetzt schon awk, grep etc. auspacken wollte, ist mir zum Glück eingefallen, dass es ja eine nette kleine Software mit Namen XMLStarlet gibt. Und mit der geht das relativ trivial:

Die Leute, die mein Blog hauptsächlich via RSS-Feed lesen, haben jetzt übrigens ein Problem: Die alten Einträge tauchen jetzt in der Feed-Übersicht ganz vorne auf. Tut mir leid. Ehrlich!

Ich habe mir jetzt doch mal einen Account bei StartSSL zusammen geklickt und mir da zwei Zertifikate für die Domains geholt, unter denen das Blog verfügbar ist. Nachdem ich nur eine IPv4-Adresse habe, hinter der ich das hosten kann (also ich hätte schon noch eine über, aber wer weiß, wofür ich die noch brauchen werde), funktioniert das ganze zwar völlig normal wenn man die Seite als www.incertum.net (oder als incertum.net, die StartSSL-Zertifikate haben immer einen Subject Alternative Name drin) aufruft - aber falls man sie als (www.)stefan-foerster.de ansprechen will, muß die Kombination aus Browser und Betriebssystem die Erweiterung Server Name Indication (SNI) unterstützen. Und damit ist dann Windows XP nativ raus, die dort vorhandene Version von Secure Channel kann einfach kein SNI. Alternative Browser wie z.B. Chrome sollten aber trotzdem funktionieren.

Im IPv6-Land ist das ganze übrigens kein großes Problem: Nachdem man hier IPs im Überfluss hat ist es kein Thema, für die SSL-Hosts, die verschiedene Zertifikate vorweisen sollen, auch jeweils eigene IPv6-Adressen zu verwenden, was ich so auch umgesetzt habe. Sprich, wenn jemand mit einem Windows XP und Internet Explorer IPv6 hat, dann sollte das sogar funktionieren. Um die Konfiguration halbwegs übersichtlich zu halten, habe ich sie soweit wie möglich modularisiert:

• Der Standard-HTTP-Host tut nichts weiter, als eine permanente Umleitung auf die HTTPS-Seite weiterzugeben. Dabei wird die Variable $host und nicht $server_name benutzt, weil letzere bei mehr als einem Servernamen in der Konfiguration immer auf den ersten Wert matched, nicht aber auf den, den der Browser aufgerufen hat. Beginnt die Konfiguration z.B. mit server_name www.incertum.net www.stefan-foerster.de ...;, dann würde eine Umleitung immer auf www.incertum.net landen. Das ist dann z.B. bei Safari-Browsern problematisch, wenn die nämlich einen Cookie von einer Domain haben, dann lassen sie sich nicht einfach so auf HTTPS umleiten.
• Die Teile der SSL-Konfiguration, die pro Server gleich sind, habe ich in eine eigene Datei ausgelagert. Das ist im wesentlichen alles ausser dem Server-Namen, den Zertifikaten und den IPs. Mit der Direktive listen ... ssl default_server; legt man übrigens fest, welcher SSL-Host derjenige sein soll, der sein Zertifikat herzeigt, wenn der Browser kein SNI kann. Wie man weiterhin sieht, sind beide IPv6-SSL-Hosts jeweils als default_server markiert.
• Die IPv6-Adressen sind keine Wildcard-Adressen, also benötigt man kein ipv6only=on.
• Ebenso ist die eigentliche S9Y-Konfiguration für das Blog in ein eigenes File gewandert.
• Die zusätzliche IPv6-Adresse wird ganz normal über die up/down-Direktiven in /etc/network/interfaces konfiguriert (und wie man sieht kommt die Hauptadresse via SLAAC)

Das ganze sieht dann so aus:

Selbstverständlich habe ich die entsprechenden TLSA-Records bereits im DNS hinterlegt. Lasst mich doch bitte wissen, falls ihr nach dieser Änderung Probleme beim Zugriff auf die Seite haben solltet, dann kann ich da gerne entsprechend nachfixen.

Wenn man GNU mailman auf Debian/wheezy einsetzen will, dann installiert das Debian-Paket netterweise unter /etc/mailman/apache.conf ein Konfigurationsfile für den Apache, das einem die Aliasse so hinbiegt, dass sie auf Anhieb funktionieren. Gleichzeitig tut man sich mit dem Indianer recht leicht, cgi-bin's auszuführen - das kann er nämlich von Haus aus. Mit nginx hat man hier leider etwas verloren, kann der doch weder cgi-bin von sich aus noch gibt es eine vorbereitet Konfiguration. Also schauen wir uns mal an, wie man das relevante Subset an Funktionalität mit nginx & Co. nachbauen kann.

Relativ einfach ist der cgi-bin-Teil. Debian stellt hier das Paket fcgiwrap bereit, welches man einfach installiert und startet. Das Ding ist bereits so vorkonfiguriert, dass es uns alle CGIs aus /usr/lib/cgi-bin ausführt und von nginx normal via FastCGI angesprochen werden kann. Das war der einfach Teil.

Die nginx-Konfiguration ist etwas komplizierter, man muss sich da nämlich mit der Variable fastcgi_split_path_info auseinandersetzen. Dabei handelt es sich um eine RegExp, in der wir zwei Teile gruppieren müssen. Der erste Teil soll dabei der Pfad zu dem eigentlichen CGI-Skript sein, der zweite Teil der zum Pfad. Oder anders gesagt, wenn wir die den Request /mailman/admin/listname/nondigest haben, dann muss die RegExp daraus den Skriptnamen mailman/admin machen und die Pfadinfo sollte /listname/nondigest sein - man beachte hier die Slashes, der Skriptname darf am Ende keinen, die Pfadinfo muss am Ende einen haben. Das ganze sieht dann ungeführ so aus:

Ein paar Anmerkungen dazu:

• Zeilen vier und fünf sehen so aus, wenn es sich nicht um den Default-vHost auf dem Server handelt, deswegen kein default_server und kein ipv6only dahinter.
• Zeile 19 macht genau den Split, den ich oben erwähnt habe.
• Zeilen 21-24 sind ein bisserl speziell: Die mitgelieferte Datei /etc/nginx/fastcgi_params definiert den Parameter SCRIPT_FILENAME in für uns unbrauchbarer Form, deswegen habe ich da den "dreckigen" Weg gewählt und das einfach auskommentiert, weswegen ich es in Zeile 23 so setzen kann, wie ich will. Das bedeutet natürlich auch, dass man auf anderen vHosts auf dem selben Server immer eine Zeile extra braucht - wägt selber ab, was für Euch am wenigsten Aufwand ist.
• Zeile 23 sorgt dann dafür, dass ein Request wie /mailman/listinfo/listname an das Skript /usr/lib/cgi-bin/mailman/listinfo weitergeleitet wird - via fcgiwrap natürlich.
• Zeile 24 gibt bei einem Request wie /mailman/listinfo/listname den Parameter /listname mit an das CGI-Skript weiter.

Insgesamt ist fcgiwrap wirklich sehr praktisch, das hat mir den Umstieg auf nginx bei einigen Dingen, z.B. auch awstats, deutlich erleichtert.

Zuletzt muss man sagen, dass die obige Konfiguration nicht perfekt ist: So habe ich zum einen auf die Rewrites verzichtet, die z.B. /admin nach /mailman/admin überführen, und zum anderen habe ich nie getestet, ob öffentliche Archive funktionieren. Wäre toll, wenn das mal jemand testen könnte und mir dann Bescheid sagt.

Ich dachte mir, sicher ist sicher, paste ich es hier also auch nochmal rein:

Hi,

you are receiving this e-mail because you once signed my OpenPGP key
BBE2A9E9.  For a number of reasons, I’ve recently set up a new OpenPGP
key, and will be transitioning away from my old one.

The old key will continue to be valid for some time, but i prefer all
future correspondence to come to the new one.  I would also like this
new key to be re-integrated into the web of trust.  This message is
signed by both keys to certify the transition. If you are using the
"mutt" MTA, you might have to add this line to your ~/.muttrc to have
mutt automatically verify traditional style PGP messages:

#v+
message-hook '!(~g|~G) ~b"-----BEGIN\ PGP\ (SIGNED\ )?MESSAGE"' \
 "exec check-traditional-pgp"
#v-

The old key was:

pub   1024D/BBE2A9E9 2000-10-30
      Key fingerprint = 100F D755 B723 B7A1 3E45  3E0E 9345 02E3 BBE2 A9E9

And the new key is:

pub   4096R/4BAE9B24 2013-09-17
      Key fingerprint = DE92 4D5A 4080 1811 3B95  D9F8 491F ED2C 4BAE 9B24

To fetch the full key, you can get it with:

  wget -q -O- https://mail.incertum.net/4bae9b24.pub.asc | gpg --import -

You can, alternatively, fetch my public key via HTTP:

  wget -q -O- http://mail.incertum.net/4bae9b25.pub.asc | gpg --import -

Or, to fetch my new key from a public key server, you can simply do:

  gpg --keyserver pgp.mit.edu --recv-key 4BAE9B24

The keys are published in DNS as well, as described in
http://www.gushi.org/make-dns-cert/HOWTO.html. If you are using a
recent version of GnuPG, you may add

  auto-key-locate cert pka

to your ~/.gnupg/options to automatically retrieve the key via DNS.

Please note that all DNS data for the "incertum.net" zone is DNSSEC
signed. Furthermore, you can verify the webservers certificate using
DANE TLSA records.

If you already know my old key, you can now verify that the new key is
signed by the old one:

  gpg --check-sigs 4BAE9B24

If you don’t already know my old key, or you just want to be double
extra paranoid, you can check the fingerprint against the one above:

  gpg --fingerprint 4BAE9B24

If you are satisfied that you’ve got the right key, and the UIDs match
what you expect, I’d appreciate it if you would sign my key:

  gpg --sign-key 4BAE9B24
Lastly, if you could upload these signatures, I would appreciate it.
You can either send me an e-mail with the new signatures (if you have
a functional MTA on your system):

  gpg --armor --export 4BAE9B24 | mail -s "OpenPGP Signatures" cite@incertum.net

Or you can just upload the signatures to a public keyserver directly:

  gpg --keyserver pgp.mit.edu --send-key 4BAE9B24

Please DO NOT upload my key to *.pgp.com. pgp.mit.edu and
subkeys.pgp.net are sane choices.

Please let me know if there is any trouble, and sorry for the
inconvenience.

Regards,

        Stefan

[This e-mail is is based on dkg’s template at
http://fifthhorseman.net/key-transition-2007-06-15.txt, thanks for that.]

Man sieht sehr schön, wie die verschiedenen Crypto-Geschichten da ineinander greifen: Via DNSSEC ist zum einen der CERT-RR direkt abgesichert, was einen automatischen Download des Keys ermöglicht. Wer den Key lieber per Hand und über SSL vom Webserver zieht, der kann via DANE TLSA verifizieren, dass das Zertifikat das erwartete ist. Und wer dem alten Key traut, sieht dessen Unterschrift nicht nur unter der Mail, sondern auch auf dem neuen Key.

Was könnte man eigentlich noch machen, wenn man dem eigenen DNS etwas mehr Sicherheit verpasst hat? Na ja, eine Idee wäre z.B., im DNS bestimmte Aussagen über den sonstigen Einsatz von Kryptographe zu treffen. Dabei gibt es zwei Dinge, die mir sinnvoll erscheinen: Zum einen SSHFP-Records, mit denen man den Host-Key eines SSH-Servers im DNS verewigen kann, und zum anderen DANE TLSA, mit dem man selbiges etwas universeller tun kann.

Warum sollte man sich die Mühe machen? Nun, viele gemeinhin eingesetzte Protokolle unterstützen von Haus aus zwar SSL/TLS, arbeiten aber oft recht opportunistisch: Ohne weitere Konfiguration z.B. ist es bei Mailservern durchaus üblich, dass diese Nachrichten zustellen, egal, ob der Zielserver überhaupt die STARTTLS-Erweiterung anbietet. Und selbst wenn die STARTTLS-Erweiterung angeboten wird ist es unüblich, das präsentierte Zertifikat zu verifizieren - weder darauf, ob der Hostname stimmt noch ob das Zertifikat von einer vertrauenswürdigen (was auch immer das in diesen Zeiten bedeuten mag) Stelle unterzeichnet wurde. Und selbst wenn man das alles prüft: Wir haben erlebt, wie CAs in der Vergangenheit missbraucht wurden. Man kann zwar soweit gehen und die Fingerprints bestimmter Gegenstellen lokal pflegen, aber das skaliert nicht wirklich. Hier springt nun DNSSEC ein: Mit DNSSEC ist es so gut wie unmöglich, DNS-Records zu fälschen, da es, von der root-Zone abwärts, eine vertrauenswürdige Kette von Signaturen gibt, die man leicht verifizieren kann. Was liegt also näher, als besagte Fingerprints im DNS zu veröffentlichen?

Für das SSH-Protokoll wird dies durch den Einsatz der genannten SSHFP-Records erledigt. Beispiel:

Wichtig ist hier, dass die Daten auch wirklich via DNSSEC verifiziert wurden - in meinem Query habe ich das durch den Schalter +ad erzwungen. Verbindet man sich nun mit entsprechenden Parametern auf den Server, so sieht man, dass eine DNS-Abfrage gestellt wurde (und sofern man einen verifizierenden Resolver verwendet, kann man sich auch darauf verlassen):

Die ausschlaggebende Zeile hier ist Matching host key fingerprint found in DNS.. Die DANE TLSA-Records ermöglichen ein vom Effekt her identisches Vorgehen für beliebige Dienste, da sie vom Aufbau her einer ähnlichen Syntax wie SRV-Records folgen. So habe ich z.B. auf meinem Server mail.incertum.net ein Zertifikat, welches ich sowohl für die Webmail-Oberfläche als auch für den Mailempfang nutze. Die dazugehörigen TLSA-RRs sehen wie folgt aus:

Auch hier ist wieder darauf zu achten, dass authentifizierte Daten benutzt werden. Und natürlich kann man sich überlegen, auch TLSA-RRs für den MSA-Port 587, für IMAP etc. zu deployen. Die Unterstützung für TLSA-RRs ist derzeit noch recht rudimentär, es gibt bisher ein Firefox-Plugin sowie etwas Code, um einfach TLSA/SSHFP-RRs zu erzeugen. Die aktuellen Snapshots von Postfix und Exim bieten jedoch bereits Unterstützung für DANE TLSA MX-RRs. Trotzdem: Lieber zuviel Crypto als zu wenig!