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