Inhaltliche Aufbereitung

Eigentlich wäre das Signieren ganz einfach: Aus einem Hash-Wert des Inhalts ließe sich mit Hilfe des privaten Schlüssels direkt die Signatur berechnen. Der Hash kommt ins Spiel, damit sich am Ende ein Integer-Wert fester Größe (256 Bit) ergibt. Gute Hash-Algorithmen sind nicht trivial. Sie haben eine Reihe bemerkenswerter Eigenschaften. Die Eigenschaft, die hier von Interesse ist, besteht darin, dass sich ein komplett anderer Wert ergibt, wenn sich nur ein einziges Bit des Inhalts ändert.

Mit solchen Hash-Werten ist sicher jeder schon in Berührung gekommen: RPM-Pakete beispielsweise bringen in der Regel eine MD5Prüfsumme mit, damit der Systemadministrator überprüfen kann, dass nicht der Übertragungsprozess oder ein böswilliger Dritter den Inhalt verändert hat.

Die kleinsten Änderungen zu entdecken, ist eine grundlegende Fähigkeit des Hash. Genau dieses gestaltet sich aus der Perspektive von DKIM aber als grundlegendes Problem, denn seit wenigstens 25 Jahren ändern E-Mail-Programme aller Art die Mails beim Durchlaufen ihres Systems. Am häufigsten passiert das bei Mail Transfer Agents (MTAs), aber auch Mail Delivery Agents (MDAs) sind nicht unschuldig. Für das Signieren der Mail ergibt sich daraus ein großes Problem: Die Änderungen mögen unbedeutend erscheinen, aber sie führen zu einem völlig neuen Hash-Wert.

Ein einfaches Beispiel: Nach den Vorgaben des RFC 2821 (SMTP) sollte ein MTA keine Mail weiterleiten, die Zeilen mit mehr als 998 Bytes Text enthält. Manche MTAs fügen nun einfach Umbrüche ein, wenn sie auf eine solche Zeile stoßen. Der Regel ist damit genüge getan, und für einen menschlichen Leser stellt die Zeilenschaltung kein Problem dar, trotzdem ergibt sich aber ein anderer Hash und also auch eine ganz andere Signatur.

Es gibt zahlreiche weitere Beispiele für solche „harmlosen“ Korrekturen. Manche MTAs entfernen etwa überflüssige Leerzeichen aus Kopfzeilen, andere bestehen auf korrekter Großschreibung und verwandeln selbstständig »fROM:« in »From:«, wieder andere gehen noch extremer vor und konvertieren sogar das Datum in ein Format, das ihnen genehm ist. Und natürlich hängt jeder MTA neue Received-Zeilen an. Die Herausforderung für DKIM besteht nun darin, diese häufigen Änderungen auf dem Übertragungsweg und das Prinzip der Hash-Berechnung unter einen Hut zu bringen. Die Lösung hat einen Namen: Kanonikalisierung (Canonicalization).

Kanonikalisierung

Unter Kanonikalisierung ist ein Prozess zu verstehen, der die E-Mail in ein Format überführt, das die Änderungen wieder beseitigt, die verschiedene Zwischenschritte auf dem Übertragungsweg hinzugefügt haben. Die Umwandlung dient dem alleinigen Zweck, anschließend einen eindeutigen Hash-Wert berechnen zu können – der Inhalt der Mail bleibt natürlich unberührt. In der Sprache der Unix-Welt könnte man den Prozess schematisch so notieren:

$ cat email | canonicalize | md5 > hash

Gerade war schon von überflüssigen Leerzeichen, Zeilenschaltungen oder Großschreibung die Rede. Deshalb benutzt die Kanonikalisierung die Strategie, alle Leerzeichen und Newlines zu entfernen und prinzipiell alles klein zu schreiben. Dadurch verwandeln sich »To: Fred Blogs\n« und »to: fredblogs« oder »to:\n\ n\n\nredblogs\n\n« und so weiter in dieselbe Schreibweise.

Wäre die Eignung für das Signieren der einzige Maßstab, dann sollte die Kanonikalisierung sehr rigoros vorgehen. Aus dem Blickwinkel der Sicherheit allerdings ist zu verlangen, das der Prozess eher konservativ und bedachtsam Änderungen nur dann zurücknimmt, wenn sich daraus keine Sicherheitslücken ergeben. Die Balance zwischen diesen beiden Forderungen zu finden, das beanspruchte einen großen Teil der Zeit der IETF-Arbeitsgruppe und führte schließlich zu einer guten, aber einigermaßen komplexen Lösung.

Die Arbeitsgruppe konnte dabei auf viele Erfahrungen zurückgreifen, die vorher mit dem DKIM-Vorgänger DomainKeys [6] gesammelt wurden. Daher wusste man bereits, dass auf dem Übertragungsweg Änderungen am Body der E-Mail selten sind, während die Header in viel stärkerem Maß den Launen der MTAs ausgeliefert sind. So richtet sich der Normalisierungsprozess jetzt an drei Zielen aus: Änderungen am Body, Header-Änderungen und HeaderNeuordnung.

Für jedes Ziel lässt sich justieren, wie rigoros zu kanonikalisieren ist. Abbildung 5 zeigt ein Beispiel mit dem Parameter »c=relaxed/simple«. Die Option »relaxed« bezieht sich darauf, wie die Header zu behandeln sind, bevor sie in den Hash eingehen. Hier geht es vorrangig um Whitespace und Zeilenumbrüche. Dagegen meint »simple« die Art der Vorbereitung des Body, bei der es vor allem um Leerzeilen und Terminal-Whitespace geht. Dasselbe Beispiel enthält außerdem den Parameter »h=Content-Type …«, der bestimmt, welche Header-Zeilen in welcher Reihenfolge zu verarbeiten sind.

Abbildung 5: Weitere Header-Felder verraten dem Empfänger, wie die Mail vozubehandeln ist, ehe er daraus den Hash berechnen kann. Dieser Schritt nennt sich Kanonikalisierung.

Bei all dem achtete die DKIM-Arbeitsgruppe sehr auf gute Erweiter- und Konfigurierbarkeit. Diese sollen es möglich machen, dass sich ein Anwender heute dafür entscheiden kann, eine vielleicht etwas weniger sichere, dafür aber zuverlässig funktionierende Einstellung zu wählen. Später, wenn sich DKIM auf breiter Front durchgesetzt hat und die MTAs deswegen womöglich zurückhaltender bei ihren Eingriffen sind, soll der Benutzer eine striktere Einstellung wählen können, die mehr Sicherheit bietet, dann aber genauso gut funktioniert – ohne dass die DKIM-Arbeitsgruppe erneut zusammentreten müsste.

Ähnliche Artikel

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023