# HG changeset patch # User Heiko Schlittermann (JUMPER) # Date 1427717843 -7200 # Node ID 2834a7825e8e1b515f266b2c357de33193baed4c # Parent 98879feeb993959de1569b5e0d0c2791c6228114 renamed the main document to dane.txt diff -r 98879feeb993 -r 2834a7825e8e Makefile --- a/Makefile Mon Mar 30 14:00:40 2015 +0200 +++ b/Makefile Mon Mar 30 14:17:23 2015 +0200 @@ -1,4 +1,4 @@ -doc = sichere-email +doc = dane txt = ${doc}.txt html = out.html/${doc}.html diff -r 98879feeb993 -r 2834a7825e8e dane.txt --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/dane.txt Mon Mar 30 14:17:23 2015 +0200 @@ -0,0 +1,267 @@ +Sichere E-Mail +============== +:Author: Heiko Schlittermann +:Email: hs@schlittermann.de +:toc: + +Übersicht +--------- + +Verschiedene Mythen existieren über die Sicherheit/Vertraulichkeit von +E-Mail. In diesem kurzen Paper möchte ich aufklären über das derzeit +technisch Umsetzbare. + +== E-Mail-Übertragung + +Die E-Mail-Übertragung beginnt beim MUA des Absenders. Dieser sendet die +Mail per SMTP zum ersten MTA (Submission-Server). Häufig ist dafür eine +Anmeldung am Server notwendig. Dieser Server befindet sich entweder beim +Internet-Provider oder, meistens bei größeren Firmen, in einer internen +Infrastruktur. Die Adresse bzw. der Name des Submission-Servers sind im +MUA per Konfiguration fest hinterlegt. + +Vom Submission-Server geht die Mail dann über mehrere weitere MTAs bis +zum letzten MTA, der dann die Nachricht über den MDA in die Mailbox des Nutzers legt. +Die Adresse des jeweils nächsten MTA wird mit Hilfe des DNS ermittelt. + +Diese Mailbox liegt meistens auf einem Server im Internet. Auf diesen +greift dann der MUA des Empfängers per IMAP oder POP3 oder über einen +Webmail-Client zu. + +image::dia/transport.png[Transport der Mail] + +== Angriffspunkte + +Alle Übertragungskanäle sollten als unsicher betrachtet werden. Das gilt +für die Anmeldung am Submission-Server, für den Transport der Mails, für +die DNS-Information und auch für das Abrufen der Nachrichten. + +Für Angriffe ist nicht zwingend ein krimineller Hintergrund notwendig, +auch Überwachungsmaßnahmen werden schnell zu Angriffen. + +=== Übertragung der Mails + +Um an den Inhalt der übertragenen Nachrichten zu kommen, müsste der +Angreifer auf die Verbindungen zwischen den einzelnen Servern zugreifen +können. + +Werden verschlüsselte (TLS/SSL) Verbindungen verwendet, gelingt das +Mitschneiden auf den Verbindungen nicht mehr. Aber es ist möglich, die +Verbindung zu entführen und sich für das Zielsystem auszugeben. + +=== Namensauflösung + +Die Entführung der Verbindung ist möglich durch einen Eingriff ins IP-Routing, +oder durch die Manipulation der DNS-Daten, aus denen der Client die +IP-Adresse des Zielsystems erfährt. + + +== Stand der Technik + +Aktuell werden etwa 80% der Mails auf dem Transportweg verschlüsselt +übertragen. + +=== Übertragung der Mails + +TLS ist schon sehr lange Stand der Technik für verschlüsselte +Datenübertragung. Die Authentizität der Kommunikationspartner wird über +X509-Zertifikate (SSL-Zertifikate) festgestellt. Üblicherweise weist +sich der Server in einer Verbindung mit seinem Zertifikat aus. Der +Client prüft dises Zertifikat, um sicher zu sein, dass er mit dem +richtigen Server verbunden ist. + +Bei HTTPS geht der Browser davon aus, dass der Name des Zertifikats mit +dem Hostnamen aus der URL übereinstimmt. Um die Echtheit des Zertifikats +zu bestimmen, prüft der Browser, ob das Zertifikat von einer ihm +bekannten und vertrauenswürdigen CA unterschrieben ist. + +Auch die Mailprotokolle SMTP, IMAP, POP3 können eine Verschlüsselung des +Übertragungsweges aushandeln. Jeoch werden hier sehr oft +Server-Zertifikate verwendet, die sich nicht verifizieren lassen. Diese +Zertifikate sind entweder selbst signiert oder von lokalen CAs +bestätigt. + +Dort wo ein Client immer mit dem selben Server kommuniziert (z.B. MUA +mit Smarthost) ist es möglich, die Information über das +Server-Zertifikat auf dem Client als vertrauenswürdig zu hinterlegen. +Dieses Verfahren skaliert aber nicht, wenn die Menge der Zielhosts groß +ist. + +=== Namensauflösung + +DNS verwendet für die meisten Anfragen das UDP-Prokoll. Diese Protokoll +ist sehr anfällig für Angriffe. + +Bei DNS-Informationen geht es *immer* um öffentlich verfügbare +Information, hier geht es also nicht die Vertraulichkeit, sondern die +Authentizität der Daten. + +Wenn zwei DNS-Server miteinander kommunizieren (Abgleich der +Domaindaten), können die Daten mit TSIG geschützt werden. Dieses +Verfahren beruhg auf einem von beiden Seiten gemeinsam genutzten +Schlüssel. Es skaliert nicht für eine große Zahl von DNS-Clients die +eine große Zahl von DNS-Servern fragen. + +Seit gut 15 Jahren gibt es DNSSec, eine Erweiterung des DNS-Protokolls +und der DNS-Datensätze um die Möglichkeit, die Antworten zu signieren. +Damit kann der Client die erhaltene Antwort validieren. + +== Das technisch Machbare - Absicherung + +Der oben beschriebene Stand der Technik ist gut, aber nicht ausreichend. +Verbindungen können entführt werden, DNS-Antworten sind nur selten mit +DNSSec geschützt. + +=== Übertragung der Mails + +Jeder sendender MTA bzw. Client muss das Server-Zertifikat seines +Kommunikationspartners prüfen! Jedoch ist die Konvention von HTTPS +(Zertifikatsname == Hostname der URL) nicht auf die Mail-Kommunikation +übertragbar. + +Der Client benötigt also einen zweiten Kanal, über den er die +Information erhält, die er zum Validieren des Server-Zertifikats +benötigt. DNS bietet sich dafür an. Aber es muss gesichert sein, also DNSSec. + +=== Namensauflösung + +Seit ca. 2010 können die größen DNS-Domains über DNSSec gesichert +werden. Das bedeutet, dass die Nameserver die Antworten signieren. Das +gibt dem DNS-Client die Möglichkeit, die Antwort auf seine Frage zu +validieren. Wenn die DNS-Antworten validierbar sind, dann ist damit +auch die Informationen über die Adresse des nächsten Mailhosts +validierbar und auch die Information zum Überprüfen des +Server-Zertifikats des nächsten Mailhosts. + +== Umsetzung + +Die beschriebenen Maßnahmen zum Schutz der Mailübertragung müssen +kombiniert werden - TLS, Zertifikate und Überprüfung von +DNS-Informationen. + +Mit DANE ist ein Standard entwickelt worden, der beschreibt, wie +Zertifikatsinformation unabhängig von einer vertrauenswürdigen Instanz +(CA) geprüft werden kann: die notwendige Information wird im DNS +(gesichert über DNSSec) abgelegt. + +Die Initiative liegt in erster Linie beim Empfänger der Mail, *er* muss +Zertifikate bereitstellen, DNSSec für seind Domain implementieren. Erst +dann *kann* der Client die beschriebenen Mechanismen nutzen. + +Aktuelle MTAs unter Linux sind in der Lage, diesen Standard zu +unterstützen, sowohl auf der Server- als auch auf der Clientseite. + +=== Übertragung + +==== Client + +Mailclients müssen versuchen, verschlüsselte Verbindungen aufzubauen. +Mailclients *müssen* Zertifate der Server prüfen. MTA können das am +einfachsten mit DANE. + +==== Server + +Für alle Serverdienste, die mit Mail im Zusammenhang stehen, müssen +Zertifikate erzeugt werden, dabei spielt es keine Rolle, ob diese +Zertifikate von einer zentralen CA unterzeichnet werden, oder ob sie +selbstsigniert sind. Die Serverdienste müssen den Clients die +Möglichkeit der Verschlüsselung anzeigen. + +=== Namensauflösung + +==== Client + +Auf der Clientseite müssen validierende Resolver verwendet werden, als +Software, die in der Lage ist, neben der eigentlichen Namensauflösung +auch die Gültigkeit der Antwort zu überprüfen. + +==== Server + +Der Nameserver für die Zieldomain muss DNSSec unterstützen, die DNS-Zone +muss signiert sein und die Schlüssel müssen an die Elternzone +weitergegeben werden. Normalerweise ist dafür der Registrar der Domain +verantwortlich. Nur eine kleine Zahl der Domain-Registrare verfügt +bisher über die erforderlichen Schnittstellen. + +Im DNS muss für die Zielserver ein Datensatz eingetragen sein, +dieser enthält die Information über das Server-Zertifikat. + +== Schlussfolgerung + +Eine sichere Mailübertragung wird es nur geben, wenn beide Maßnamen (TLS +*und* DNSSec) gemeinsam verwendet werden. Zum aktuellen Zeitpunkt ist +bei den jeweils Verantwortlichen leider relativ wenig Problembewußtseind +und Fachwissen über diese Bereiche vorhanden. + +Wirklich sichere Mailübertragung ist nur mit End-To-End-Verschlüsselung +(S/MIME, GPG, PGP) möglich. TLS und DANE können nur die Sicherheit +zwischen den einzelnen Mailhosts gewährleisten. + + + +[glossary] +== Glossary + +[glossary] + +CA:: + Certificate Authority - eine vertrauenswürdige Organisation, die + sicherstellt, dass nur authorisierte Zertifikate ausgesetllt werden. + Dazu überprüft sie die Identität des Antragsstellers. + +DNS:: + Domain Name System - eine verteilte Datenbank, die Informationen über + Domains, IP-Adressen, verantwortliche Mailserver bereitstellt. + +IMAP:: + Internet Message Access Protocol - mit diesem Protokoll können MUAs auf + Mails zugreifen. Die Mails bleiben dabei auf dem Server. (RFC 3501 + u.a.) + +MDA:: + Mail Delivery Agent heisst die Software, die die Mail vom letzten MTA übernimmt und + in die Mailbox des Nutzers legt. (Protokolle: LMTP, Pipeline) + +MTA:: + Der Mail Transfer Agent ist das, was wir normalerweise „Mailserver“ + nennen, also Exim, Postfix, Qmail, Sendmail, …. (Protokolle: SMTP) + +MUA:: + Der Mail User Agent ist das, was wir normalerweise „Mailprogramm“ nennen, das + ist also für viele das Outlook, der Thunderbird, Mutt, Evolution,… + Es ist im strengen Sinne nicht der Webbrowser, auch wenn wir Webmail + damit machen können. (Protokolle: SMTP, IMAP, POP3) + +POP3:: + Post Office Protocol - mit diesem Protokoll können MUAs auf Mails + zugreifen. Die Mails werden lokal auf dem Client gespeichert. (RFC + 1939) + +SMTP:: + Simple Mail Transfer Protocol - mit diesem Protokoll werden Mails + übertragen, vom MUA zum Submission Server und von MTA zu MTA. (RFC + 5321) + +TLS/SSL:: + Transport Layer Security, Secure Socket Layer - ein Protokoll, mit + dessen Hilfe es möglich ist, den Übetragungskanal zwischen zwei + Endpunkten gegen Dritte zu schützen. Neuere Versionen heissen TLS, + ältere Versionen heißen SSL. (SSLv3.1 entpricht TLSv1.0) + +TSIG:: + Transaction Signature - bei der Übertragung von DNS-Information ein + Verfahren zur Authentifizierung und Integritätsprüfung + +Zertifikat | X509-Zertifikat:: + Ein elektronisches Dokument, das den Besitz z.B. eines bestimmten + Domainnamens bestätigt. Dieses Dokument ist in der Regel von einer + CA unterzeichnet, die damit bestätigt, die im Zertifikat + festgehaltenen Eigenschaften überprüft zu haben. + + +== Disclaimer + +Einige Dinge wurden nur vereinfacht dargestellt. Ich habe versucht, +nur unwesentliche Details zu übergehen, bin mir jedoch im Klaran +darüber, dass jeder eine andere Sichtweise auf _unwichtig_ hat. + diff -r 98879feeb993 -r 2834a7825e8e sichere-email.txt --- a/sichere-email.txt Mon Mar 30 14:00:40 2015 +0200 +++ /dev/null Thu Jan 01 00:00:00 1970 +0000 @@ -1,267 +0,0 @@ -Sichere E-Mail -============== -:Author: Heiko Schlittermann -:Email: hs@schlittermann.de -:toc: - -Übersicht ---------- - -Verschiedene Mythen existieren über die Sicherheit/Vertraulichkeit von -E-Mail. In diesem kurzen Paper möchte ich aufklären über das derzeit -technisch Umsetzbare. - -== E-Mail-Übertragung - -Die E-Mail-Übertragung beginnt beim MUA des Absenders. Dieser sendet die -Mail per SMTP zum ersten MTA (Submission-Server). Häufig ist dafür eine -Anmeldung am Server notwendig. Dieser Server befindet sich entweder beim -Internet-Provider oder, meistens bei größeren Firmen, in einer internen -Infrastruktur. Die Adresse bzw. der Name des Submission-Servers sind im -MUA per Konfiguration fest hinterlegt. - -Vom Submission-Server geht die Mail dann über mehrere weitere MTAs bis -zum letzten MTA, der dann die Nachricht über den MDA in die Mailbox des Nutzers legt. -Die Adresse des jeweils nächsten MTA wird mit Hilfe des DNS ermittelt. - -Diese Mailbox liegt meistens auf einem Server im Internet. Auf diesen -greift dann der MUA des Empfängers per IMAP oder POP3 oder über einen -Webmail-Client zu. - -image::dia/transport.png[Transport der Mail] - -== Angriffspunkte - -Alle Übertragungskanäle sollten als unsicher betrachtet werden. Das gilt -für die Anmeldung am Submission-Server, für den Transport der Mails, für -die DNS-Information und auch für das Abrufen der Nachrichten. - -Für Angriffe ist nicht zwingend ein krimineller Hintergrund notwendig, -auch Überwachungsmaßnahmen werden schnell zu Angriffen. - -=== Übertragung der Mails - -Um an den Inhalt der übertragenen Nachrichten zu kommen, müsste der -Angreifer auf die Verbindungen zwischen den einzelnen Servern zugreifen -können. - -Werden verschlüsselte (TLS/SSL) Verbindungen verwendet, gelingt das -Mitschneiden auf den Verbindungen nicht mehr. Aber es ist möglich, die -Verbindung zu entführen und sich für das Zielsystem auszugeben. - -=== Namensauflösung - -Die Entführung der Verbindung ist möglich durch einen Eingriff ins IP-Routing, -oder durch die Manipulation der DNS-Daten, aus denen der Client die -IP-Adresse des Zielsystems erfährt. - - -== Stand der Technik - -Aktuell werden etwa 80% der Mails auf dem Transportweg verschlüsselt -übertragen. - -=== Übertragung der Mails - -TLS ist schon sehr lange Stand der Technik für verschlüsselte -Datenübertragung. Die Authentizität der Kommunikationspartner wird über -X509-Zertifikate (SSL-Zertifikate) festgestellt. Üblicherweise weist -sich der Server in einer Verbindung mit seinem Zertifikat aus. Der -Client prüft dises Zertifikat, um sicher zu sein, dass er mit dem -richtigen Server verbunden ist. - -Bei HTTPS geht der Browser davon aus, dass der Name des Zertifikats mit -dem Hostnamen aus der URL übereinstimmt. Um die Echtheit des Zertifikats -zu bestimmen, prüft der Browser, ob das Zertifikat von einer ihm -bekannten und vertrauenswürdigen CA unterschrieben ist. - -Auch die Mailprotokolle SMTP, IMAP, POP3 können eine Verschlüsselung des -Übertragungsweges aushandeln. Jeoch werden hier sehr oft -Server-Zertifikate verwendet, die sich nicht verifizieren lassen. Diese -Zertifikate sind entweder selbst signiert oder von lokalen CAs -bestätigt. - -Dort wo ein Client immer mit dem selben Server kommuniziert (z.B. MUA -mit Smarthost) ist es möglich, die Information über das -Server-Zertifikat auf dem Client als vertrauenswürdig zu hinterlegen. -Dieses Verfahren skaliert aber nicht, wenn die Menge der Zielhosts groß -ist. - -=== Namensauflösung - -DNS verwendet für die meisten Anfragen das UDP-Prokoll. Diese Protokoll -ist sehr anfällig für Angriffe. - -Bei DNS-Informationen geht es *immer* um öffentlich verfügbare -Information, hier geht es also nicht die Vertraulichkeit, sondern die -Authentizität der Daten. - -Wenn zwei DNS-Server miteinander kommunizieren (Abgleich der -Domaindaten), können die Daten mit TSIG geschützt werden. Dieses -Verfahren beruhg auf einem von beiden Seiten gemeinsam genutzten -Schlüssel. Es skaliert nicht für eine große Zahl von DNS-Clients die -eine große Zahl von DNS-Servern fragen. - -Seit gut 15 Jahren gibt es DNSSec, eine Erweiterung des DNS-Protokolls -und der DNS-Datensätze um die Möglichkeit, die Antworten zu signieren. -Damit kann der Client die erhaltene Antwort validieren. - -== Das technisch Machbare - Absicherung - -Der oben beschriebene Stand der Technik ist gut, aber nicht ausreichend. -Verbindungen können entführt werden, DNS-Antworten sind nur selten mit -DNSSec geschützt. - -=== Übertragung der Mails - -Jeder sendender MTA bzw. Client muss das Server-Zertifikat seines -Kommunikationspartners prüfen! Jedoch ist die Konvention von HTTPS -(Zertifikatsname == Hostname der URL) nicht auf die Mail-Kommunikation -übertragbar. - -Der Client benötigt also einen zweiten Kanal, über den er die -Information erhält, die er zum Validieren des Server-Zertifikats -benötigt. DNS bietet sich dafür an. Aber es muss gesichert sein, also DNSSec. - -=== Namensauflösung - -Seit ca. 2010 können die größen DNS-Domains über DNSSec gesichert -werden. Das bedeutet, dass die Nameserver die Antworten signieren. Das -gibt dem DNS-Client die Möglichkeit, die Antwort auf seine Frage zu -validieren. Wenn die DNS-Antworten validierbar sind, dann ist damit -auch die Informationen über die Adresse des nächsten Mailhosts -validierbar und auch die Information zum Überprüfen des -Server-Zertifikats des nächsten Mailhosts. - -== Umsetzung - -Die beschriebenen Maßnahmen zum Schutz der Mailübertragung müssen -kombiniert werden - TLS, Zertifikate und Überprüfung von -DNS-Informationen. - -Mit DANE ist ein Standard entwickelt worden, der beschreibt, wie -Zertifikatsinformation unabhängig von einer vertrauenswürdigen Instanz -(CA) geprüft werden kann: die notwendige Information wird im DNS -(gesichert über DNSSec) abgelegt. - -Die Initiative liegt in erster Linie beim Empfänger der Mail, *er* muss -Zertifikate bereitstellen, DNSSec für seind Domain implementieren. Erst -dann *kann* der Client die beschriebenen Mechanismen nutzen. - -Aktuelle MTAs unter Linux sind in der Lage, diesen Standard zu -unterstützen, sowohl auf der Server- als auch auf der Clientseite. - -=== Übertragung - -==== Client - -Mailclients müssen versuchen, verschlüsselte Verbindungen aufzubauen. -Mailclients *müssen* Zertifate der Server prüfen. MTA können das am -einfachsten mit DANE. - -==== Server - -Für alle Serverdienste, die mit Mail im Zusammenhang stehen, müssen -Zertifikate erzeugt werden, dabei spielt es keine Rolle, ob diese -Zertifikate von einer zentralen CA unterzeichnet werden, oder ob sie -selbstsigniert sind. Die Serverdienste müssen den Clients die -Möglichkeit der Verschlüsselung anzeigen. - -=== Namensauflösung - -==== Client - -Auf der Clientseite müssen validierende Resolver verwendet werden, als -Software, die in der Lage ist, neben der eigentlichen Namensauflösung -auch die Gültigkeit der Antwort zu überprüfen. - -==== Server - -Der Nameserver für die Zieldomain muss DNSSec unterstützen, die DNS-Zone -muss signiert sein und die Schlüssel müssen an die Elternzone -weitergegeben werden. Normalerweise ist dafür der Registrar der Domain -verantwortlich. Nur eine kleine Zahl der Domain-Registrare verfügt -bisher über die erforderlichen Schnittstellen. - -Im DNS muss für die Zielserver ein Datensatz eingetragen sein, -dieser enthält die Information über das Server-Zertifikat. - -== Schlussfolgerung - -Eine sichere Mailübertragung wird es nur geben, wenn beide Maßnamen (TLS -*und* DNSSec) gemeinsam verwendet werden. Zum aktuellen Zeitpunkt ist -bei den jeweils Verantwortlichen leider relativ wenig Problembewußtseind -und Fachwissen über diese Bereiche vorhanden. - -Wirklich sichere Mailübertragung ist nur mit End-To-End-Verschlüsselung -(S/MIME, GPG, PGP) möglich. TLS und DANE können nur die Sicherheit -zwischen den einzelnen Mailhosts gewährleisten. - - - -[glossary] -== Glossary - -[glossary] - -CA:: - Certificate Authority - eine vertrauenswürdige Organisation, die - sicherstellt, dass nur authorisierte Zertifikate ausgesetllt werden. - Dazu überprüft sie die Identität des Antragsstellers. - -DNS:: - Domain Name System - eine verteilte Datenbank, die Informationen über - Domains, IP-Adressen, verantwortliche Mailserver bereitstellt. - -IMAP:: - Internet Message Access Protocol - mit diesem Protokoll können MUAs auf - Mails zugreifen. Die Mails bleiben dabei auf dem Server. (RFC 3501 - u.a.) - -MDA:: - Mail Delivery Agent heisst die Software, die die Mail vom letzten MTA übernimmt und - in die Mailbox des Nutzers legt. (Protokolle: LMTP, Pipeline) - -MTA:: - Der Mail Transfer Agent ist das, was wir normalerweise „Mailserver“ - nennen, also Exim, Postfix, Qmail, Sendmail, …. (Protokolle: SMTP) - -MUA:: - Der Mail User Agent ist das, was wir normalerweise „Mailprogramm“ nennen, das - ist also für viele das Outlook, der Thunderbird, Mutt, Evolution,… - Es ist im strengen Sinne nicht der Webbrowser, auch wenn wir Webmail - damit machen können. (Protokolle: SMTP, IMAP, POP3) - -POP3:: - Post Office Protocol - mit diesem Protokoll können MUAs auf Mails - zugreifen. Die Mails werden lokal auf dem Client gespeichert. (RFC - 1939) - -SMTP:: - Simple Mail Transfer Protocol - mit diesem Protokoll werden Mails - übertragen, vom MUA zum Submission Server und von MTA zu MTA. (RFC - 5321) - -TLS/SSL:: - Transport Layer Security, Secure Socket Layer - ein Protokoll, mit - dessen Hilfe es möglich ist, den Übetragungskanal zwischen zwei - Endpunkten gegen Dritte zu schützen. Neuere Versionen heissen TLS, - ältere Versionen heißen SSL. (SSLv3.1 entpricht TLSv1.0) - -TSIG:: - Transaction Signature - bei der Übertragung von DNS-Information ein - Verfahren zur Authentifizierung und Integritätsprüfung - -Zertifikat | X509-Zertifikat:: - Ein elektronisches Dokument, das den Besitz z.B. eines bestimmten - Domainnamens bestätigt. Dieses Dokument ist in der Regel von einer - CA unterzeichnet, die damit bestätigt, die im Zertifikat - festgehaltenen Eigenschaften überprüft zu haben. - - -== Disclaimer - -Einige Dinge wurden nur vereinfacht dargestellt. Ich habe versucht, -nur unwesentliche Details zu übergehen, bin mir jedoch im Klaran -darüber, dass jeder eine andere Sichtweise auf _unwichtig_ hat. -