1 Sichere E-Mail

     2 ==============

     3 :Author: Heiko Schlittermann

     4 :Email:  hs@schlittermann.de

     5 :toc:

     6 

     7 Übersicht

     8 ---------

     9 

    10 Verschiedene Mythen existieren über die Sicherheit/Vertraulichkeit von

    11 E-Mail.  In diesem kurzen Paper möchte ich aufklären über das derzeit

    12 technisch Umsetzbare.

    13 

    14 == E-Mail-Übertragung

    15 

    16 Die E-Mail-Übertragung beginnt beim MUA des Absenders. Dieser sendet die

    17 Mail per SMTP zum ersten MTA (Submission-Server). Häufig ist dafür eine

    18 Anmeldung am Server notwendig. Dieser Server befindet sich entweder beim

    19 Internet-Provider oder, meistens bei größeren Firmen, in einer internen

    20 Infrastruktur.  Die Adresse bzw. der Name des Submission-Servers sind im

    21 MUA per Konfiguration fest hinterlegt.

    22 

    23 Vom Submission-Server geht die Mail dann über mehrere weitere MTAs bis

    24 zum letzten MTA, der dann die Nachricht über den MDA in die Mailbox des Nutzers legt.

    25 Die Adresse des jeweils nächsten MTA wird mit Hilfe des DNS ermittelt.

    26 

    27 Diese Mailbox liegt meistens auf einem Server im Internet. Auf diesen

    28 greift dann der MUA des Empfängers per IMAP oder POP3 oder über einen

    29 Webmail-Client zu.

    30 

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

    32 

    33 == Angriffspunkte

    34 

    35 Alle Übertragungskanäle sollten als unsicher betrachtet werden. Das gilt

    36 für die Anmeldung am Submission-Server, für den Transport der Mails, für

    37 die DNS-Information und auch für das Abrufen der Nachrichten.

    38 

    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 

    44 Um an den Inhalt der übertragenen Nachrichten zu kommen, müsste der

    45 Angreifer auf die Verbindungen zwischen den einzelnen Servern zugreifen

    46 können.  

    47 

    48 Werden verschlüsselte (TLS/SSL) Verbindungen verwendet, gelingt das

    49 Mitschneiden auf den Verbindungen nicht mehr. Aber es ist möglich, die

    50 Verbindung zu entführen und sich für das Zielsystem auszugeben.

    51 

    52 === Namensauflösung

    53 

    54 Die Entführung der Verbindung ist möglich durch einen Eingriff ins IP-Routing,

    55 oder durch die Manipulation der DNS-Daten, aus denen der Client die

    56 IP-Adresse des Zielsystems erfährt.  

    57 

    58 

    59 == Stand der Technik

    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-Zertifikate (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 Die Initiative liegt in erster Linie beim Empfänger der Mail, *er* muss 

   148 Zertifikate bereitstellen, DNSSec für seind Domain implementieren. Erst

   149 dann *kann* der Client die beschriebenen Mechanismen nutzen. 

   150 

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

   152 unterstützen, sowohl auf der Server- als auch auf der Clientseite.

   153 

   154 === Übertragung

   155 

   156 ==== Client

   157 

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

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

   160 einfachsten mit DANE.

   161 

   162 ==== Server

   163 

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

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

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

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

   168 Möglichkeit der Verschlüsselung anzeigen.

   169 

   170 === Namensauflösung

   171 

   172 ==== Client

   173 

   174 Auf der Clientseite müssen validierende Resolver verwendet werden, als

   175 Software, die in der Lage ist, neben der eigentlichen Namensauflösung

   176 auch die Gültigkeit der Antwort zu überprüfen. 

   177 

   178 ==== Server

   179 

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

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

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

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

   184 bisher über die erforderlichen Schnittstellen.

   185 

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

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

   188 

   189 == Schlussfolgerung

   190 

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

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

   193 bei den jeweils Verantwortlichen leider relativ wenig Problembewußtseind

   194 und Fachwissen über diese Bereiche vorhanden.

   195 

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

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

   198 zwischen den einzelnen Mailhosts gewährleisten.

   199 

   200 

   201 

   202 [glossary]

   203 == Glossary

   204 

   205 [glossary]

   206 

   207 CA::

   208    Certificate Authority - eine vertrauenswürdige Organisation, die

   209    sicherstellt, dass nur authorisierte Zertifikate ausgesetllt werden.

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

   211 

   212 DNS::

   213    Domain Name System - eine verteilte Datenbank, die Informationen über

   214    Domains, IP-Adressen, verantwortliche Mailserver bereitstellt.

   215 

   216 IMAP::

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

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

   219     u.a.)

   220 

   221 MDA::

   222     Mail Delivery Agent heisst die Software, die die Mail vom letzten MTA übernimmt und

   223     in die Mailbox des Nutzers legt. (Protokolle: LMTP, Pipeline)

   224 

   225 MTA::

   226     Der Mail Transfer Agent ist das, was wir normalerweise „Mailserver“

   227     nennen, also Exim, Postfix, Qmail, Sendmail, …. (Protokolle: SMTP)

   228 

   229 MUA::

   230     Der Mail User Agent ist das, was wir normalerweise „Mailprogramm“ nennen, das

   231     ist also für viele das Outlook, der Thunderbird, Mutt, Evolution,…

   232     Es ist im strengen Sinne nicht der Webbrowser, auch wenn wir Webmail

   233     damit machen können. (Protokolle: SMTP, IMAP, POP3)

   234 

   235 POP3::

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

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

   238     1939)

   239 

   240 SMTP::

   241     Simple Mail Transfer Protocol - mit diesem Protokoll werden Mails

   242     übertragen, vom MUA zum Submission Server und von MTA zu MTA. (RFC

   243     5321)

   244 

   245 TLS/SSL::

   246     Transport Layer Security, Secure Socket Layer - ein Protokoll, mit

   247     dessen Hilfe es möglich ist, den Übetragungskanal zwischen zwei

   248     Endpunkten gegen Dritte zu schützen. Neuere Versionen heissen TLS,

   249     ältere Versionen heißen SSL. (SSLv3.1 entpricht TLSv1.0)

   250 

   251 TSIG::

   252     Transaction Signature - bei der Übertragung von DNS-Information ein

   253     Verfahren zur Authentifizierung und Integritätsprüfung

   254 

   255 Zertifikat | X509-Zertifikat::

   256     Ein elektronisches Dokument, das den Besitz z.B. eines bestimmten

   257     Domainnamens bestätigt. Dieses Dokument ist in der Regel von einer

   258     CA unterzeichnet, die damit bestätigt, die im Zertifikat

   259     festgehaltenen Eigenschaften überprüft zu haben.

   260 

   261 

   262 == Disclaimer

   263 

   264 Einige Dinge wurden nur vereinfacht dargestellt. Ich habe versucht,

   265 nur unwesentliche Details zu übergehen, bin mir jedoch im Klaran

   266 darüber, dass jeder eine andere Sichtweise auf _unwichtig_ hat.

   267