Sicherer E-Mail Transport

E-Mail

Die E-Mail ist eine der ersten Anwendungen des Internets und erfreut sich auch heute noch einer sehr großen Verbreitung. Mit der Verbreitung des Internets und der damit einhergehenden intensiveren Nutzung der E-Mail ist diese auch immer mehr zum Angriffsziel geworden. Gefahren denen heute begegnet werden muss sind Spam, Fishing, Spoofing, etc, aber auch DNS Cache Poisoning und Angriffe auf die Transportverschlüsselung.

Im folgenden wird der Aufbau einer E-Mail, das Transportprotokoll SMTP und die Kommunikation beim E-Mail Versand betrachtet. Anschließend werden Sicherheitstechniken vorgestellt, die Lösungen gegen einzelne Gefahren bieten. Der Fokus liegt hierbei auf der Server <-> Server Kommunikation.

Aufbau

Die E-Mail besteht aus einem Header und einem Body.

Header

Im Header der E-Mail befinden sich allerlei Informationen die üblicherweise von Client Software ausgeblendet werden. Dies sind z.B. Informationen zur erfolgten Spam Prüfung, Anti-Virus Scans, die Route die die E-Mail genommen hat u.a.

Die wichtigsten Header die gesetzt werden sollten, um zum Beispiel nicht direkt als SPAM eingestuft zu werden, sind Sender (From), Empfänger (To), das Datum (Date) und der Betreff (Subject).

X-Virus-Scanned: amavisd-new at diverse.io
X-Spam-Flag: NO
X-Spam-Score: 0.524
X-Spam-Level:
Subject: ITSec Testmail
From: ***@itsec.vog3l.de
To: ***@informatik.hu-berlin.de
Date: Fri, 09 Oct 2015 15:30:18

Body

Im Body befindet sich der eigentliche Inhalt der versendet werden soll. Wird eine E-Mail mit PGP oder S/MIME signiert, so findet man auch die Signatur im Body.

SMTP

Beim Versenden verpackt der versendende MTA die E-Mail in eine Art Umschlag. Hierbei wird dem empfangenden MTA ein Begrüßung (EHLO), der Absender (MAIL FROM) und der/die Empfänger (RCPT TO) vor der eigentlichen Übermittlung der E-Mail mitgeteilt. Erst wenn der empfangenden MTA sowohl den Absender als auch die Empfänger akzeptiert, wird die E-Mail (Header und Body) nach dem Stichwort DATA übertragen und mit einem Punkt (.) abgeschlossen.

Für den Fall, dass der empfangende MTA die Annahme der E-Mail ablehnen sollte, hat dies einen enormen Vorteil. Die eigentliche E-Mail mit dem Header und Body ist noch gar nicht übertragen worden.

EHLO mail.itsec.vog3l.de
MAIL FROM: ***@itsec.vog3l.de
RCPT TO: ***@informatik.hu-berlin.de
DATA
Subject: ITSec Testmail
From: ***@itsec.vog3l.de
To: ***@informatik.hu-berlin.de
Date: Fri, 09 Oct 2015 15:30:18

Hier beginnt der E-Mail Body....
.

Interaktionsdiagramm E-Mail Versand

Das folgende Interaktionsdiagramm veranschaulicht die Server Kommunikation die beim Versand einer E-Mail erfolgt.

Sicherheitstechniken

SPF

Das Secure Policy Framework (SPF) ist ein Verfahren um das Fälschen von Absenderadressen in E-Mails zu verhindern. Hierfür muss ein Ressource Record vom Typ TXT in der DNS Zone für eine Domain hinterlegt werden.

$ dig -t TXT itsec.vog3l.de

itsec.vog3l.de.         291780  IN      TXT     "v=spf1 mx -all"

Der Eintrag hat die folgende Syntax:

v=versionsnummer qualifiermechanism qualifiermechanism

• Beispiel
  • v=spf1 ip4:10.5.10.13 a -all

• Mechanisms
  • ALL Trifft immer zu
  • A wenn der A Record zutrifft
  • IP4 wenn die angegebene IPv4 Adresse zutrifft
  • IP6 wenn die angegebene IPv6 Adresse zutrifft
  • MX wenn der MX record zutrifft
  • EXISTS
  • INCLUDE

• Qualifiers
  • + für PASS. Falls kein Qualifier angeben ist, wird + angenommen.
  • ? für NEUTRAL. Wird intepretiert als wenn keine policy angegeben wäre.
  • ~ (tilde) für SOFTFAIL. Eine Debugging Variante die zwischen NEUTRAL und FAIL angesiedelt ist. Üblicherweise wird eine E-Mail mit SOFTFAIL akzeptiert aber getagt.
  • - (minus) für FAIL. Die E-Mail sollte abgelehnt werden.

