# HG changeset patch # User Heiko Schlittermann (JUMPER) # Date 1427462584 -3600 # Node ID ddbc7cbd83f7ffd1fab77b957dd708f2def2c167 # Parent 81355bae626f2d792d3518ecf671dc13863a9fa2 [snapshot] diff -r 81355bae626f -r ddbc7cbd83f7 .hgignore --- a/.hgignore Thu Mar 26 11:12:42 2015 +0100 +++ b/.hgignore Fri Mar 27 14:23:04 2015 +0100 @@ -1,2 +1,3 @@ syntax:glob out.html/ +dia/*.png diff -r 81355bae626f -r ddbc7cbd83f7 Makefile --- a/Makefile Thu Mar 26 11:12:42 2015 +0100 +++ b/Makefile Fri Mar 27 14:23:04 2015 +0100 @@ -6,6 +6,9 @@ date = ${shell date -I} revision = "${shell hg id -tibB}" +dia = ${wildcard dia/*dia} +png = ${dia:.dia=.png} + .PHONY: all clean distclean @@ -14,8 +17,13 @@ distclean: ${clean} rm -f ${html} rmdir ${dir ${html}} + rm -f dia/*.png -${html}: ${txt} +${html}: ${txt} ${png} @mkdir -p ${dir $@} asciidoc -a lang=de -a data-uri -a icons -a date=${date} \ -a revision=$(revision) -o $@ ${txt} + +dia/%.png: dia/%.dia + @mkdir -p ${dir $@} + dia --export=$@ $< diff -r 81355bae626f -r ddbc7cbd83f7 dia/transport.dia --- a/dia/transport.dia Thu Mar 26 11:12:42 2015 +0100 +++ b/dia/transport.dia Fri Mar 27 14:23:04 2015 +0100 @@ -65,13 +65,13 @@ - + - + - + @@ -103,7 +103,7 @@ - + @@ -116,13 +116,13 @@ - + - + - + @@ -154,7 +154,7 @@ - + @@ -167,13 +167,13 @@ - + - + - + @@ -205,7 +205,7 @@ - + @@ -218,13 +218,13 @@ - + - + - + @@ -256,7 +256,7 @@ - + @@ -269,16 +269,16 @@ - + - + - + @@ -317,7 +317,7 @@ - + @@ -339,16 +339,16 @@ - + - + - - - - + + + + @@ -370,22 +370,22 @@ - + - + - + - - - - + + + + @@ -408,21 +408,21 @@ - + - + - + - - - - + + + + @@ -445,19 +445,19 @@ - + - + - + - - + + @@ -490,16 +490,16 @@ - + - + - + @@ -513,7 +513,7 @@ - + @@ -529,10 +529,10 @@ - + - + @@ -546,6 +546,39 @@ + + + + + + + + + + + + + + + + + + + + + + + + + #DNS# + + + + + + + + @@ -560,48 +593,15 @@ - + - + - - - - - - #DNS# - - - - - - - - - - - - - - - - - - - - - - - - - - - - + - + @@ -633,7 +633,7 @@ - + @@ -646,16 +646,16 @@ - + - + - - - - + + + + @@ -677,16 +677,16 @@ - + - + - + @@ -700,7 +700,201 @@ - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #SMTP# + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + #Internet# + + + + + + + + + diff -r 81355bae626f -r ddbc7cbd83f7 sichere-email.txt --- a/sichere-email.txt Thu Mar 26 11:12:42 2015 +0100 +++ b/sichere-email.txt Fri Mar 27 14:23:04 2015 +0100 @@ -14,7 +14,7 @@ == E-Mail-Übertragung Die E-Mail-Übertragung beginnt beim MUA des Absenders. Dieser sendet die -Mail per SMTP zu seinem _Submission-Server_. Häufig ist dafür eine +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 @@ -28,27 +28,164 @@ 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. Eine andere Möglichkeit ist, die Antwort des DNS so zu -verfälschen, dass die Verbindung zum Zielserver zu einem anderen Server -entführt wird. Von dort kann die Nachricht dann weitergeleitet werden, -so dass die Entführung nicht auffällt. +können. Werden verschlüsselte (TLS/SSL) Verbindungen verwendet, gelingt das -Mitschneiden auf den Verbindungen nicht mehr. Wenn es aber wieder -gelingt, die Verbindung zu entführen, dann kann die Mail mitgeschnitten -werden, da TLS/SSL lediglich eine Verschlüsslung des Transportkanals -zwischen zwei Servern darstellt. +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-Zertifikaten (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. + +Aktuelle MTAs unter Linux sind in der Lage, diesen Standard zu +unterstützen. + +=== Ü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 + +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. + + == Disclaimer Einige Dinge wurden nur vereinfacht dargestellt. Ich habe versucht, @@ -61,10 +198,20 @@ [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) @@ -79,25 +226,31 @@ 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) -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.) - -POP3:: - Post Office Protocol - mit diesem Protokoll können MUAs auf Mails - zugreifen. Die Mails werden lokal auf dem Client gespeichert. (RFC - 1939) - 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. + 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. [index]