Die MECSA-Plattform prüft Sicherheit und Datenschutz die von Email-Providern angeboten werden, indem sie deren Support auf eine Liste von vorher identifizierten Standards prüft.
Der StartTLS-Befehl [RFC3207, RFC7817] ist eine Erweiterung des „Simple Mail Transfer Protocol“ [RFC5321] (SMTP), das normalerweise „Transport Layer Security“ [RFC5246] (TLS) Verschlüsselung zwischen Client und Server (Absenderin/Absender und Empfängerin/Empfänger) emöglicht. Nach dem SMTP-Protokoll muss der Server seine Unterstützung zum StartTLS-Befehl in der Antwort auf einen EHLO-Befehl ankündigen. Der Client sendet dann den StartTLS-Befehl um darauf hin zuweisen, dass er eine TLS-Verhandlung wünscht. In dieser TLS-Verhandlung geschehen zwei Dinge:
Beispiel für einen SMTP-Dialog, entnommen aus RFC3207:
S: <waits for connection on TCP port 25>
C: <opens connection>
S: 220 mail.imc.org SMTP service ready
C: EHLO mail.example.com
S: 250-mail.imc.org offers a warm hug of welcome
S: 250-8BITMIME
S: 250-STARTTLS
S: 250 DSN
C: STARTTLS
S: 220 Go ahead
C: <starts TLS negotiation>
C & S: <negotiate a TLS session>
C & S: <check result of negotiation>
C: EHLO mail.example.com
S: 250-mail.imc.org touches your hand gently for a moment
S: 250-8BITMIME
S: 250 DSN
X.509-Zertifikate werden benutzt um die Identität und/oder den Öffentlichen Schlüssel eines Servers zu prüfen (z.B. während einer TLS-Verhandlung). X-509-Zertifikate (manchmal auch „Secure Socket Layer“ (SSL)-Zertifikate genannt) erhielten ihren Namen von dem Zertifikatsformat, das ursprünglich von Netscape eingeführt wurde, als es die erste Version des SSL-Protokolls entwickelte. Ein X.509-Zertifkiat fungiert als Kontainer für spezifische Informationen hinsichtlich der Idenität, für die das Zertifikat ursprünglich ausgestellt wurde. Die wichtigsten Einträge, die sich in einem X.509 finden lassen, sind:
Version: Die Version des X.509-Formats, die für das Zertifkat verwendet wurde.
Serial number: Eine eindeutige Zahl die durch den Herausgeber des Protokolls festgelegt wird.
Algorithm information: Der Algorithms, welcher benutzt wird um das Zertifikat zu unterzeichnen.
Issuer distinguished names: Der Name des Herausgebers (normalerweise eine „certification authority“) des Zertifikats.
Validity period of the certificate: Beginn und Ende der Gültigkeitsperiode des Zertifikats.
Subject distinguished name: Der Name des Zertifkatbesitzers, für welches das Zertifikat ausgestellt wurde.
Subject public key information Öffentlicher Schlüssel des Zertifikatbesitzers.
Das Format des Zertifkates wird in RFC5280 festgelegt. Die Art und Weise wie darauf zugegriffen und es verarbeitet werden kann, ist in RFC4210 definiert. RFC3739 legt fest, was ein qualifiziertes Zertifikat genannt werden darf. Diese Bezeichnung hängt zusammen mit der „European Directive on Electronic Signature (Directive 1999/93/EC)“.
Das „Sender Policy Framework“ [RFC7208, RFC7372] (SPF) ist ein Protokoll, dass den Email-Providern erlaubt eine Liste von Hosts zu veröffentlichen (IP-Adressen), denen es erlaubt ist in ihrem Namen Emails zu verschicken. Dem SMTP-Protokoll zu Folge muss ein Client, wenn er sich indentifiziert (HELO or EHLO commands), einen Hostname oder eine IP-Adresse angeben. Wenn der Client die Übertragung einer Email initiiert, muss zusätzlich der MAIL-FROM Befehl versendet werden, welcher die Email-Adresse des Absenders enthält.
Diese beiden Einträge, der Hostname (oder die IP-Adresse) und der HELO (or EHLO)-Befehl, sowie der Befehl für die Email von MAIL-FROM, müssen mit dem SPF-record verglichen werden, der vom entsprechenden Email-Provider veröffentlicht wurde. Dies geschieht, um zu prüfen, ob der Client die Erlaubnis hat Emails für den Provider zu versenden.
v=spf1 a mx ip4:139.191.36.5 -all
v=spf1 Version
a Die IP wird akzeptiert, wenn sie eine der et.dcslab.eu A-records ist
mx Die IP wird akzeptiert, wenn sie eine der et.dcslab.eu MX-records ist
ip4:139.191.36.5 Die IP wird akzeptiert, wenn sie sich im vorgegebenen Rahmen bewegt
-all Die Grundeinstellung ist die IP nicht zu akzeptieren
„DomainKeys Identified Mail“ [RFC6376] (DKIM) ist ein Authentifizierungsmechanismus, der benutzt wird um die Gültigkeit des Emailursprungs zu prüfen.
Er benutzt digitale Unterschriften um die Identität des Hosts zu prüfen. Ein Email-Provider erzeugt eine Paar eines öffentlichen/privaten Schlüssels für eine Domain und veröffentlicht den öffentlichen Schlüssel als DNS-record. Jedes Mal, wenn eine Mail gesendet wird, wird dabei der private Schlüssel verwendet. Sobald der Empfangsserver de Nachricht erhält, kann damit die Unterschrift mit dem veröffentlichen Record verglichen werden.
Beispiel eines DKIM-Headers einer empfangenen Email.
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=et.dcslab.eu; s=102016; t=1476792726; bh=HS0o/CkH/ZCpSrfolDyH8IR5hX6n8GxWLzY59OuvtWo=; h=Date:From:From:Subject; b=OOlOO/jae1cPF2pllIF2QiENPJdUvGL70FdPMkKa89qkhXdvr D89eZwK6OZzEdLYncAbYCrEVi58jFqFAjKBcASrRpjSQXTJX6hM cRNZ295/1xp8vR/J9CQl9baqGxhYWID8Z0OrN/tbwXNN2UiNTmk MIm90UDJHdQnw/rd9rX4=
Im vorherigen Beispiel, um den Schlüssel zu erhalten und die DKIM-Signatur prüfen zu können, muss man einen DNS-record dvom Typ TXT für die Domain beantragen: 102016._domainkey.et.dcslab.eu.
„Domain-based Message Authentication, Reporting and Conformance“ [RFC7489] (DMARC) ist ein Mechanismus, der es Providern erlaubt, Regelvorgaben für SPF und DKIM zu veröffentlichen.
Insbesondere erlaubt er einem Email-Provider einzuschätzen, was geschehen soll, wenn eine Nachricht nicht dem SPF- oder DKIM-Standard entspricht (abgelehnt, unter Quarantäne, keine Aktion) und stellt eine Email-Adresse zur Verfügung an die Berichte gesandt werden können.
Weiterhin kann DMARC dazu benutzt werden, Regeln für Akzeptanz-/Ablehnungsquoten von nicht dem Standard entsprechenden Nachrichten festzulegen. Dies erlaubt derartige Technologien auch erst nach und nach einzuführen. Beispiel: DMARC-record von der et.dcslab.eu-Domain:
v=DMARC1; p=reject; rua=mailto:dmarc_reports@et.dcslab.eu
v=DMARC1 Sprachversion von DMARC
p=reject Regeln die von der Empfängerin/dem Empfänger angewendet werden: keine Aktion/Quarantäne/abgelehnt.
rua=mailto.. Adresse für Sendeberichte
DNS-based Authentication of Named Entities [RFC6698, RFC7218, RFC7671, RFC7672] DANE ist ein Mechanismus, der x.509-Zertifikate (oder auch öffentliche Schlüssel) mit Services verbindet. Dabei werden Port, Protokoll, und Domain des Service näher festgelegt. Diese Verbindung von Zertifikat und Service wird als TLSA-DNS-record veröffentlicht. DANE kann in Verbindung mit jedem Service verwendet werden. Für den speziellen Fall von Email-Kommunikation gilt RFC7672, das die Anwendung von DANE und DNSSEC auf die Kommunikation zwischen MTAs (SMTP) regelt. RFC7672 schlägt insbesondere vor, DANE-TA und DANE-EE mit DNSSEC zu verwenden.
Ein TLSA-record enthält 4 Werte: Die Eingabefelder für Benutzer, Selektor, „Matching-Type“ und „Associated-Data“. Im Folgenden zeigen wir die Beschreibung unterschiedlicher Felder eines TLSA-records.
Als Beispiel zeigen wir, wie ein TLSA-record für einen SMTP-Server aussähe, der auf dem Standard-Port 25 läuft, mit dem Host mx.example.com, unter Benutzung von DANE-EE und Veröffentlichung eines öffentlichen SHA2-256-Schlüssels (SPKI) des 'Endpoint-Zertifikats':
_25._tcp.mx.example.com TLSA 3 1 1 1cf...6ab
Usage-Field
Selector-Field: Präzisiert den Inhalt des x.509-Zertifikat um es den damit zusammenhängende Daten anzupassen.
Matching-Type-field: Schlägt das Format der damit zusammenhängenden Daten vor.
Associated-Data:
Domain Name System Security Extensions [RFC4033, RFC6014, RFC6840] DNSSEC ist ein Protokoll, das benutzt wird um die Antworten von DNS-Servern zu authentifizieren. Dieser Mechanismus ist sehr nützlich, um zu Verhindern dass Programme und Apps veränderte oder gefälschte DNS-recods verwenden. Das Protokoll is in der Lage, eine Reihe von DNS-records zu authentifizieren, indem es eine beiligende, krypotgraphische Unterschrift verifiziert.
Um DNSSEC zu aktivieren, muss der Server Zugriff auf zwei Paare von Schlüsseln (öffentlich und privat) haben. Das erste Paar sind die „Public and Private Zone Signing Keys (ZSKs)“, das zweite die „Key Signing keys (KSKs)“. Mit dem privaten ZSK unterzeichnet der Server digital alle RRSET- und DNS-records (alle Gruppen von DNS-records der selben Art, z.B. MX, TXT, etc.) und speichert alle Unterschriften in ein RRSIG-record. Der öffentliche ZSK wird gebraucht um Unterschriften zu verifizieren und wird als DNSKEY-record veröffentlicht. Der DNSKEY-record des öffentlichen ZSK wird mit dem privaten KSK unterzeichnet. Der öffentliche KSK wird als als DNSKEY-record veröffentlicht und ist halb-siginiert, was bedeutet, dass er mit einem privaten KSK gezeichnet ist. Diese Reihenfolge von Schritten stellt das Vertrauen innerhalb einer Zone her.
Da DNS ein hierarisches System ist, muss das Vertrauen innerhalb einer Zone mit einer „Parent Zone“ verbunden sein. Dafür hasht der Server den öffentlichen KSK und veröffentlicht diesen Hash als einen DS-record in seiner „Parent-Zone“