Der empfangende MTA kann nun die Felder 'MAIL-FROM' und 'HELO' aus dem E-Mail-Envelope gegen den im DNS hinterlegten SPF Record prüfen und die E-Mail entweder annehmen oder ablehnen. Es wird hierbei allerdings nicht das 'From:' Feld im Header der E-Mail geprüft.

Ein gültiger SPF Record hilft häufig auch dabei, dass E-Mails am Greylistening vorbei kommen, sowie auch einen besseren SPAM Score erzielen.

DKIM

DomainKeys Identified Mail (DKIM) ist eine Anti-Spoofing und Anti-Phishing Technik.

Die E-Mail wird hierfür vom versendenden MTA mit einer Signatur versehen. Vorher wird der Public Key in der DNS Zone in einem TXT Record hinterlegt. Damit kann der empfangenden MTA sicherstellen, dass der Versand für diese Domain authorisiert ist und die E-Mail beim Transport nicht modifiziert worden ist.

Ein Signatur sieht wie folgt aus:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=itsec.vog3l.de;
	s=mail; t=1444297250;
	bh=bmY+6VYtf/CKbo/kg3vJWg5eDLYfJ8ydsGRhxgoqVn8=;
	h=Subject:From:To:Date:From;
	b=gNcTfHCGrV57qtRXukKftJre0IsXa9eaxi0vCZvkWY3WlJezjnbduuDpsfZlLYLbT
	 ERSxXtD20vEBWGXz7PEdy9eoXzIKRT5AY4tDfwRN2KTBWgMrakS5q9JupqlOk5uzcD
	 KXE55K2aIGuPoO20VNOJePTbY2RkLUUxs80R9Ajo=

• v: Version
• a: Signatur Algorithmus
• c: Canonicalization Algorithmus für Header und Body
• d: Domain
• s: Selektor
• bh: Body Hash
• h: Liste aller Header die zur Signatur verwendet wurden. Die DKIM-Signatur (mit leerem b=) und der Body sind implizit enthalten.
• b: die eigentliche Signatur

Mit Hilfe des Selektors und der Domain kann der public key aus dem DNS ausgelesen werden:

$ dig -t TXT selektor._domainkey.domain

$ dig -t TXT mail._domainkey.itsec.vog3l.de

mail._domainkey.itsec.vog3l.de. 604800 IN TXT   "v=DKIM1\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDWLZ/sEpdm76aQkisvQF8P6MSEUAnztt7dBCSuT2u5Q0isG743a24bS0XJGDhtibZmA/yUj7gdaia5vSrH0PB9YSKd6eHQ6KD
ARQkDovhisxaj4y4esuOKiQYF3a9MFVpKMQc7rY1W+6JtvbhNJ6qkcZN8ySFxgYkqgiPZIWb1+wIDAQAB"

Zur Prüfung der Signatur errechnet der empfangende MTA den Hash-Wert aus den in h genannten Headern und dem Body. Zusätzlich wird mit Hilfe des Public Keys der Signatur Hash-Wert entschlüsselt und anschließend beide Hash-Werte miteinander verglichen. Stimmen diese überein ist die Signatur gültig.

Da die DKIM Signatur auch von Spam Scannern mit einbezogen wird, kann mit einer gültigen DKIM Signatur ein besserer Spam Score erzielt werden.

DNSSEC

Domain Name System Security Extensions (DNSSEC) ist eine Sicherheitserweiterung des Domain Name System (DNS), um die Authentizität und Integrität der DNS Antworten sicherzustellen. Dies wird dadurch erreicht, indem zu jeder DNS Antwort auch ein entsprechender RRSIG Record mitgeschickt wird. Dieser entspricht der digitalen Signatur des angefragten Ressource Records und kann mit Hilfe des Public Keys im DNSKEY record verifiziert werden.

$ dig +dnssec mail.itsec.vog3l.de

