Nachdem ich im ersten Teil erläutert habe, warum SPF nicht gegen Spam hilft und auch nur sehr beschränkt gegen Phishing/Spoofing, wollen wir uns heute mit dem zweiten Mail-Authentisierungs-Verfahren «DKIM» beschäftigen.

DKIM

  • Ziel: Anbringung eines sicheren Identifiers an ein Mail
    • Die Definition in RFC 6376 sagt im Detail „DomainKeys Identified Mail (DKIM) permits a person, role, or organization that owns the signing domain to claim some responsibility for a message by associating the domain with the message.“
  • Wie:
    • DKIM signiert die Mailheader und z.T. den Body mit einem Public-Key Verschlüsselungsverfahren. (Die Signatur das Mailheaders ist also vollständig unabhängig vom Envelope Sender (vgl. SPF))
    • Der im DKIM Header referenzierte Key ist in einem DNS TXT Record publiziert
    • Der DNS Eintrag erfolgt mit einem „Selector“ unterhalb der Domain _domainkey.example.com
  • Der empfangende Mailserver überprüft die Signatur

Eine gültige DKIM Signatur bindet also die Identität des Signierenden an ein Mail. Die Mail ist somit erwiesenermassen von dem entsprechenden Mailserver verarbeitet worden. Der Empfänger kann dann auf Grund dieser Identität diesem Mailserver eine Reputation zuweisen. Die DKIM Signatur aber sagt nichts über die Richtigkeit z.B. des From aus. Sondern nur, dass der Header seit der Signierung nicht verändert wurde. Es gibt primär keinen Zusammenhang zwischen (angeblichem) Absender und dem verwendeten DKIM-Key.

DKIM sagt auch nichts darüber aus, was mit gültigen oder ungültigen Signaturen geschehen soll.

Beispiel

DKIM Signatur, wie sie im Mailheader auftaucht:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=avantec.ch; i=@avantec.ch; l=17120; q=dns/txt;
s=avantec2019; t=1555600856; x=1587136856;
h=from:to:subject:date:message-id:mime-version; bh=7K3R3KnWOs0IXCuvxW4Im0Av7Q+TMW6wehxbAAaG4vM=; b=EEo5LOKLfSuVMkoAyjKgQOeSyA8v6eF5R2qvsJ2NxW8i9qNV9GpmoZNWu13CmlLq8dl5LpFYVf6Iw9CgWrzBdPKnM/ tOypeov9WFjlB2vAYlqt7uLK+zLbFcLNAn2S9pR/d6eQakCjomJhEbz7jppLS30q+V4EoUAeMDtHhMJ0=;

Im Wesentlichen bedeutet dies, dass die Domain «avantec.ch» mit dem im DNS unter dem Selektor «avantec2019» publizierten Key das Mail und die Header «from», «to», «subject» usw. signiert hat. Die eigentliche Signatur lautet «EEo5LOK…». Falls die Signatur beim Überprüfenden stimmt, so ist erwiesen, dass das Mail über ein Mailsystem gelaufen ist, welches den entsprechenden private Key kennt, also zur DNS Domain «avantec.ch» gehört. Dies hat aber a priori nichts mit der Maildomain im From Header des Mails zu tun.

 

Abfrage des DKIM Keys im DNS:

dig avantec2019._domainkey.avantec.ch TXT +short
„v=DKIM1; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCgDtUlAoLt9O61tEw0y+nX0+mHeYoVzz0Ejh4HThTDQIqXiPw2deIM8KA/lvtb/ OCKMB57A/EZNmE2dGAjqgyGGxluRpKFvxJrnmNgnqLVwZ/6VfBFEC+92tZ7gKy1UldtQfbYX2K1M5l25EBMi3Jmb76BLhfdk7z21VRxtkJBnwIDAQAB;“

Probleme

  • Wenn ein System, z.B. eine Mailinglist, einen Footer einfügt, so stimmt die Signatur nicht mehr (Abhilfe: l-Flag und nicht die ganze Mail signieren)
  • Wenn ein System ein Tag ins Subject einfügt (z.B. [mail suspicious]), so stimmt die Signatur nicht mehr (Abhilfe: Eingehende Mails auf dem äussersten Gateway überprüfen und nur intern verändern)
  • Wenn ein Mailverschlüsselungsgateway die Mail z.B. durch eine S/MIME Signatur verändert, so stimmt die DKIM Signatur nicht mehr (Abhilfe: Ausgehende Mails auf dem äussersten Gateway DKIM signieren)
  • Wenn eine Mailinglist den Sender oder Reply-To Header anpasst, so stimmt die Signatur nicht mehr (Abhilfe: keine. Lösungsansätze: eigene DKIM Signatur durch Mailinglist erstellen lassen, den zukünftigen Standard ARC verwenden)

Zusammenfassung

  • DKIM hilft nicht gegen Spoofing und Phishing, denn die DKIM Domain (wer die Mail signiert) hat nichts mit dem angeblichen Absender zu tun (der Domain im From Header).
  • DKIM kann indirekt gegen Spam helfen, denn der DKIM Identität kann eine Reputation zugewiesen werden (Überlegung: „Wenn diese Identität in der Vergangenheit nie Spam verschickt hat, so wird sie es potentiell in Zukunft auch nicht tun“).
  • DKIM macht Probleme mit Systemen, welche Mails verändern (z.B. Subject oder Sender anpassen, Footer einfügen oder Links verändern/entfernen).

Im ersten Teil dieser Blog-Artikel Serie haben wir SPF kennengelernt: Dieses Verfahren «schützt» den Envelope Sender, nützt aber weder gegen Phishing, Spoofing noch gegen Spam. In diesem zweiten Teil haben wir gesehen, dass DKIM eine Identität an ein Mail bindet. Dies sagt aber nichts über den Absender eines Mails aus, hilft somit ebenfalls nicht gegen Spoofing. Beide Verfahren SPF und DKIM sind sogenannte Mail Authentication Protokolle: Gewisse Identitäten werden überprüft. Nur leider keine, welche irgendwie relevant wären, um die Absenderadresse eines Mails zu identifizieren. Die einzige verbreitete Methode, um den Absender eines Mails zuverlässig zu Authentifizieren sind Email-Signaturen mittels S/MIME oder OpenPGP. Die anderen erwähnten Protokolle lösen Probleme, welche in der Praxis nicht relevant sind.

Im nächsten, dritten Teil dieser Serie werden wir untersuchen, was es mit dem Protokoll «DMARC» auf sich hat und ob diese Kombination von SPF und DKIM die Mängel der letztgenannten beheben kann. (Dass die Antwort negativ ausfallen wird, wird wohl nach obigen Zeilen niemanden erstaunen).

Links:

Internet Protocol Standard 67: www.rfc-editor.org/std/std76.txt (RFC 6376)

Alles über E-Mail Security: www.avantec.ch/themen/e-mail-security/

SPF/DKIM/DMARC oder warum Google meine Mails nicht mag, Teil 1: www.tec-bite.ch/warum-mag-google-meine-mails-nicht/

SPF/DKIM/DMARC oder warum Google meine Mails nicht mag, Teil 3: www.tec-bite.ch/warum-mag-google-meine-mails-nicht-teil-3/


blenny

blenny

blenny ist Senior Security Engineer und langjähriger AVANTEC-Mitarbeiter. Er interessiert sich für Kryptographie, Privacy, Datenschutz, offene Protokolle und beschäftigt sich am liebsten mit den technischen Aspekten der IT- und Informations-Sicherheit.

Privacy Preference Center