Sicherer E-Mail Transport: Difference between revisions

From
Jump to navigation Jump to search
Line 126: Line 126:


==DANE==
==DANE==
DNS-based Authentication of Named Entities (DANE) setzt DNSSEC voraus und bietet eine Alternative zum heute üblichen CA Trust Anchor an.
DNS-based Authentication of Named Entities (DANE) setzt DNSSEC voraus und bietet eine Alternative zum Heute üblichen CA Trust Anchor an.




Revision as of 14:35, 22 October 2015

E-Mail

Aufbau

Den meisten ist bekannt, dass eine E-Mail aus deinem Header und einem Body Teil besteht. Darüber hinaus wird eine E-Mail beim Versand in einen Envelope (Umschlag) gesteckt.

Envelope

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. Dies hat z.B. den Vorteil, dass der eigentliche Inhalt der E-Mail noch nicht übertragen worden ist, für den Fall, dass der empfangende MTA die Annahme der E-Mail ablehnen sollte. 

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....
.

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 und auch die Route die die E-Mail genommen hat. 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 und unter Umständen auch eine PGP oder S/MIME Signatur.

Server Kommunikation

Das folgenden Interaktionsdiagramm veranschaulicht die Kommunikation die beim Versand einer E-Mail erfolgt. Hierbei wird nur die Server zu Server Kommunikation betrachtet.

Interaction-send-email.jpeg

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 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 Technik um E-Mail Spoofing und Phishing zu verhindern. Die E-Mail wird hierfür vom versendenden MTA mit einer Signatur versehen, die vom empfangenden MTA verifiziert werden kann. Somit 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=

Die Tags in der Signatur bedeuten folgendes:

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


Mit Hilfe des Selektors und der Domain kann der public key wie folgt im 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 dem Header und dem Body und vergleicht diesen gegen den Hash-Wert, der sich aus der Entschlüsselung des Signatur Hash-Wertes aus dem Header mit dem Public Key ergibt.

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 jede zu jeder DNS Antwort auch ein entsprechender RRSIG Record mitgeschickt wird. Dieser entspricht der digitalen Signatur des angefragten 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       5.9.27.206
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==


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 ein Trust Anchor aufgebaut.


Chain.png


Anleitungen zum Einrichten von DNSSEC:

DANE

DNS-based Authentication of Named Entities (DANE) setzt DNSSEC voraus und bietet eine Alternative zum Heute üblichen CA Trust Anchor an. 


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

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


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


Das aktuelle Postfix unterstützt DANE bereits, aber DANE kann entweder anstatt von Opportunistic TLS konfiguriert werden, oder es Alternativ jede Domain gepflegt werde, für die DANE genutzt werden soll. Da DANE noch kein e Flächendeckende Verbreitung hat, kommt zur Zeit eigentlich nur Möglichkeit in Frage DANE per Domain 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

Wikipedia

Check Tools

Anleitungen

Retrieved from "https://sarwiki.informatik.hu-berlin.de/index.php?title=Sicherer_E-Mail_Transport&oldid=11826"