mail.itsec.vog3l.de.    604800  IN      A       XX.XX.XX.XXX
mail.itsec.vog3l.de.    604800  IN      RRSIG   A 5 4 604800 20151103185106 20151004185106 59235 itsec.vog3l.de. iJP8jqmXpUxSI+OXH+s7naTnLyAV9xqTqGRJmicJhQnzIfSWA/Hc+21k ZLwkL48NswboaGtM7aBMa5GyS3Ej3rA5TO
mr6+97P46mdypI3iUhZunG MJrHRwkKeaFbeFvQJDRLdaTePxTpODuWnUv7gD62Rxu9MRRKoV2/Q6cy o4GpNHd3//Zr21GsAk9m99N9xETdEySlPImO3aemSymH579rsZ7CyqDX +eRlYJIeoXaECdJV0N/6DvtJmgS2OpC6XL8qPUbz/KzCk0Kh4WNVfRrh IrbsYEEAf0
SMclZh5Dh1TPeB/0lh9RJtyCRsmlJAygkA9pbenp4XmaIi Sw7aWg==

$ dig +dnssec -t DNSKEY itsec.vog3l.de

itsec.vog3l.de.         604800  IN      DNSKEY  256 3 5 AwEAAa6QliT6Qa3mbvRu222NxMzMSMu9sWAkMi0oKFeCsktMIBBHCKYC s0XHA6sQ/fqfZMou5bq+OA9eOoDcW8SdnyRQkkOo+0fhJwANuE3cPU2w ni/eR5u5tZfYwLHB1TKt7/CwoKgCSrjTFf
36sT24cOWmLjcL1V6/VF/1 UAdqQU5Qp0CvYAKWjY61SzHo+kmc9KAE70QcNGWTeXKzhbuH/fUTNqw/ g/0tPFPJetvMEhp8I1G9gbpClYH678cpNPv+HKUpptBCbCPtHQwilPbH d6AQ2WCtB/K5D3fKdyrhG8HVrVNlgv0eCu5CxIxqzTAaC9NoBlhyOYg+ 9Yuo0pKm0e
U=
itsec.vog3l.de.         604800  IN      DNSKEY  257 3 5 AwEAAajcmFh2SDvoi5cpI16navuUBecsh04NX6Fad8mOe3JjFMbySk1D 88io2JiAFGtHHMj1hLQCxNFh3T69aDtqIBNjFNS05WbpNH+20rE/WCA0 B2AvXNKHQ7F8NR03jFJ/RoVfYLy7tVl8nx
kUw/wE9oAcUP88NFyiN0Tt WRQU0AksgFvtR7WwP6aujRcKUwX7IsPrvasfu8H0+Zhx1bOMTTDF+nWt +LpdDVKbkEZ0MKRqW+eCp+NCHrnu/KkjU4W1/+BPq9FMot3GnmHJoUZx 71meWrE1AcYmPXZLXQErM4CwJhXjOo+I9l6ZdIO+UGTNoHIFzHo8nRcb 2vVl0vJNIy
c=
itsec.vog3l.de.         604800  IN      RRSIG   DNSKEY 5 3 604800 20151103185106 20151004185106 59235 itsec.vog3l.de. EdJSBjfBFiw8W7cLCnxmtfHrCbbuGxDJFKDng9Dz4QeUmh4j+dBRXVfd vzqHa34Qzqhjpq146H73iQG6DwBAF
/kX4xbkWOMNWrYN+FXwiTjbrWWi WDAGynYElphjbDccTGdsiPF3A0bCGaqwaW1v5o6sfOWR7I6S86w3zevE u2eZqg2TPCBiEkNdw/Jdg1htgsONdj75URJa+D+hLNBPaEgDrqcWHH3a gv77WDoRaNyJUVZocn9uFlerrSC/9tJr69rV6TolPdPo2wXsWabnD/m9 Uu/1f
6DMoK9gzXbQxhtec3inzWb4ey50QvJWBQB+/BZr//y9Ris08ac+ viDjTw==
itsec.vog3l.de.         604800  IN      RRSIG   DNSKEY 5 3 604800 20151103185106 20151004185106 60691 itsec.vog3l.de. gWKf5bh2CE/QPcFQSqHWi54yAu6Wwl2E8j1mFtJlcrxyTcc4kug2dfeK q1LtvRTSHWrW3Ok9+f0UYlBSGGTjg
AHv71k4Nj4yDF9qP77b7SOKjpWz HQjyRiRJKbspc5HIkZkTZAt113obyowUKnWPlxxycs/5SbcvIyhadjbF q5kEzwWiizEEIC/2fDlZnAoMqG4KgTjxiJKEhuSpgnQwanT5ZMmipx7o NZu2gaQF22R6bJLB+r1h/jv9u7Cnm5S2+I8d4DlaXiJ+jgoqzeZrivj6 VHuYT
JNl+OVYbz6GnX1aEuO07RnnE8p9MtHsYRL0bv51lQWpvEm5po1J qVyiXw==

