31 image::dia/transport.png[Transport der Mail]

    32 

    39 Für Angriffe ist nicht zwingend ein krimineller Hintergrund notwendig,

    40 auch Überwachungsmaßnahmen werden schnell zu Angriffen.

    41 

    42 === Übertragung der Mails

    43 

    60 

    61 Aktuell werden etwa 80% der Mails auf dem Transportweg verschlüsselt

    62 übertragen.

    63 

    64 === Übertragung der Mails

    65 

    66 TLS ist schon sehr lange Stand der Technik für verschlüsselte

    67 Datenübertragung. Die Authentizität der Kommunikationspartner wird über

    68 X509-Zertifikaten (SSL-Zertifikate) festgestellt.  Üblicherweise weist

    69 sich der Server in einer Verbindung mit seinem Zertifikat aus. Der

    70 Client prüft dises Zertifikat, um sicher zu sein, dass er mit dem

    71 richtigen Server verbunden ist.

    72 

    73 Bei HTTPS geht der Browser davon aus, dass der Name des Zertifikats mit

    74 dem Hostnamen aus der URL übereinstimmt. Um die Echtheit des Zertifikats

    75 zu bestimmen, prüft der Browser, ob das Zertifikat von einer ihm

    76 bekannten und vertrauenswürdigen CA unterschrieben ist.

    77 

    78 Auch die Mailprotokolle SMTP, IMAP, POP3 können eine Verschlüsselung des

    79 Übertragungsweges aushandeln. Jeoch werden hier sehr oft

    80 Server-Zertifikate verwendet, die sich nicht verifizieren lassen. Diese

    81 Zertifikate sind entweder selbst signiert oder von lokalen CAs

    82 bestätigt. 

    83 

    84 Dort wo ein Client immer mit dem selben Server kommuniziert (z.B. MUA

    85 mit Smarthost) ist es möglich, die Information über das

    86 Server-Zertifikat auf dem Client als vertrauenswürdig zu hinterlegen.

    87 Dieses Verfahren skaliert aber nicht, wenn die Menge der Zielhosts groß

    88 ist.

    89 

    90 === Namensauflösung

    91 

    92 DNS verwendet für die meisten Anfragen das UDP-Prokoll. Diese Protokoll

    93 ist sehr anfällig für Angriffe. 

    94 

    95 Bei DNS-Informationen geht es *immer* um öffentlich verfügbare

    96 Information, hier geht es also nicht die Vertraulichkeit, sondern die

    97 Authentizität der Daten. 

    98 

    99 Wenn zwei DNS-Server miteinander kommunizieren (Abgleich der

   100 Domaindaten), können die Daten mit TSIG geschützt werden. Dieses

   101 Verfahren beruhg auf einem von beiden Seiten gemeinsam genutzten

   102 Schlüssel. Es skaliert nicht für eine große Zahl von DNS-Clients die

   103 eine große Zahl von DNS-Servern fragen.

   104 

   105 Seit gut 15 Jahren gibt es DNSSec, eine Erweiterung des DNS-Protokolls

   106 und der DNS-Datensätze um die Möglichkeit, die Antworten zu signieren.

   107 Damit kann der Client die erhaltene Antwort validieren. 

   108 

   109 == Das technisch Machbare - Absicherung

   110 

   111 Der oben beschriebene Stand der Technik ist gut, aber nicht ausreichend.

   112 Verbindungen können entführt werden, DNS-Antworten sind nur selten mit

   113 DNSSec geschützt.

   114 

   115 === Übertragung der Mails

   116 

   117 Jeder sendender MTA bzw. Client muss das Server-Zertifikat seines

   118 Kommunikationspartners prüfen!  Jedoch ist die Konvention von HTTPS

   119 (Zertifikatsname == Hostname der URL) nicht auf die Mail-Kommunikation

   120 übertragbar.

   121 

   122 Der Client benötigt also einen zweiten Kanal, über den er die

   123 Information erhält, die er zum Validieren des Server-Zertifikats

   124 benötigt.  DNS bietet sich dafür an. Aber es muss gesichert sein, also DNSSec.

   125 

   126 === Namensauflösung

   127 

   128 Seit ca. 2010 können die größen DNS-Domains über DNSSec gesichert

   129 werden. Das bedeutet, dass die Nameserver die Antworten signieren. Das

   130 gibt dem DNS-Client die Möglichkeit, die Antwort auf seine Frage zu

   131 validieren. Wenn die DNS-Antworten validierbar sind, dann ist damit

   132 auch die Informationen über die Adresse des nächsten Mailhosts

   133 validierbar und auch die Information zum Überprüfen des

   134 Server-Zertifikats des nächsten Mailhosts.

   135 

   136 == Umsetzung

   137 

   138 Die beschriebenen Maßnahmen zum Schutz der Mailübertragung müssen

   139 kombiniert werden - TLS, Zertifikate und Überprüfung von

   140 DNS-Informationen.

   141 

   142 Mit DANE ist ein Standard entwickelt worden, der beschreibt, wie

   143 Zertifikatsinformation unabhängig von einer vertrauenswürdigen Instanz

   144 (CA) geprüft werden kann: die notwendige Information wird im DNS

   145 (gesichert über DNSSec) abgelegt.

   146 

   147 Aktuelle MTAs unter Linux sind in der Lage, diesen Standard zu

   148 unterstützen.

   149 

   150 === Übertragung

   151 

   152 ==== Client

   153 

   154 Mailclients müssen versuchen, verschlüsselte Verbindungen aufzubauen.

   155 Mailclients *müssen* Zertifate der Server prüfen. MTA können das am 

   156 einfachsten mit DANE.

   157 

   158 ==== Server

   159 

   160 Für alle Serverdienste, die mit Mail im Zusammenhang stehen, müssen

   161 Zertifikate erzeugt werden, dabei spielt es keine Rolle, ob diese

   162 Zertifikate von einer zentralen CA unterzeichnet werden, oder ob sie

   163 selbstsigniert sind. Die Serverdienste müssen den Clients die

   164 Möglichkeit der Verschlüsselung anzeigen.

   165 

   166 === Namensauflösung

   167 

   168 Der Nameserver für die Zieldomain muss DNSSec unterstützen, die DNS-Zone

   169 muss signiert sein und die Schlüssel müssen an die Elternzone

   170 weitergegeben werden. Normalerweise ist dafür der Registrar der Domain

   171 verantwortlich. Nur eine kleine Zahl der Domain-Registrare verfügt

   172 bisher über die erforderlichen Schnittstellen.

   173 

   174 Im DNS muss für die Zielserver ein Datensatz eingetragen sein,

   175 dieser enthält die Information über das Server-Zertifikat.

   176 

   177 == Schlussfolgerung

   178 

   179 Eine sichere Mailübertragung wird es nur geben, wenn beide Maßnamen (TLS

   180 *und* DNSSec) gemeinsam verwendet werden. Zum aktuellen Zeitpunkt ist

   181 bei den jeweils Verantwortlichen leider relativ wenig Problembewußtseind

   182 und Fachwissen über diese Bereiche vorhanden.

   183 

   184 Wirklich sichere Mailübertragung ist nur mit End-To-End-Verschlüsselung

   185 (S/MIME, GPG, PGP) möglich. TLS und DANE können nur die Sicherheit

   186 zwischen den einzelnen Mailhosts gewährleisten.

   187 

   201 CA::

   202    Certificate Authority - eine vertrauenswürdige Organisation, die

   203    sicherstellt, dass nur authorisierte Zertifikate ausgesetllt werden.

   204    Dazu überprüft sie die Identität des Antragsstellers.

   205 

   209 

   210 IMAP::

   211     Internet Message Access Protocol - mit diesem Protokoll können MUAs auf

   212     Mails zugreifen. Die Mails bleiben dabei auf dem Server. (RFC 3501

   213     u.a.)

   229 POP3::

   230     Post Office Protocol - mit diesem Protokoll können MUAs auf Mails

   231     zugreifen. Die Mails werden lokal auf dem Client gespeichert. (RFC

   232     1939)

   233