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/
Das Verhalten welches du im ersten Teil des Blog Artikels beschrieben hast, ist länger bekannt. Grosser Mail Provider wie Google und Yahoo betreiben schon länger eine eigene IP Reputation, welches in beide Richtungen funktioniert. Konkret bedeutet das, dass man die Historie der IP, mit der man Mails versenden möchte kennen sollte und nicht Vollgas Mails versenden sollte. Man muss jede IP langsam warm laufen lassen. Es ist auch schon länger so, dass Domains, die nicht über einen SPF Eintrag verfügen, schlechter behandelt werden.
Es ist deshalb immens wichtig, dass bevor dem in Betrieb nehmen eines Mail System DMARC/DKIM/SPF korrekt funktioniert. Anschliessend sollte man einen Teil des Mail Verkehrs über denen neuen Gateway laufen lassen und langsam migrieren. Nie aufs Mal – das geht garantiert schief.
Zum Thema SPF/DKIM/DMARC: Es ist ein Fehlannahme, dass diese Techniken Spam und Phishing verhindern. Vielmehr helfen sie, die Absender Domain zu verifiziren. Seit beispielsweise PayPal diese Techniken eingeführt hat, ist auch die Anzahl der gefakten paypal.com Mail drastisch runter gegangen.
Die Aussage, dass DKIM Probleme verursacht, wenn man den Header verändert, ist nicht korrekt. Richtig ist, dass DKIM keine Änderungen am Header erlaubt. Dementsprechend muss man vorsichtig sein, was man mit den Mails tut. Wie du es geschrieben hast, sollte man Header erst nach dem Spam Gateway modifizieren und mit Mailinglisten sollte man ebenfalls vorsichtig sein.
Die Art und Weise wie Google und Yahoo mit der Thematik umgehen, halte ich für die richtige. Mail Server, welche wenig Mails in Richtung Yahoo und Google schicken, bekommen ein gutes Rating, so lange sie keinen Spam verschicken. Microsoft hingegen verlangt, dass man pro Tag mindestens 160 saubere E-Mails von einer IP empfängt, bis man eine gute Reputation erhält. Anschliessend muss man ein gewisses Level aufrecht erhalten, damit man eine gute Reputation hat. Offensichtlich hat Microsoft hier etwas falsch verstandend und verursacht so Probleme für Organisationen, die wenig Mailverkehr mit einer von Microsoft gehosteten Domain haben.
Wie bereits in Teil eins recht drollige Argumentation:
DKIM soll eine Manipulation des Headers verhindern. Es wird sich nun im Artikel darüber beschwert, das eine Manipulation auffällt, wenn beteiligte Systeme am Header „rumpfuschen“. Wie kommt ein System wie ein vorgeschaltetes Mail Gateway oder andere beteiligten Server dazu, eMails zu verändern (zu Manipulieren) wie z.B. die betreff Zeile zu verändern?
Emails gehören unverändert zugestellt! Wenn die Links nicht zulässig sind, wird die Mail abgewiesen (und der Sender benachrichtigt) oder in den Spam Ordner einsortiert.
Die erwähnten Verfahren wie s/mime oder openPGP sind persönliche = e2e Systeme, die im Emailprogramm zu hinterlegen und zu organisieren sind. Es ist schlimm genug, das Gateways nun mit generischen Zertifikaten eine Art e2e Verschlüsselung oder Zertifizierung vorzugaukeln! Aber dieses „pfuschen“ zu verteidigen oder vorzuschlagen, geht gar nicht! Im besten fall werden derartig manipulierten Mails aussortiert. Entweder ist eine Mail e2e verschlüsselt i.O. (mein System kann beides) oder sie ist es nicht, dann hat sich die mail an offizielle Standards zu halten!
Korrekterweise nutz man dann das hierfür vorgesehene DNSSEC mit DANE und entsprechender Transportverschlüsselung oder notfalls die alternative MTA-STS. Aber es braucht wohl wieder druck von den „großen“, das sich etwas ändert. Leider…