Jede DNS Zone hat zwei Arten von Keys zum signieren. Der Zone Signing Key (ZSK) wird zum signieren der Ressource Records verwendet und der zugehörige Public Key im DNSKEY Record hinterlegt. Der DNSKEY Record selber wird mit einem Key Signing Key (KSK) signiert. Der Public Key des KSK wird in der übergeordneten DNS Zone bekannt gemacht, indem dieser in einem DS Record veröffentlicht und mit dem ZSK der übergeordneten Zone signiert wird. Dies wird bis zur Root Zone entsprechend fortgeführt und dadurch eine Trust Chain aufgebaut.

Anleitungen zum Einrichten von DNSSEC:

• DNSSec
• DANE_für_unseren_Mail-Server

DANE

DNS-based Authentication of Named Entities (DANE) setzt DNSSEC zwingend voraus und bietet eine Alternative zum Heute üblichen CA Trust Anchor an. Hierfür wird das Zertifikat oder die CA für einen bestimmten Dienst, alternativ auch der Public Key, in einem TLSA Record in der DNS Zone bereit gestellt. Die Syntax für den Eintrag sieht wie folgt aus:

_portnummer._protokoll.domain

$ dig -t TLSA _25._tcp.mail.itsec.vog3l.de

_25._tcp.mail.itsec.vog3l.de. 604800 IN TLSA    3 0 1 09A1DAE37E9E087FB4764DEED67395F631DCAB6C3D9D70399FD49CFE D6B5F916

Die Zahlen '3 0 1' nach 'IN TLSA' haben die folgende Syntax und Bedeutung:

Certificate Usage | Selector | Matching Type

• Certificate Usage Feld
  • 0 CA Constraint: Nur die CA im TLSA Record darf als Trust Anchor verwendet werden und es wird eine Prüfung der Vertrauenshierarchie durchgeführt.
  • 1 Service Certificate Constraints: Dem Zertifikat im TLSA Record soll vertraut werden und es wird eine Prüfung der Vertrauenshierarchie durchgeführt.
  • 2 Trust Anchor Assertion: Das Zertifikat im TLSA Record soll als Trust Anchor verwendet werden und es wird eine Prüfung der Vertrauenshierarchie durchgeführt.
  • 3 Domain-Issued Certificate: Dem Zertifikat im TLSA Record soll vertraut werden und es wird keine Prüfung der Vertrauenshierarchie durchgeführt.

• Selector Feld:
  • 0 Zertifikat
  • 1 Public Key

• Matching Type Feld
  • 0 eins-zu-eins
  • 1 SHA-256 hash
  • 2 SHA-512 hash

Da das Zertifikat nun im DNS hinterlegt werden kann und Dank DNSSEC auch sicher abgefragt, ist es möglich mit DANE auch selbst ausgestellte Zertifikate zu verwenden die als Vertrauenswürdig eingestuft werden.

Postfix hat eine DANE Unterstützung eingebaut, diese kann aber nur anstatt Opportunistic TLS konfiguriert werden. Alternativ wäre Liste mit Domains zu pflegen, für die DANE eingesetzt werden soll. Da DANE noch keine flächendeckende Verbreitung hat, kommt zur Zeit eigentlich nur Möglichkeit in Frage DANE per Liste zu aktivieren, was aber doch sehr Pflegebedürftig ist. Wünschenswert wäre, dass wenn DANE konfiguriert ist als Fallback Opportunistic TLS genutzt werden würde.

TestUmgebung

• Debian 8 (Jessie)
• bind9 9.9.5
• postfix 2.11.3-1
• opendkim 2.9.2-2

Quellen

• BSI TR-03108 Sicherer E-Mail-Transport

• RFC7208 Sender Policy Framework (SPF) for Authorizing Use of Domains in Email)
• RFC4871 DomainKeys Identified Mail (DKIM) Signatures
• RFC4033 DNS Security Introduction and Requirements
• RFC4035 Protocol Modifications for the DNS Security Extensions
• RFC6394 Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)
• RFC6689 The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA
• RFC7218 Adding Acronyms to Simplify Conversations about DNS-Based Authentication of Named Entities (DANE)

• Sender_Policy_Framework
• DomainKeys_Identified_Mail
• Domain_Name_System_Security_Extensions

Check Tools

• DNSSEC Debugger
• DNS Zonen Visualisierung

Anleitungen

• Setup DKIM
• Setup DNSSEC
• Postfix Milter
• Postfix DANE